Новые возможности COM+ 1.5

Дмитрий Старостин,
специалист по разработке программных систем московского представительства Microsoft
dmitrys@microsoft.com

Включение сервера транзакций MTS (Microsoft Transaction Server) в состав пакета Option Pack for Windows NT 4.0 стало значительным шагом в эволюции COM-платформы для построения распределенных многоуровневых систем. МТS предоставил COM-разработчикам инфраструктуру для поддержки распределенных транзакций, интегрированной модели безопасности, пула нитей выполнения; позволил оптимизировать администрирование и конфигурирование.

С выпуском Windows 2000 все лучшие идеи, реализованные в технологиях COM и MTS, были интегрированы в новую среду выполнения COM-объектов, названную COM+. Инструментарий COM+ 1.0 стал неотъемлемой частью установки Windows 2000. К средствам поддержки транзакций и интегрированной безопасности новый инструментарий добавил сервисы синхронизации и поддержки пула компонентов. Появились возможности обработки событий COM+ и вызова компонентов через инфрастуктуру MSMQ (Queued Components, очередь компонентов).

В числе новшеств Microsoft Windows XP можно отметить новую версию служб COM+ 1.5. Хотя формально изменился только номер подверсии, разработчики и администраторы приложений найдут в COM+ 1.5 много полезных новшеств. В данной статье приводится обзор новых возможностей COM+, ориентированных на облегчение разработки, развертывания и администрирования приложений.

Развитие COM+ 1.5 шло в следующих направлениях:

• улучшение масштабируемости;
• управление опциями доступности компонентов;
• повышение управляемости;
• расширение программной модели.

В новой версии не только расширились функциональные возможности, но и значительно улучшился интерфейс консоли управления COM+ (рис. 1). Вот лишь некоторые новшества интерфейса, способные порадовать разработчика своим удобством. Различные типы приложений отображаются различными значками, запущенные в текущий момент приложения отображаются в отдельной папке, появилась папка DCOM Config, предназначенная для централизованного управления зарегистрированными на локальном компьютере COM-серверами (EXE-серверы), появилась возможность помещать в приложение COM+ помимо прочего еще и неконфигурируемые in-proc-компоненты.

Рис. 1. Интерфейс консоли управления службы COM+.

Итак, рассмотрим более детально новые возможности, предлагаемые COM+ 1.5.

Масштабируемость

Прежде всего необходимо отметить. что в новой версии появилась возможность управлять уровнем изоляции транзакции. В COM+ 1.0 транзакции всегда создавались с уровнем SERIALIZABLE. Это самый высокий уровень изоляции, который гарантирует корректность данных в любых сценариях. Естественно, чем выше уровень изоляции транзакции, тем больше требуется ресурсов для ее поддержания и тем ограниченнее масштабирование конкурентно выполняемых транзакций. В реальных ситуациях с помощью продуманного понижения уровня изоляции транзакций можно повысить масштабируемость и производительность системы в несколько раз. Если компонент не требовал самого высокого уровня изоляции, то при работе с COM+ 1.0 нужно было явно указывать это в коде и менять уровень изоляции через соответствующую команду менеджера ресурсов, участвующего в транзакции. Например, в случае с Microsoft SQL Server необходимо было выполнить команду SET TRANSACTION ISOLATION LEVEL. Теперь, в COM+ 1.5, уровень изоляции транзакции можно задавать для компонента в диалоге свойств консоли управления. При этом, если уровень изоляции указан явно и приходит запрос на создание компонента из транзакции с более низким уровнем изоляции, то будет возвращаться ошибка E_ISOLATIONLEVELMISMATCH.

Регулирование пула процессов, в которых создаются компоненты, дает еще одну возможность улучшения масштабируемости. В COM+1.0 компоненты из одного приложения COM+ создавались в одном процессе. Разработчики на "чистом" COM имели возможность управлять числом создаваемых процессов на уровне фабрик классов. Версия COM+ 1.5 дает такую возможность и разработчикам COM+- параметры пула процессов задаются в диалоге настройки. Это полезно для изоляции сбоев в компонентах. Исключение в компоненте приведет к завершению только одного экземпляра процесса и не помешает функционировать объектам, созданным в других процессах. Кроме того, пул процессов в некотором смысле реализует балансировку загрузки между процессами в рамках одного физического сервера. Отметим, что разработчику компонентов необходимо учитывать возможность их запуска в разных процессах при обращении с ресурсами – будь то файлы, семафоры, системный реестр (Registry) или что-либо другое, – теперь при соответствующих настройках обращение к ресурсам может происходить из разных процессов.

Управление опциями доступности компонентов

