Есть ли какие-либо причины не размещать COM-сервер в приложении COM +?

Question

Самый простой способ преобразовать внутренний COM-сервер в внешний COM-сервер - это создать приложение COM +.Каковы возможные недостатки такого подхода?

Answer 1

Я действительно не могу придумать никакой причины создавать свой собственный контейнер или использовать сторонний (если таковой существует) в пользу MTS / COM +.Я имею в виду, что он делает все, что вы хотели бы:

• Позволяет выбрать распределение COM-объектов по процессам-контейнерам.
• Позволяет настроить учетную запись, под которой они работают .
• Отслеживает содержимое контейнера обрабатывает и перезапускает при необходимости и может утилизировать их.
• Даже позволяет размещать компоненты STA в сценариях где требуется несколько потоков обслуживается путем запуска нескольких рабочих процессов.и т.д.

Трудно представить, что можно добиться большего, не потратив на это 6 месяцев или больше.

Answer 2

Выворачивая вопрос наизнанку, я предполагаю, что ваш анти-я мог бы спросить: "Почему существуют варианты, помимо COM + сервера, для неработоспособного COM-сервера?Какие преимущества предоставляют эти другие варианты хостинга?"

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

Основное различие, которое я вижу, заключается в административной модели и возможностях, а также в гибкости.Например, размещение COM-сервера в службе Windows предоставляет вам возможности службы Windows - автоматический запуск при загрузке ОС;пользовательский интерфейс администратора, связанный с services.msc (как административные, так и операционные функции), и гибкость добавления других интерфейсов в эту службу (гибкость).