COM+

COM+ является слиянием COM- и MTS- моделей программирования, таким образом справедлива формула:

COM + MTS = COM+

Базовая программная модель и того, и другого являются идентичными: разрабатываются компоненты "в процессе", в них выставляются интерфейсы, для обеспечения автоматизации реализуется IDispatch, реализуется код для регистрации, т.е. в рамках новой парадигмы нужно делать то же, что делалось и ранее. Однако в дополнение к этому появились новые сервисы, значительно расширяющие возможности приложений.

COM был создан как компонентная технология уровня изолированной рабочей станции. Потом, с реализацией распределенного COM в NT4 (DCOM), эта технология получила развитие в направлении поддержки удаленных обращений к компонентам. MTS создавался для обеспечения работы серверных компонент и устранения некоторых недостатков DCOM. COM+ появился для унификации и объединения COM, DCOM и MTS в согласованную технологию, понятную и удобную для реализации приложений корпоративного уровня.

ПРИЛОЖЕНИЯ COM+

COM+ приложение является основной единицей для защиты и администрирования компонент. COM+ приложение - это множество COM компонент, которые выполняют согласованные функции. COM класс представляет собой именованный набор интерфейсов (один или несколько). COM объект - это созданный экземпляр COM класса. COM компонент - это бинарная единица кода, функцией которого является создание COM объекта. Интерфейс - это группа логически взаимосвязанных функций, называемых, методами. Таким образом, можно сказать, что каждый из компонент состоит из интерфейсов, который, в свою очередь, состоит из методов. COM класс идентифицируется уникальным идентификатором CLSID, интерфейс - IID.

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

• Определение пространства развертывания COM компонент
• Общее конфигурирование COM компонент, включая службу безопасности, балансировку загрузки компонент, диспетчеризацию очередей сообщений компонент
• Разработчик более не беспокоится об обеспечении сохранения атрибутов компонент - это задача операционной системы
• Компонентные DLL загружаются в процесс по усмотрению разработчика
• Создание и управление потоками выполнением компонент
• Осуществление доступа к контексту объекта за ресурсами позволяет автоматически ассоциировать их с контекстом объекта

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

• Определение COM классов и их воплощение
• Группировка классов в компоненты
• Определение множества COM+ сервисов, необходимых для компоненты
• Разработка COM+ приложения
• Интеграция компонент в COM+ приложение, уже существующее или новое
• Определение правильного множества атрибутов для каждого класса. Эти атрибуты представляют зависимости компонент от используемых сервисов (транзакции, очереди и т.д.).
• Установка системы защиты (права и роли классов, методов, интерфейсов)
• Конфигурация переменных окружения для классов и приложений
• Подготовка приложения для распространения и развертывания
• Администрирование COM+ приложений
• Инсталляция приложения на машине администратора
• Установка переменных окружения (членов групп-ролей и т.д.)
• Создание брокеров (proxy) приложения (если приложение должно быть доступно удаленно)
• Тестирование приложения
• Задание параметров кластеризации

Давайте посмотрим, какие новые возможности привнес COM+ в уровне бизнес логики.COM+ позволяет увеличить надежность и масштабируемость приложений применяя балансировку нагрузки компонент*¹ и компоненты с поддержкой очередей. Будет показано как и зачем используются не жестко связанные события и как можно интегрировать новую модель защиты в приложения. Мы рассмотрим также некоторые проблемы, связанные с миграцией приложений от NT 4.0 к Windows 2000/COM+.

СЛУЖБЫ COM+

Не жестко связанные события

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

Неплохо ведь, чтобы сообщали, о каких-то интересных изменениях в мире. Не будь этой возможности, вам пришлось бы периодически вызванивать биржевого маклера, чтобы выяснить последние цены. Можно избавить себя от этой головной боли, если дать брокеру свой номер телефона и попросить, чтобы он сообщал вам, когда что-либо на бирже изменится. В терминах СОМ, подписчик (абонент) обеспечивает издателя интерфейсом, а издатель вызывает метод этого интерфейса, когда происходит что-то его интересующее. Такой подход используют элементы управления ActiveX для генерации событий в своих контейнерах. Это так называемое жестко связанное событие (tightly coupled event). Подписчик знает точно, у какого издателя запрашивает извещение (контейнер знает CLSID) и механизм для соединения с ним (ICONNECTIONPOINTCONTAINER и интерфейсы ICONNECTIONPOINT). Жестко связанные события неплохо работают в приложениях масштаба одной рабочей станции, но имеют ряд недостатков, если используются в системах масштаба предприятия. Например, может потребоваться чтобы подписчик был способен делать свои запросы, во время, когда издатель дезактивирован, чтобы издатель был способен начать работу с подписчиком, во время инициирования события. Другое решение - использовать компоненты с поддержкой очередей вместо прямых соединений для посылки извещений о событиях. Еще одна проблема с жестко связанными событиями состоит в том, что подписчик должен знать точный механизм взаимодействия с каждым издателем, и эти механизмы могут радикально отличаться.

