COM+ и .NET – практичный подход - часть 1

Written on . Posted in .NET Framework

ОГЛАВЛЕНИЕ

Данная статья состоит из трех основных частей. Первая часть рассматривает все стороны использования COM+. После ее прочтения вы узнаете, какие возможности есть для размещения сборки в COM+, влияния на производительность приложения ASP.NET и каковы, при наличии таковых, ограничения, налагаемые выбором определенного варианта размещения в COM+.

Вторая часть описывает все управляющие преимущества, которые приложение может получить от COM+. Эта часть содержит подробности об улучшении доступности и стабильности с помощью COM+ и о том, кого надо отслеживать и как использовать данные слежения для быстрого и легкого обнаружения источников проблемы.

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

Введение

COM+ существует, но не очень процветает на веб-серверах со времени windows 2000. COM+ даже заслуживает обновления до версии 1.5 в операционных системах XP и Windows 2003. COM+ был полезен для программ ДНК, но теряет свою славу в эру .Net. Большинство программистов использует COM+ для управления транзакциями через базу данных, но COM+ предлагает множество других возможностей, позволяющих создать намного более масштабируемое и доступное приложение и упростить задачи программирования. Данная статья применяет практичный подход к COM+ (1.0 и 1.5), объясняя и показывая, когда и как можно использовать COM+ вместе с .Net.

Определение проблемы

Название COM+ - одно из его основных недостатков. Интерполяция словосочетания COM заставляет многих программистов ошибочно думать, что COM+ базируется на COM, и избегать использования старой технологии из нового сорта веб-приложения .NET. Несмотря на то, что для ряда случаев COM+ действительно основан на COM, использование его возможностей может внести огромный вклад в веб-приложение и сервер. Создатели .Net подумали о последствиях использования COM для доступа к приложению COM+ и создали CLR таким образом, чтобы доступ к компоненту .Net, регистрирующему в COM+, осуществлялся без использования COM. Такая архитектура позволяет использовать службы COM+, такие, как компоненты с поддержкой очередей, слабосвязанные события, организация пула, JITA (активизация "на лету"), SWC (службы без компонента) и другие, чтобы упростить задачи программирования.

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

Данная статья рассматривает COM+ 1.0 и 1.5. Упоминание COM+ означает, что средство существует в COM+ 1.0 и 1.5. Явное указание COM+ 1.5 означает, что средство существует только в версии COM+ 1.5 (серверы windows XP или .Net).

Структура статьи

•    Типы приложения Com+ и как они влияют на производительность приложения
•    Производительность
•    Доступ и ограничения
•    Придание масштабируемости приложению
•    Максимальная изоляция
•    Отслеживание компонентов и быстрое решение проблем
•    Перезапуск приложения
•    Масштабирование объектов
•    Дамп процесса
•    Организация одновременной работы разных версий приложения COM+
•    Поиск светлого будущего
•    Применение безопасности
•    Повышение мощности сервера и дохода приложения.
•    Отслеживание и сжатие использования лицензий.
•    Уведомление других при изменении состояния приложения
•    Сбор плодов COM+ без необходимости растить дерево COM+.
•    Уведомление ASP.NET из серверного приложения COM+.
•    Транзакции, просто к сведению.


Типы приложения Com+ и как они влияют на производительность приложения

COM+ может двумя путями разместить компоненты .Net: приложение библиотеки и приложение сервера. Приложение библиотеки выполняет компонент в вызывающем процессе, тогда как приложение сервера выполняет компонент в специальном процессе, созданном COM+, под названием Dllhost.exe. Тип приложения COM+ влияет на все составляющие размещенного компонента. Приложение сервера работает в отдельном процессе, влияя на общую производительность приложения, которому приходится пересекать границу процессов для вызова служб компонента. Межпроцессное взаимодействие является ведущим фактором в различиях касательно производительности и ограничений между приложениями библиотеки и сервера.

