Смешивание VB6 «устаревшего кода» и веб-приложения

Question

Я работаю над новым веб-сайтом, написанным на VB.Net с использованием ASP.NET MVC2, поэтому необходимо вызывать «устаревший» код VB6 для различных сложных элементов бизнес-логики.VB6 - это фреймворк, состоящий из множества dll, и он очень сложный, мы в значительной степени эмулируем, как фреймворк используется в нашем клиентском приложении, т. Е. Приложение работает (много настроек состояния), пользователь входит в систему (еще больше состояний) изатем загружает файл (еще больше состояния).

Мне была предоставлена ​​«структура интерфейса веб-службы», чтобы запустить его для использования в веб-приложении, эта «веб-структура» скрывает устаревший код за тонким слоем, работающим под IIS.Идея заключается в том, что пул потоков, предоставляемый IIS, сократит использование памяти и т. Д. И т. Д. Я не могу не поверить, что парень, предоставивший это, упустил из виду, поскольку каждый экземпляр имеет такое состояние, что пул потоков не может работатьпоскольку, как только пользователь входит в систему, используя один конкретный объект из пула, никакой другой объект не сможет обслуживать этого клиента (так как у него не будет состояния)!Кроме того, добавление интерфейса веб-службы и связанного с ним SOAP-маршалинга - это огромные издержки по сравнению с непосредственным вызовом объектов.

Единственный способ, которым я могу думать об этом, - это единственный экземпляр устаревшего интерфейса, который используется всеми клиентамии блокируется каждым вызовом, пока он не завершится, или потоком на клиента, где каждый устаревший интерфейсный объект создается в новом потоке и живет для жизни клиента.

Ни один из них не является идеальным, но с количеством рассматриваемого кода и продолжительной программой миграции на .net (2+ года и все еще с состоянием) я не могу придумать альтернативы.Мы запускаем исходное клиентское приложение в среде citrix для некоторых клиентов, поэтому я ожидаю, что оно также может нормально работать с потоком на клиента при достаточно мощном сервере и что издержки самой инфраструктуры должны быть ниже, чем при использовании клиентского приложения.

Есть идеи ??

Answer 1

Я предлагаю вам взглянуть на эту платформу Visual WebGui .Я являюсь сотрудником этой компании, и поэтому не представляюсь объективным, но я считаю, что Visual WebGui решил некоторые из основных проблем, связанных с масштабированием государственных приложений и превращением однопользовательской среды в многопользовательскую.Стоит посмотреть.

Answer 2

Вот вариант, но он не будет красивым.

Звучит так, как будто вам необходимо связать долгоживущий объект (объект с состоянием с вашим внутренним уровнем) с отдельными пользователями.

Вы могли бы сохранить этот объект в состоянии приложения и связать его с состоянием сеанса пользователя с помощью ключа.Вы должны предоставить упаковку, чтобы отслеживать их все.Когда сеанс умирает, вы можете захватить событие и уничтожить объект бэкэнда.

Состояние приложения - это хранилище ключей / значений, так же как и Session.Вы можете получить доступ через HttpContext.Application

. Большим недостатком этого является то, что объекты, которые вы помещаете туда, остаются там до тех пор, пока вы их не уничтожите, поэтому ваш код-оболочка и разрушающий сессию код должны быть на месте.Кроме этого, это может быть быстрый способ начать работу.

Как я уже сказал, это не будет оптимальным, но, вероятно, будет работать.

Подробнее о последствиях:http://msdn.microsoft.com/en-us/library/bf9xhdz4(VS.71).aspx

РЕДАКТИРОВАТЬ:

Вы также можете сделать эту работу в среде веб-фермы.Сохраните информацию, необходимую для воссоздания вашего унаследованного объекта с сохранением состояния в состоянии сеанса, которое может быть разделено между компьютерами с помощью встроенного поставщика SQL.Если пользователь подключается к серверу, на котором объект не существует, ваша оболочка состояния приложения может просто воссоздать его из информации о состоянии сеанса.

Это просто оставляет способ очистки объекта с состоянием на серверах, где он не существует.Т нужно.В вашей поисковой оболочке обновляйте хеш-таблицу или что-то с временем доступа каждый раз, когда к данному объекту с состоянием обращаются.Выполните процедуру периодической очистки в th-обертке, чтобы уничтожить объекты с состоянием, к которым не был получен доступ, чуть больше значения времени ожидания сеанса вашего веб-приложения.