СОМ+ служба событий - это сервис операционной системы, который согласовывает и связывает подписчик и подписчиков. СОМ+ служба событий обеспечивает инфраструктуру, которая делает простыми "публикацию" и "подписку" к данным.

Издатель - это любая программа, делающая СОМ вызовы, которые инициализируют события, а абонент (подписчик) - это СОМ+ компонент, который принимает СОМ вызовы, представляющие собой события издателя. Абонент осуществляет интерфейс как COM сервер; издатель делает вызовы как СОМ клиент.

Событие представляется как одиночный вызов метода СОМ интерфейса, инициированный издателем и доставленный службой событий (event service) нужному подписчику или подписчикам. Единственное отличие от классического СОМ - наличие промежуточной службы событий, отслеживающей множество подписчиков, ожидающих вызова, и направляющей вызовы этим подписчикам, При этом специфическая информация об издателе не нужна.

Создание одиночного запроса события известно как возбуждение события. В документации термин "публикация" используется в как синоним для термина "возбуждение". Соединение между издателем и подписчиком осуществляется классом события. Класс события - это СОМ+ компонент, содержащий интерфейсы и методы, которые издатель вызывает для инициирования события и которые должен реализовывать подписчик, если он желает получить извещение о событии. Интерфейсы и методы, обеспеченные классом события называются интерфейсами события и методами события. Средствами СОМ+ библиотек типов устанавливаются, какие СОМ+ интерфейсы и методы должен содержать класс события. Классы событий хранятся в СОМ+ каталоге; помещаются туда или непосредственно программами-издателями или административными инструментальными средствами. Подписчик объявляет о своем намерении принимать события от издателя, регистрируя подписку в службе событий СОМ+. Подписка - это структура данных, которая обеспечивает службу событий информацией о получателе события. Она определяет, от какого класса события, и какого интерфейса или метода, в этом классе события, подписчик хочет получить вызов. Подписки хранятся в СОМ+ каталоге, помещаются туда или непосредственно программами-подписчиками или административными инструментальными средствами. Постоянные подписки сохранятся и после рестарта операционной системы; временные - нет. Когда издатель хочет инициировать событие, он использует стандартные объектные функции создания объекта требуемого класса события, типа CoCreate или CreateObject. Этот объект, известный как объект события, содержит реализацию системы событий требуемого интерфейса. Затем издатель вызывает метод события для инициирования события подписчиком. Система событий просматривает СОМ+ каталог, и находит всех подписчиков, которые имеют зарегистрированные подписки к этому интерфейсу и методу. Далее система событий соединяется с каждым подписчиком и вызывает в каждом указанный метод. Поскольку обычно извещения о событии получают более одного подписчика, методы событий не могут возвращать никакого значения, кроме Success или Failure типа HRESULTs. Такие же самые ограничения касаются методов интерфейса очередей компонент. Таким образом, по существу любой СОМ клиент может стать издателем, и по существу любой СОМ+ компонент может стать подписчиком. При этом ни том, ни в другом случае он не обязан ничего знать о действиях, выполняющихся службой событий.

Компоненты с поддержкой очередей

Конечно же, проще разрабатывать распределенные приложения, если нет необходимости в том, чтобы все его компоненты выполнялись одновременно. Очереди Компонент СОМ+ обеспечивают инфраструктуру отложенного действия. Связь между клиентом и сервером поддерживается службой Очередей Сообщений Microsoft.

Например, предположим, что в приложении почтового обслуживания склада исполнитель заказа по телефону говорит с заказчиком и вносит его заказ на своей рабочей станции. Одни этапы этой операции должны быть выполнены синхронно, а другие - нет. Например, проверка возможности принятия заказа (или способность склада принять заказ) должна быть выполнена немедленно. Другие части операции не нуждаются в синхронном выполнении. Например, нет никакой нужды ни для заказчика, ни для оператора-исполнителя заказа ждать передачи заказа компьютеру в отделении отгрузки. Что действительно необходимо - некоторый способ для компьютера оператора-исполнителя заказа оставить сообщение для транспортного компьютера. Когда транспортный компьютер будет делать back up или "разгребать" невыполненные заказы, он найдет эти сообщения и обработает их. Взаимодействие с компьютером отделения отгрузки должно происходить асинхронно. СОМ+ компоненты с поддержкой очереди обеспечивают такую инфраструктуру автоматически.

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

Компоненты с поддержкой очередей (Queued Components), в дальнейшем QC службы СОМ+. Клиентское приложение создает "поставленный в очередь" объект, таким же образом, как это делается для любого СОМ объекта. Поставленный в очередь объект так же предоставляет СОМ интерфейс своему клиенту. Классический DCOM использует синхронный RPC (удаленный вызов процедуры), чтобы переместить байты от одного компонента к другому, представляющие СОМ вызов. С использованием QC, взаимосвязь между клиентской функцией-заместителем и серверной функцией-посредником осуществляется Службой Поддержки Очередей Сообщений Microsoft (MSMQ).