COM+ основан на контексте. Контекст является средой для объектов с одинаковыми требованиями к исполнению. Контекст может перехватить вызов метода или активацию объекта и вследствие этого выполнить одну из служб COM+. Чтобы зарегистрировать класс .Net в COM+, класс должен наследоваться от ServicedComponent. Реализация ServicedComponent базируется на дистанционной связи, перехватывающей вызов метода. Если CLR требуется для создания экземпляра нового производного объекта ServicedComponent, делается вызов управляемого C++. Вызов управляемого C++ CoCreateInstance, позволяющий COM+ привязать объект к неуправляемому контексту и задать неуправляемые службы, предопределенные для регистрации класса в каталоге COM+. CLR также способен использовать атрибуты, связанные программистом с классом, чтобы установить метаданные класса в COM+, если они не установлены ранее. Во время регистрации ключ InProcServer32, обычно указывающий на путь COM DLL или COM EXE, указывает на mscoree.dll, являющийся механизмом .NET JIT(just in time – точно вовремя) (как ни странно, mscoree.dll является COM DLL). Со времени обратного вызова CLR созданный фактический объект является настоящим управляемым объектом.

Описанный процесс происходит, когда требует объект библиотеки COM+, и в конце CLR создает чистый управляемый класс. Объекты, зарегистрированные как приложение сервера, получили другой путь экземпляра. Межпроцессный характер приложения сервера требует дистанционной связи и DCOM(распределённая модель компонентных объектов) для вызова зарегистрированного объекта из управляемого кода. На самом деле происходит два вызова дистанционной связи в ходе активации объекта: один для получения URI объекта сервера, а второй для фактической активации. Межоперационные вызовы COM производятся в ходе активации и демаршалинге данных. В обоих случаях (библиотека, сервер) объект является управляемым объектом, созданным CLR, только объект сервера требует дистанционной связи и DCOM для активации объекта и для каждого вызова для демаршалинга параметров. Влияние этих различий показано в разделе производительность.

Производительность

После объяснения шагов, касающихся активации приложения библиотеки и сервера, рассматривается, как каждая из этих опций влияет на производительность веб-приложения. Как сказано ранее, данная статья посвящена практичному подходу, поэтому одновременно с проверкой производительности приложений COM+ проверяются другие службы COM+, способные повлиять на производительность веб-приложения в определенных ситуациях. Эти службы включают в себя JIT, организацию пула объектов и поддержку синхронизации. Подробно они не разбираются, полное описание их смотрите в http://www.ondotnet.com/pub/a/dotnet/excerpt/com_dotnet_ch10/index.html?page=1 или в документациях MSDN.

Испытание производительности основано на обычном приложении ASP.NET, созданном в традиционной слойной архитектуре. Приложение ASP.NET состоит из 6 страниц:
1.    GetDataNoCom.aspx : страница, получающая около 20 записей из базы данных и отображающая их.
2.    GetDaataCom.apsx : страница, вызывающая класс, зарегистрированный в COM+, чтобы извлечь около 20 записей из базы данных и отобразить их.
3.    GetLargeDataNoCom.aspx : страница, получающая около 1000 записей из базы данных и отображающая часть из них
4.    GetLargeDataCom.aspx : страница, вызывающая класс, зарегистрированный в COM+, чтобы извлечь около 1000 записей из базы данных и отобразить часть из них.
5.    LongInit.aspx : страница, вызывающая ресурс с длительным временем инициализации.
6.    LongInitCom : страница, вызывающая класс, зарегистрированный в COM+. Класс com+ использует ресурс с длительным временем инициализации.

Каждый из объектов COM+ будет испытан во время работы в качестве библиотеки и сервера с JIT, организацией пула объектов и временем вызова методов. Испытание проведено на компьютере с одним процессором Intel 4 1,80ГГц и 500 Мб ОЗУ. Полученные числа - RPS (запросов в секунду), возвращенные ACT (испытание центра приложений). Каждое испытание выполняется 5 секунд с 10 одновременными пользователями.

Таблица1.0 результаты испытания
 

нетCOM+

библиотека

сервер
   

организация пула

JITA

время вызова

PRS

организация пула

JITA

время вызова

RPS

GetDataNoCom – 90 записей

300

X

X

X

X

X

X

X

X

GetDaataCom – 90 записей

X

-

-

-

233

-

-

-

111
 

X

+

+

-

200

+

+

-

105
 

X

+

+

+

200

+

+

+

105

GetLargeDataNoCom - 900 записей

50

X

X

X

X

X

X

X

X

GetLargeDataCom – 900 записей

X

-

-

-

49

-

-

-

36
 

X

+

+

-

48

+

+

-

28
 

X

+

+

+

48

+

+

+

28

LongInit

1

X

X

X

X

X

X

X

X

LongInitCom

X

-

-

