Есть ли причины не размещать COM-сервер в приложении COM +? - PullRequest
3 голосов
/ 29 апреля 2009

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

Ответы [ 2 ]

3 голосов
/ 12 июня 2009

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

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

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

1 голос
/ 13 мая 2009

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

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

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

...