Несмотря на совершенствование методик разработки и тестирования, программы по-прежнему содержат ошибки. И, увы, с увеличением сложности проектов вероятность появления ошибок повышается. Зачастую источниками ошибок становятся не освобожденные после использования ресурсы (всем хорошо известные "утечки памяти"). При автономной работе компонентов в течение долгого времени даже небольшие утечки ресурсов снижают производительность системы и могут привести к ее останову при исчерпании всех ресурсов. Работая с приложениями COM+ 1.0, администраторы информационных систем практически не имели средств для управления автоматическим перезапуском компонентов; в COM+ 1.5 такие средства появились. В окне свойств приложения на вкладке Pooling&Recycling можно задать события, при которых приложение COM+ будет автоматически перезапущено (рис. 2). Перезапуск может происходить по истечении определенного периода времени, при превышении лимита используемой оперативной памяти, при достижении заданного количества запросов на создание объекта или обращений к его методам и свойствам. Важно отметить, что по достижении граничных условий COM+ перенаправляет все запросы на создание объектов в новый процесс и ждет, пока клиенты освободят ссылки на объекты в старом процессе, чтобы его завершить. Однако ожидание не будет бесконечным – его продолжительность также можно задать на вкладке Pooling&Recycling (Expiration Time). Дополнительно COM+ выдает уведомление о необходимости перезапуска приложения через механизм COM+ событий. Если клиентское приложение должно хранить ссылку на объект длительное время, то оно должно подписаться на соответствующее событие и при получении уведомления заново создать объект (COM+ создаст его уже в новом процессе). Задавать условия перезапуска можно не только через интерфейс консоли управления, но и из программы. Инструментарий COM+ Admin SDK содержит методы для принудительного перезапуска приложения COM+, что позволяет реализовать свою логику для определения условий необходимости перезапуска.

Рис. 2. Настройка параметров перезапуска компонентов.

При разработке может потребоваться запускать приложение COM+ как сервис. Процесс создания сервисов в Windows 2000 был достаточно сложен, но теперь, в Windows XP c COM+ 1.5, вы можете установить соответствующий флажок в интерфейсе управляющей консоли, чтобы процесс, в котором будут создаваться компоненты, был запущен как служба. Для таких приложений COM+ существуют некоторые ограничения – они не могут использовать пул процессов и возможности перезапуска. Запуск как сервис – это единственная возможность для приложения COM+ работать от имени Local System, что дает приложению все права на локальном компьютере.