-

1

-

-

-

1
 

X

+

+

-

0.3

+

+

-

100
 

X

+

+

+

0.3

+

+

+

100
                   
                   

Как видно в таблице 1.0, есть различие в производительности не COM+ страниц и страниц, использующих библиотеку COM+. Различия в производительности минимизируются, так как страница выполняет более трудоемкие задачи. Напротив, страницы, использующие приложение сервера COM+, в 2 раза медленнее, чем страницы, использующие приложения библиотеки COM+. Одно исключение – обработка задачи, требующей длительного времени инициализации, где использование организации пула резко повышает производительность. Подробно этот вопрос будет рассмотрен позже. Использование данных о времени вызова для отслеживания компонентов приложения никак не влияет на вывод страницы. Позже будет показано, как применять эти данные для проверки проблем приложения во время выполнения.

Использовать ACT полезно в процессе разработки. Проверка страницы на RPS по мере разработки помогает найти проблемы и узкие места в ходе разработки. Проблемы, обнаруженные рано в процессе разработки, решаются легче, чем когда процессы разработки завершены. Настоятельно рекомендуется максимально использовать ACT, чтобы хорошо понимать состояние приложения в каждой фазе разработки.

Доступ и ограничения

Помимо производительности, надо рассмотреть ограничения, о которых необходимо знать,  решив использовать приложения COM+. Ограничение касается только приложения сервера COM+ из-за его внепроцессной природы. Класс библиотеки сервера не имеет доступа к встроенному объекту ASP.NET. Это можно сделать, если многопоточное состояние страницы изменится на единственный поток с помощью атрибута ASPCOMPAT, но использование этого атрибута навредит производительности приложения.
Размещение сборки .Net в DLLHOST.exe, являющемся процессом, выполняющимся в каталоге системы, приводит к ограничению из-за того, что приложение ASP.NET и вызванная сборка сервера COM+, выполняющаяся в другом месте, заставляют программиста разместить сборки, содержащие общие данные (интерфейсы, перечисления, и т.д.) в GAC(глобальный кэш сборок). Помещение сборок общих данных в GAC предотвращает развертывание этих сборок в нескольких физических местах.

Использование дистанционной связи для вызова приложения сервера COM+ из приложения ASP.NET налагает еще несколько ограничений. Если ASP.NET вызывает класс COM+ и требует данные – все работает гладко, так как CLR обрабатывает дистанционную связь для регистрации класса COM+. Но если классу COM+ нужно создать обратный вызов к вызывающему приложению ASP.NET или вернуть ссылочный тип (например, DataReader), то  должно быть предпринято какое-то действие, чтобы сделать класс страницы Дистанционная связь сервером. Позже будет показано, как добиться такого поведения.
Еще одно ограничение, вытекающее из дистанционной связи, является требованием передачи параметров, поддерживающих сериализацию. Дистанционная связь сериализует объект, чтобы переместить его через канал дистанционной связи. Передача в качестве параметра объекта, не поддерживающего сериализацию, вызовет ошибку времени исполнения.

Из-за использования DCOM и дистанционной связи при каждом вызове для регистрации класса в качестве приложения сервера COM+ лучше использовать массивные, а не неряшливые вызовы. Лучше создать несколько вызовов с параметрами, а не использовать свойства для классов, вызываемых из приложений ASP.NET. Массивный вызов вместо неряшливого подходит только для классов «входной точки». Остальные классы, используемые в рамках обработки запроса, должны использовать классический объектно-ориентированный подход.


Придание максимальной доступности приложению

Одной из стратегических целей, тактикой достижения которых является .Net, является рынок корпоративного программного обеспечения. Microsoft хочет проникнуть в этот рынок, на котором многие годы господствовали Oracle и SUN (поставщики Java и сервера приложений java). Потребности корпоративного рынка отличаются от потребностей рынка электронной коммерции. Обычно корпоративное ПО применяется для обработки больших разных баз данных с набором приложений внутренней сети, являющихся единой большой программой для конечного корпоративного пользователя. Эти приложения (обычно десятки) размещаются на одном и том же сервере, являющемся частью кластера балансировки нагрузки. Создание набора приложений разными группами разработчиков, с большим объемом связи между ними, которые в итоге будут рассматриваться как единое приложение и размещаться на одном и том же сервере, требует отличающегося набора требований от создания одиночного клиент-серверного приложения или приложения электронной коммерции. Microsoft начинает выпускать все больше программных средств и средств разработки, помогающих предприятиям разрабатывать свое ПО. Одно из таких средств - COM+, один из вкладов COM+ - мощная поддержка доступности и масштабируемости.

