DCOM singleton replacement

Question

У нас есть старое устаревшее веб-приложение. Архитектура состоит из:

1. (классический) ASP-страницы, обслуживающие браузеры клиента; VB, тысячи из них
2. сервер DCOM без обработки, вызываемый ASP (IIS); MFC, singleton, exe
3. база данных; один или несколько схем
4. дополнительное приложение ASP.NET вызова сервера DCOM

роли сервера являются:

• для обработки входа пользователя, выход из системы и лицензирования
• хранить информацию сеанса пользователя
• для создания UI
• для обеспечения/авторизации действий пользователя
• для извлечения и хранения данных в базе данных

Поскольку многие роли сервера, вызывающий интерфейс между ASP (IIS) и сервером DCOM довольно широк и широко используется на многих страницах.
Основная проблема лежит в IIS, вызывающем DCOM-сервер и увеличиваясь с новыми серверами Windows. Начиная с Windows Server 2008 эта комбинация практически не поддерживается. С UAC на месте даже однопользовательский сервер DCOM без обработки не работает (разные процессы запускаются в разных контекстах безопасности).

Я хотел бы сохранить код MFC/C++ сервера и работать как одиночный (несмотря на все минусы). Эти страницы ASP являются самой динамичной и постоянно меняющейся частью приложения, и я бы хотел оставить их неизменными. Я могу пожертвовать дополнительным приложением ASP.NET.

Что было бы лучшей заменой одноточечного интерфейса DCOM на сервере? Я считаю, что производительность и будущее обслуживание наиболее важны.

(я могу видеть, идентичную .Net интерфейс в качестве замены COM, но моя главная задача была держать его один-процесс-одиночки в моих первых итераций.)

Answer 1

Этот вопрос немного открытого состава для SO ... Но я давно использовал следующую технику, используя мост Java-to-COM. HTH ...

Я понимаю, что код работает, так как вы готовы сохранить большую часть его. У вас проблема с масштабированием одноэлементного шаблона.

Итак, разделите один синглтон на две части.

Сначала запустите свой синглтон как услугу (или в COM +). Добавьте к этому процессу небольшую прокладку (работает в своем потоке), которая принимает HTTP-запросы и преобразует их в вызовы COM-процессов. Поскольку вы уже работаете вне процесса, сортировка по потоку не должна быть проблемой. Посмотрите на Mongoose для части HTTP. Это один C-файл, который даст вам доказательство запуска концепции в кратчайшие сроки.

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

+ Убедитесь, что ваша прокладка не прослушивает публичный интерфейс!