Когда клиент инициирует объект с поддержкой очередей, он связывается не напрямую с СОМ объектом, а с call recorder (с вызывным записывающим устройством). Клиентское приложение осуществляет СОМ вызовы как обычно, но вместо немедленной передачи через RPC, эти вызовы сохраняются на клиентской стороне. Когда клиент дезактивирует компонент QC используя MSMQ, он асинхронно пересылает пакет сохраненных СОМ вызовов на компьютер, который содержит требуемый серверный компонент. Конфигурация проверяется при чтении сервером сообщения из очереди. Сервер использует MSMQ для чтения сообщения, содержащего пакет СОМ вызовов, посланных клиентом. Сервер инициирует player component (компонент-проигрыватель), который создает реальный СОМ объект и инициирует сохраненные вызовы. Разработчику не требуется знания подробностей MSMQ. Клиентское приложение совершает СОМ-вызовы в обычном режиме, а лежащая в основе системная инфраструктура берет на себя корректность их выполнения, даже если клиент и сервер не выполняются синхронно.

Реализация компонент с поддержкой очередей достаточно проста. Нужно создать СОМ компонент любым удобным для вас способом, используя любые инструментальные средства и сделать несколько изменений в семантике интерфейсов (по существу избавиться от выходных параметров). Затем, следует установить компонент в СОМ+ приложение, отметить его интерфейсы как поддерживающие очереди, используя Component Services snap-in (Службу Компонент). СОМ+ возьмет заботу о прослушивании входящих MSMQ сообщений от клиентов и о вызове методов компонент при их появлении этих вызовов. Все эти подробности прозрачны для вас и обеспечиваются службой QC. Так реализация компонент, соответствующих специфической бизнес логике, может наследовать инфраструктуру операционной системы.

COM+ безопасность

Еще одно значительное усовершенствование, которое обеспечивает СОМ+, лежит в области защиты. С появлением DCOM как части Windows NT 4.0, защита стала реальным результатом для разработчиков компонент. Хотя DCOM-поддержка удаленного вызова сделала реальным проектирование распределенных приложений, стоимость создания защищенных приложений сильно увеличилась. МТS несколько помог в этой области, введя концепцию системы защиты на основе прикладных ролей (role-based security). Система защиты на основе прикладных ролей позволяет разработчикам приложений создавать различные классы полномочий, или ролей. Каждый пользователь приложения относится к одному или нескольким классам полномочий. Роль-основанная защита позволяет разработчику сосредоточиться на проблемах безопасности прикладного уровня вместо нижнего уровня. Однако МТS обеспечивал достаточно ограниченную поддержку по сравнению с СОМ+.

Как и MTS СОМ+ служба безопасности обеспечивается посредством концепции ролей. Конечно, если это не удовлетворяет требования вашего приложения, Вы можете продолжать писать NT код защиты нижнего уровня. Это тот случай, когда роль-основанная защита не эффективна (например, per-instance security - система защиты на основе экземпляров объектов), но СОМ+ обеспечивает обширную поддержку для impersonation and cloaking, чтобы помочь в этом случае. Цель архитектуры защиты СОМ+ изолировать, в максимально возможной степени, проблемы безопасности нижнего уровня. При разработке защищенного СОМ+ приложения, Вы начинаете с создания системы авторизации. Эта система описывает различные роли и их разрешенные действия в пределах Вашего приложения. После установки прикладной системы защиты, Вы разделяете ваше приложение на его отдельные компоненты. Каждом пользователю приложения будет назначена одна или более ролей, указывающих уровень их полномочий или доступа. Используя СОМ+ Вы можете назначать роли определенным компонентам, интерфейсам и методам в пределах вашего приложения. Клиентский доступ к каждому из этих объектов управляется СОМ+ во время выполнения. Это - мощная методика, в которой СОМ+ осуществляет систему доступа для вашего приложения. Другой важной особенностью является то, что установка и обслуживание этой системы осуществляется декларатирвно (то есть, внешне для кода вашего компонента). Так как СОМ+ обеспечивает детали контроля доступа нижнего уровня, система может управляться административно, намного позже после разработки самого приложения. Потребителям даны роли; компонентам, интерфейсам и методам - назначены роли.

Использование декларативной, роль-основанной защиты будет работать во многих прикладных сценариях, но в случаях, где это не делается, Вы можете добавить логику защиты для ваших компонент также, как мы это делали выше в коде примера МТS. Программно, ролевая защита в СОМ+ усилена объектами контекста вызова. Объект контекста вызова связан с каждым вызовом и содержит информацию относительно числа вызывающих программ в вызывной цепочке, а также и о подлинности каждой вызывающей программы.

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