Размещение множества приложений на одном и том же сервере очень выгодно для предприятия. Такая конфигурация обеспечивает лучшую производительность из-за связи между приложениями и экономит деньги (Представьте стоимость покупки и обслуживания сервера для каждого приложения). Но есть один крупный недостаток. Если часовая система отчетности даст сбой и потребит 100% ресурсов процессора, все остальные приложения, работающие в том же самом IIS, тоже пострадают. Такая ситуация может повредить доступность приложения и даже данных и должна предупреждаться или хотя бы отслеживаться и прекращаться.

Один из очевидных выводов из производительности и ограничений заключается в том, что лучше не использовать приложение сервера COM+. Несмотря на то, что этот вывод базируется на веских доказательствах, приложение сервера COM+ легко способно решить проблему доступности, но с издержками производительности. Большей частью издержки производительности неважны для корпоративного ПО, которое в крайнем случае должно обслуживать десятки тысяч пользователей, разделенных между тремя серверами или более.

Максимальная изоляция

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

По сути, IIS5 и IIS6 обеспечивают другой механизм изоляции. IIS 5.0 захватывает запрос к приложению .Net и посредством конвейера передает запрос специальному процессу для обработки приложений ASP.NET - aspnet_wp.exe. Есть только один процесс aspnet_wp на сервере, и каждое веб-приложение имеет свой собственный домен приложения внутри aspnet_wp. ASP.NET пользуется преимуществами такой архитектуры и перезапускает приложение путем перезапуска домена приложения веб-приложения. Хотя ASP.NET может перезапустить приложение в определенных ситуациях, администраторы не могут. Администратор может использовать механизм перезапуска веб-приложения ASP.NET при внесении любого изменения в каталог bin приложения. Этот обходной прием будет работать, только если приложение не обрабатывает входящий запрос. В таком случае перезапуск приложения произойдет сразу после завершения запроса. Если один из шагов обработки запроса войдет в бесконечный цикл, веб-приложение не перезапустится.

Такое поведение IIS5 вместе с внутрипроцессным режимом активации сборок, используемых веб-приложением, может привести к недоступности нескольких приложений, даже если всего одно приложение неправильно функционирует. Чтобы преодолеть данную ситуацию, администратор должен перезапустить процесс aspnet_wp, что в итоге перезапустит все приложения, работающие на сервере. Единственный способ предотвратить такую ситуацию – использовать расслоение и размещать слои, не являющиеся графическим пользовательским интерфейсом, как приложения COM+, чтобы администратор мог с помощью консоли управления COM+ перезапустить специальный процесс, не вредя процессу aspnet_wp.

IIS6 вводит пулы приложений, вмещающие несколько веб-приложений. Пулы приложений имеют свой собственный процесс w3_wp, который может перезапустить администратор, тем самым позволяя завершить одно веб-приложение без вреда для других. Данная опция IIS6 позволяет администраторам завершить одно приложение, но все еще лишена возможностей отслеживания, встроенных в COM+, позволяющих администраторам быстро найти неправильно работающую сборку.

Показывается изоляция на практике. Будет создано простое веб-приложение (AvailabilityCheck) со сборкой, содержащей один регистр класса в COM+. Этот класс содержит два метода - DoItRight и NeverEndingStory, содержащий бесконечный цикл. Веб-форма содержит две кнопки, каждая из которых вызывает метод класса.

 

Рисунок 1.0

//код класса
namespace AvailabilityCheckDll
{
   public class AC : System.EnterpriseServices.ServicedComponent 
   {
      public AC()
      {
      }
      public string DoItRight()
      {
         return DateTime.Now.ToString (); 
      }
      public string NeverEndingStory()
      {
         // моделировать незаконченную рекурсию
         for(;;)
         {
      
         }
         return DateTime.Now.ToString (); 
      }
   }
}
// код страницы
public class WebForm1 : System.Web.UI.Page
{
   protected System.Web.UI.WebControls.Button btnDoItRight;
   protected System.Web.UI.WebControls.Button btnNeverEndingStory;
   private void Page_Load(object sender, System.EventArgs e)
   {
   }
   +#region Web Form Designer generated code
   private void btnDoItRight_Click(object sender, System.EventArgs e)
   {
      AvailabilityCheckDll.AC oAc = new AvailabilityCheckDll.AC();
      Response.Write ( oAc.DoItRight ());
   }
   private void btnNeverEndingStory_Click(object sender, System.EventArgs e)
   {
      AvailabilityCheckDll.AC oAc = new AvailabilityCheckDll.AC();
      Response.Write ( oAc.NeverEndingStory());
   }
}