В соответствии с концепцией XML Web Services (см. статью "Новый универсальный клей – Web Services", "BYTE/Россия" № 9'2001, с. 60) компоненты должны раскрывать свои интерфейсы через протокол SOAP (Simple Object Access Protocol). Платформа Microsoft .NET предоставит инструментарий для разработки и использования XML Web Services. Но как быть с инвестициями в разработку компонентов на базе COM-технологии? SOAP Toolkit (дополнительный add-in для Visual Studio 6.0) позволяет при минимуме дополнительного программирования "обертывать" COM-объекты для раскрытия их интерфейсов посредством SOAP. В COM+ 1.5 появилась еще одна возможность – выбрать в диалоге параметров приложения COM+ опцию uses SOAP на вкладке активации (рис. 3). COM+ автоматически сгенерирует код WSDL (Web services description language), создаст виртуальный каталог в IIS и вызовет компонент, когда SOAP-запрос будет получен сервером. SOAP накладывает некоторые ограничения на используемые компоненты: в частности, они не могут участвовать в транзакциях.

Рис. 3. Опции активации приложения COM+.

Повышение управляемости

Через консоль управления COM+ 1.5 администратор теперь имеет возможность приостанавливать приложения и компоненты. Когда приложение приостановлено, все запросы на создание компонентов из него будут заканчиваться возвращением кода ошибки E_APP_DISABLED. При этом клиентская программа, имеющая к моменту приостановки приложения ссылку на созданные компоненты из этого приложения, будет работать и дальше. Можно приостанавливать либо приложение целиком, либо отдельные компоненты в его составе. Эта возможность прежде всего используется для обновления версий компонентов или переноса их на другой компьютер. Если раньше для решения этих задач приходилось завершать приложения COM+, теряя ссылки на объекты в активных клиентах-приложениях, то теперь можно решать задачи текущего администрирования и поддержки более деликатными методами.

COM+ 1.5 расширяет арсенал разработчика для отладки и анализа компонентов, позволяя сохранить дамп памяти приложения. Эта возможность может оказаться особенно полезной в рабочей системе, где нельзя воспользоваться отладчиком. Непосредственно дамп памяти записывает утилита userdump.exe из состава Windows Resource Kit. Такие параметры, как путь сохранения файлов с дампами и максимальное число файлов (по достижении которого более ранние файлы начнут перезаписываться), задаются через вкладку Dump. Имена файлов будут генерироваться автоматически на основе глобального уникального идентификатора (GUID) приложения. Можно задать генерацию дампа непосредственно при аварийном завершении (через выбор опции на вкладке настройки параметров) или инициировать через вызов метода DumpProcess интерфейса ICOMAdminCatalog2. Описание и примеры использования административных интерфейсов COM+ можно найти в пакете COM+ Admin SDK.

Перейдем к одной из самых интересных новых возможностей СОM+ 1.5. В предыдущей версии каталог приложений был плоским с точки зрения иерархии, а права на создание компонентов предоставлялись всем пользователям, имеющим доступ к службам COM+. Конечно, можно было определять права пользователя с помощью управления ролями или другими способами, но в любом случае делать это нужно было программным способом. Более того, технология не позволяла иметь на одном физическом компьютере компонент с одним идентификатором CLSID в разных приложениях. Введение понятия разделов для приложений COM+ позволяет преодолеть эти недостатки. Фактически раздел приложений COM+ представляет собой группу приложений (рис. 4). Разделы организуются в иерархию, и информация о разделах хранится, как нетрудно предположить, в Active Directory. Права на создание и доступ внутри раздела задаются на уровне пользователей Active Directory. Можно разместить один и тот же компонент (с одним и тем же CLSID!) в различных разделах, и для разных пользователей компонент будет создаваться в зависимости от прав пользователей на раздел. Разделы приложений COM+ могут использоваться, например, в сценариях плавного обновления версий, когда основная часть пользователей работает со старой версией компонента, а небольшая группа пробует работать с новой версией, и физически это происходит на одном компьютере. Распределение прав на разделы влияет не только на создание компонентов, но и на их администрирование (через консоль управления или программным путем). Например, внедряя приложение, выполненное сторонними разработчиками, администратор может создать отдельный раздел COM+ и предоставить доступ к нему представителям сторонней фирмы, не беспокоясь, что будут затронуты (случайно или преднамеренно) настройки других приложений COM+. Последний сценарий разграниченного администрирования приложений COM+ применим и для корпоративных разработок, когда администраторы и разработчики могут конфигурировать только те приложения, к которым у них есть доступ. Разделы COM+ представляют собой мощное средство для полного изолирования приложений на одном компьютере.

Рис. 4. Разделы приложений COM+.

Расширение программной модели

Как быть разработчику, если для разных целей он хочет использовать один и тот же компонент, но с разными настройками приложений COM+? В рамках COM+ 1.5 эта проблема решается с помощью так называемых компонентов-синонимов. Механизм COM+ 1.5 создает синоним компонента, задавая новые идентификаторы PROGID и CLSID и параметры конфигурации. Есть возможность создавать синонимы из управляющей консоли, при этом указывается новое приложение COM+, которое будет содержать синоним и новые конфигурационные параметры. С точки зрения клиентских приложений оригинальный компонент и компонент-синоним – это два разных объекта, но в действительности при обращении к компоненту-синониму среда COM+ создает объект оригинального компонента с настройками компонента-синонима.

Приложения, разработанные в архитектуре COM-компонентов, не только применяют COM для раскрытия внешних интерфейсов, но и реализуют в виде компонентов COM внутренние объекты, используемые лишь данным конкретным приложением. Такой подход позволяет рассматривать приложение как совокупность взаимосвязанных объектов, имеющую внешние и внутренние интерфейсы. В COM+ 1.0 не было возможности ограничить доступ к внутренним компонентам приложения через административные настройки, без дополнительных приемов программирования. Все интерфейсы (в терминах объектно-ориентированного программирования) были публичными (public). В COM+ 1.5 появилась возможность пометить компонент как персональный (private) для содержащего его приложения COM+. Это значит, xnj запросы на создание компонента будут удовлетворяться, только если они пришли из компонентов в рамках этого же приложения.

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

Заключение

Как мы видим, COM+ 1.5 добавляет новые и расширяет существовавшие в версии 1.0 возможности построения компонентов уровня бизнес-логики в многоуровневых, масштабируемых приложениях.

Скептики могут спросить, зачем вообще улучшать возможности COM+ (и тем более рассказывать об этом на страницах журнала), если на смену COM и COM+ вот-вот придет технология .NET со своими объектами? В ответ на это прежде всего заметим, что для поддержки транзакций, балансировки и других сервисов компоненты .NET будут использовать сервисы COM+, обращаясь к соответствующим объектам CLR (Common Language Runtime) в подпространстве имен System.EnterpriseServices. И другого пути обеспечить работу компонентов .NET с транзакционными сервисами нет (во всяком случае пока).

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

Технология COM+ не умерла; Microsoft поддерживает и продолжает развивать сервисы COM+, что доказывает и новая версия COM+ 1.5, поддерживаемая в Windows XP. И я уверен, что это не последняя версия COM+.