Запуск веб-приложения заставляет класс AC зарегистрироваться как приложение библиотеки. Нажатие на кнопку DoItRight возвращает страницу с напечатанной датой и временем. Нажатие на NeverEndingStory загружает процессор на 100%. Единственный способ завершить 100% использование процессора - перезапустить aspnet_wp (IIS5) или перезапустить пул приложений (IIS6). Теперь измените метаданные AC в консоли управления COM+, чтобы работать как приложение сервера, и нажмите кнопку NeverEndingStory. После того как вы заметите, что использование CPU достигло 100%, остановите приложение COM+. Использование CPU вернется к норме, и выведется страница с ошибкой с указанием какой-то проблемы в приложении. Данный сценарий показывает эффективность использования приложения сервера COM+. Вредоносный код легко останавливается без вреда для других веб-приложений.

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

Регистрация класса в качестве приложения сервера COM+ дает более доступные приложения и в сочетании с отслеживанием существенно сокращает период недоступности приложения. Только не забывайте, что регистрация класса в качестве приложения COM+ вредит производительности приложения. Прежде чем решить, регистрировать ли сборку в качестве приложения сервера, следует свериться с ACT (центральное испытание приложения) на RPS (запросов в секунду) и лишь затем принять решение.


Отслеживание компонентов и быстрое решение проблем

Приложение сервера COM+ предоставляет набор данных и статистику, позволяющую быстро локализовать вредоносный код. Если все сборки, используемые веб-приложением, загружены в домен приложений, только адрес памяти позволит узнать, где произошла ошибка (если вообще выдается сообщение об ошибке), путем передачи исключений вверх по иерархии и записи их в файл журнала. Даже если программист придерживается данной практики, администратор сервера вероятно не поймет эти журналы. Регистрация классов в качестве сервера COM+ поможет администраторам несколькими способами:
•    Информация о процессе. Каждый класс, регистрирующийся в качестве приложения сервера, получает свой собственный выделенный процесс. Консоль управления COM+ сообщает, чему равен идентификатор процесса у каждого приложения. С помощью этих данных можно найти сильно нагружающие процессор процессы в диспетчере задач. Сравнение идентификатора процесса (столбец идентификатора процесса добавляется из меню Вид->Выбрать столбцы) из диспетчера задач с видом состояния приложений COM+ поможет быстро определить, какое приложение COM+ виновно в интенсивном использовании процессора.
•    Информация о компоненте. Чтобы использовать эти данные, надо установить атрибут EventTrackingEnabled в объявлении класса. Установка этого атрибута дает статистику для каждого компонента приложения, которую можно посмотреть в виде состояния папки компонентов. Самые важные данные - CallTime. Этот параметр показывает, сколько времени в миллисекундах объект выполняет свою задачу. Используя эти данные, администратор может найти проблемные компоненты или компоненты, заставляющие приложение неправильно функционировать (компоненты с огромным временем вызова). Более того, если каждый компонент представляет собой один из слоев приложения, администраторы могут легко найти, находятся ли корни проблемы глубоко в базе данных или в слоях логики.

Как видно, данные о приложении и компонентах, экспортируемые COM+, могут использоваться администратором для минимизации времени отслеживания проблемы и максимизации общего времени доступности приложения. Как изоляция, данные о компоненте и приложении могут быть собраны, только если приложение назначено сервером (сбор времени вызова компонентов возможен, только если приложение назначено сервером. Другие статистические данные собираются для приложения библиотеки, но они не столь полезны, как время вызова).

С помощью предыдущего примера кода можно посмотреть, как описанные данные применяются на практике и помогают найти проблемный процесс и класс. Установите приложение COM+ на работу в качестве сервера и запустите веб-приложение. Нажмите кнопку NeverEndingStory. Когда использование процессора достигнет 100%, откройте диспетчер задач и переключитесь на вкладку процессов. Упорядочите данные по использованию процессора. Вверху списка должен быть DllHost.exe. Запомните идентификатор процесса DllHost.exe и откройте вид состояния консоли управления COM+ папки приложений COM+. Найдите приложение с тем же идентификатором процесса – вы обнаружите, что AvailabilityCheckDll соответствует тому же идентификатору процесса. Теперь, когда известно, какое приложение вызывает проблему, осталось найти класс-виновник. Откройте вид состояния компонентов приложения. Это приложение содержит только один класс, но сразу видно, что время вызова одного компонента продолжает расти. Этот компонент виновен в интенсивном использовании процессора.

Перезапуск приложения (COM+ 1.5)

Версия COM+ 1.5 еще больше повышает доступность и стабильность приложения COM+. Приложение COM+ может вызывать ожидаемые и неожиданные проблемы, такие как утечки памяти или использование немасштабируемого ресурса. COM+ позволяет администратору установить, в каких случаях приложение будет автоматически перезапускаться. COM+ позволяет установить перезапуск по времени жизни процесса, расходу памяти, количествe вызовов метода и активаций объекта.

Масштабирование объектов (COM+ 1.5)

COM+ 1.5 вводит новое средство, позволяющее масштабировать устаревшие однопоточные приложения (такие как компоненты, созданные с помощью VB 6.0). Это средство позволяет администратору установить количество процессов DllHost, запускаемых для конкретного приложения и обслуживающих входящие запросы. Если размер пула приложений больше одного, COM+ начинает распределять запросы между процессами DllHost по кругу. Можно посмотреть все процессы, в том числе их идентификаторы процесса, в папке работающих процессов консоли управления COM+. Наряду с повышением масштабируемости, организация пула приложений очень полезна для доступности и восстановления. Если отчего-то произошла ошибка в одном DllHost, новый запрос перенаправляется и использует другой DllHost из пула.

Дамп процесса (COM+ 1.5)

Полный дамп памяти процесса очень полезен для отслеживания, анализа и отладки. Дампы крайне важны для отыскания и исправления проблем, вызывающих исключения приложения. COM+ 1.5 решает эту проблему путем добавления вкладки, позволяющей администратору установить автоматическую генерацию дампа памяти процесса при возникновении исключения. Консоль управления COM+ позволяет установить местоположение файла дампа и количество файлов дампов, которое будет храниться до перемещения на диск. Кроме автоматической генерации файла дампа, можно сделать дамп памяти приложения в любой момент с помощью меню дампа в контекстном меню приложения в папке выполняющихся процессов. После создания файла дампа его можно открыть посредством WinDbg и изучить данные.

Организация одновременной работы разных версий приложения (COM+ 1.5 на сервере .NET)

Это средство есть только на серверах .Net. Необходимо подключить разделы com+ путем активации опции раздел в метке Опции компьютера в консоли управления COM+. Разделы позволяют администратору создать несколько разделов, каждый из которых вмещает приложение сервера или библиотеки с разной установкой метаданных. Данная опция позволяет разместить несколько версий приложения COM+ с разными данными каталога COM+ на одном и том же компьютере. Когда требуется активация компонента приложения COM+, COM+ решает активировать объект в разделе с помощью пользователя, активирующего компонент, и пользователей, прикрепленных к данному разделу. Эту возможность также можно применить для разделения данных между разными группами разработчиков или пользователей путем установки разной строки подключения в качестве строки конструктора COM+

Поиск светлого будущего

Следует надеяться, вы поняли, до какой степени приложение сервера COM+ помогает в создании более масштабируемых и доступных систем и, напротив, как приложение сервера COM+ вредит производительности преимущественно из-за участия DCOM в процессе активации и маршалинга. Следует надеяться, что Microsoft сообразит, и новые версии COM+ будут основаны на .Net и превратят DCOM в устаревший. До тех пор придется самостоятельно принимать решение о производительности или стабильности и доступности. В принципе, переключение с приложения сервера на библиотеку является всего лишь индикатором изменения типа активации, но на практике есть имитации сервера и небольшие изменения кода (показанные в тестовом приложении) между двумя типами активации. Рекомендуется учитывать ограничения и изменения кода при создании класса, размещаемого как компонент COM+. Такой подход оставляет за администратором и руководителем проекта решение того, как в итоге будет работать сборка.

.net форум