Добрынин В.Ю. Технологии компонентного программирования

Подождите немного. Документ загружается.

z Уровень аутентификации, который будет использован в данном клиентском приложении по умолчанию

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

z Указатель на структуру, где для каждого из поддерживаемых данным приложением сервисов аутентификации (Kerberos, NT

LAN Manager, ...), задается сервис авторизации (NULL для Kerberos) и аутентификационная информация. Для Kerberos это:

{ Имя пользователя

{ Пароль

Возможность задания аутентификационной информации позволяет клиентскому приложению пользоваться правами не того

пользователя, который запустил это приложение, а пользователя, чьи данные указаны при вызове

CoInitializeSecurity.

В случае, если клиентское приложение смогло запустить серверное (условия этого будут обсуждаться позднее), оно получит

прокси на запрошенный интерфейс. Уровни аутентификации и имперсонализации задаются на уровне прокси. Первоначально они

определяются значениями, принятыми по умолчанию, но могут быть изменены самим клиентом.

Значение уровня аутентификации определяется в результате переговоров клиентского и серверного

приложений. Именно,

итоговый уровень аутентификации равен максимальному из уровней аутентификации по умолчанию, определенными клиентским

и серверным приложениями. Уровень имперсонализации определяется исключительно клиентским приложением.

Возможность динамического изменения установок уровня безопасности основана на использовании интерфейса

IClientSecurity. Если разработка серверного приложения сопровождалась подготовкой IDL файла с описаниями всех

интерфейсов всех классов, включенных в приложение, то прокси каждого интерфейса ( код которого сгенерирован Microsoft

IDL), реализует интерфейс

IClientSecurity. Таким образом, получив указатель на любой интерфейс некоторого объекта

серверного приложения, клиентское приложение может (используя

QueryInterface) получить указатель на IClientSecurity.

Данный интерфейс имеет следующие методы:

z QueryBlanket

Используется для получения информации о текущем уровне безопасности, обеспечиваемом для всех вызовов, проходящих

через данный прокси

z SetBlanket

Используется для задания нового уровня безопасности, который будет обеспечиваться для всех вызовов через данный

прокси

z CopyProxy

В некоторых случаях удобно использовать различные уровни безопасности при вызове различных методов одного и того же

интерфейса. Например, вызов метода, среди параметров которого задается номер кредитной карты, должен выполняться с

наивысшим уровнем аутентификации, при котором шифруются все передаваемые данные. Однако, использование такого

уровня при выполнении всех вызовов через данный интерфейс

может быть слишком накладно. Используя метод CopyProxy

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

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

Еще один способ динамического задания уровня безопасности связан с заданием необходимого уровня безопасности при вызове

функции построения нового серверного объекта. Напомним, что при вызове функции

CoGetClassObject один из входных

параметров является указателем на структуру

COSERVERINFO. До настоящего момента мы полагали, что этот параметр равен NULL.

В этом случае имя машины, где установлено серверное приложение, ищется в реестре машины клиента, а требования к уровню

безопасности со стороны клиента определяются уровнем безопасности по умолчанию, заданным администратором локальной

машины.

Желая использовать иные, чем по умолчанию, требования к уровню безопасности, клиентское приложение может вызвать

функцию

CoGetClassObject с указателем на структуру COSERVERINFO, содержащую, в частности, следующие данные:

z Используемый при работе с данным объектом сервис аутентификации (например, Kerberos)

z Сервис авторизации (NULL в случае Kerberos)

z Уровни аутентификации и имперсонализации

z Указатель на структуру с аутентификационными данными:

{ Имя пользователя

{ Пароль

{ Домен

В результате, при построении нового серверного объекта клиентское приложение получит прокси настроенный на

специфицированный в

COSERVERINFO уровень безопасности. Конечно, как и раньше, его можно динамически менять через

интерфейс

IClientSecurity.

Задание уровня безопасности на стороне сервера

Конфигурируя серверное приложение, администратор должен задать (например, с помощью Component Services) ряд параметров,

определяющих требования к уровню безопасности со стороны данного приложения:

z Будет ли контролироваться доступ к приложению? Если будет, то на каком уровне : только на уровне процесса или также и

на уровне компонент?

При контроле доступа к приложению только на уровне процесса никакая информация об используемом уровне

безопасности не будет включена в контекст объекта. Это делает невозможным наиболее тонкий программный контроль

безопасности

. Стандартным для COM+ является второй вариант, когда уровень доступа контролируется и на уровне

отдельных компонент, интерфейсов и методов. В этом случае в контекст объекта включается информация, которая делает

возможным программное управление безопасностью.

z Уровни аутентификации и имперсонализации

Заданный уровень аутентификации будет использоваться при переговорах между клиентским и серверным приложениями

относительно реально используемого уровня аутентификации (используется максимальный из уровней аутентификации,

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

приложения будет вызывать другое серверное приложение, выступая в роли клиента.

z Идентификационные данные

Исполняемое серверное приложение выступает в роли принципала со своими именем, паролем, SID. Ранее (в COM)

серверное приложение могло запускаться под идентификацонными данными запустившего его клиента, но такое решение

было признано немасштабируемым. В COM+ администратор выбирает один из двух вариантов:

{ Интерактивный пользователь

В этом случае запускаемое серверное приложение будет исполняться под идентификационными данными (и с

правами) пользователя, имеющего в данный момент интерактивный сеанс на машине, где установлено серверное

приложение. Это имеет свои плюсы и минусы. Удобен этот режим для отладки, для интерактивных приложений.

Однако для неинтерактивных приложений этот способ опасен. Во

-первых, серверное приложение может получить

права администратора, если администратор в данный момент вошел в систему. Во-вторых, при выходе

интерактивного пользователя из системы, серверное приложение, запущенное под идентификационными данными

данного пользователя, будет также завершено.

{ Заданный пользователь

В этом случае администратор задает для конкретного серверного приложения уникальные имя и пароль, регистрируя

приложение как нового пользователя в системе с определенными правами. Передача прав клиента серверному

приложению возможна через механизм имперсонализации.

z Роли

В COM+ механизм ролей используется при авторизации клиентов. Авторизация клиента означает выяснение его прав,

связанных с запуском серверного приложения, с вызовом того или иного метода серверного объекта. При

конфигурировании серверного приложения администратор определяет список ролей, которым могут принадлежать

клиенты. Далее к каждой роли приписываются те или иные пользователи, зарегистрированные в домене

. Удобно

приписывать к одной роли целую группу пользователей (с заданным SID). Одной роли можно приписать многих

пользователей, и один пользователь может исполнять несколько ролей. Классические примеры ролей: клерк, менеджер.

После распределения пользователей по ролям (относительно данного серверного приложения), администратор может

приписать определенные роли приложению в целом, отдельным его компонентам, интерфейсам и

методам. В результате,

доступ к некоторому ресурсу (компоненту, интерфейсу, методу) получают только те клиенты, которые выполняются с SID

пользователя, исполняющего соответствующую роль.

Приписывание роли некоторому ресурсу означает, что эта же роль приписывается и всем ресурсам, входящим в данный

ресурс. Например, приписывание некоторой роли всему приложению означает, что всем его компонентам, их интерфейсам

и методам приписана эта же роль. Это ограничивает возможность более тонкого контроля доступа (программируемого

контроля) к компонентам приложения. Следует приписывать роли отдельным компонетам, интерфейсам и методам. В этом

случае разнообразная связанная с безопасностью информация будет включена в контекст соответствующих объектов, что

позволит выполнять программный контроль за доступом.

В связи с

рассмотренным только что вопросом о ролях уместно более подробно остановиться на программируемом контроле

доступа к приложению. Механизм ролей позволяет разрешить или запретить вызов некоторого метода некоторого серверного

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

контроль на доступом, учитывающий не только роль клиента, но и

значения параметров, которые этот клиент задал при вызове

метода. В этом случае не обойтись без программируемого контроля на стороне сервера.

С каждым вызовом некоторого метода серверного объекта связан так называемый контекст безопасности вызова (конечно, для

этого должны быть заданы роли, и некоторая роль должна быть приписана этому методу или содержащему

его интерфейсу,

компоненту, но не всему приложению). Имеется интерфейс

ISecurityCallContext, через который можно получить доступ к

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

CoGetCallContext. В качестве входного параметра задается идентификатор запрашиваемого интерфейса

(

IID_ISecurityCallContext), через выходной параметр возвращается указатель на этот интерфейс.

Для нашей задачи контроля доступа к методу в зависимости от параметров можно использовать следующие методы данного

интерфейса:

z IsSecurity Enabled возвращает как выходной параметр логическое значение: TRUE, если основанная на ролях система

безопасности задействована, и

FALSE в противном случае.

z Если система безопасности задействована, то метод IsCallerInRole используется для проверки принадлежности клиента,

вызвавшего метод, заданной роли. Входной параметр задает строку с ролью, выходной возвращает истину или ложь в

зависимости от принадлежности клиента специфицированной роли. В зависимости от этого значения можно продолжить

выполнение основной логики метода, либо прервать его выполнение с соответствующим кодом ошибки.

Вообще, интерфейс

ISecurityCallContext позволяет получить следующую информацию об исполняемом вызове:

z Длина цепи вызовов

Как уже отмечалось ранее, в COM каждый вызов получает уникальный идентификатор, и все последующие вызовы,

сделанные ради выполнения данного вызова, получают тот же идентификатор. Это позволяет отслеживать цепочки

вызовов.

z Минимальный уровень аутентификации, использующийся в данной цепи вызовов

z Идентификационная информация для всех клиентов, сделавших включенные в данную цепь вызовы:

{ SID

{ Имя

{ Сервис аутентификации (например, Kerberos)

{ Уровни аутентификации и имперсонализации

z Идентификационные данные клиента, сделавшего первый вызов в цепи

z Идентификационные данные клиента, сделавшего последний вызов в цепи

Теперь рассмотрим, как на стороне сервера решается вопрос имперсонализации клиента и делегирование его прав при удаленном

вызове.

С помощью функции

CoGetCallContext можно получить также указатель на интерфейс IServerSecurity. Именно этот

интерфейс предоставляет метод без параметров

ImpersonateClient, который при вызове в потоке, выполняющем вызов клиента,

имперсонирует этого клиента, приписывая потоку маркер доступа с аутентификационными данными этого клиента. Вызов

другого метода без параметров этого же интерфейса - RevertToSelf позволяет вернуть потоку исходный маркер доступа.

Как уже отмечалось ранее, если уровень аутентификации клиента был установлен не ниже чем в

Impersonate, то после

имперсонализации клиента сервер получает доступ (на время выполнения этого метода или до вызова

RevertToSelf) ко всем

локальным ресурсам от имени клиента пользуясь всеми его правами. Однако, если уровень имперсонализации установлен в

Delegate, можно было бы ожидать, что данный поток получает право делать от лица клиента и удаленные вызовы. Однако, это не

так. Ради совместимости с предыдущими версиями (COM под Windows NT), делегирование будет иметь место только после

дополнительной настройки. Именно, после имперсонализации клиента C поток сервера S должен выполнить cloakig, т.е. скрыть

свою сущность от вызываемого сервера Q

под маской имперсонированного клиента C. Один из способов состоит в задании

специального флага для прокси, который поток сервера S получил, выполнив вызов сервера Q. Для этого можно получить

текущие установки уровня безопасности для данного прокси используя

IClientSecurity::GetBlanket, добавить один из

следующих флагов:

z EOAC_STATIC_CLOAKING

z EOAC_DYNAMIC_CLOAKING

и задать новые установки для прокси с помощью

IClientSecurity::SetBlanket.

Упомянутые выше флаги имеют следующий смысл. При задании первого флага все последующие вызовы через этот прокси

будут делаться от лица того клиента, который был имперсонирован до вызова

SetBlanket. Если был использован второй флаг, то

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

процесса. Это означает, что, например, чередуя вызовы

IServerSecurity::ImpersonateClient и

IServerSecurity::RevertToSelf, текущий поток будет делать удаленные вызовы то от имени клиента C, то от имени сервера S.

Асинхронные компоненты

( Queued Components)

Вначале несколько слов о терминологии. Термин Queued Components сложно перевести на русский язык, сохраняя стоящий за

ним (в рамках COM+) смысл. Дословный перевод ``организованные в очередь компоненты'', который иногда используется в

русскоязычной литературе, заставляет предполагать, что имеется в виду некоторая очередь различных компонентов, тогда как все

совершенно иначе - имеется очередь вызовов к одному

компоненту. В данном курсе выбран термин ``асинхронные компоненты'',

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

непересекающиеся интервалы времени.

Здесь же необходимо отметить, что в COM+ появилась новая возможность объявить некоторый интерфейс как асинхронный.

Асинхронные интерфейсы и асинхронные компоненты (Queued Components) - это разные технологии. Использование

асинхронного интерфейса позволяет клиенту сделать

вызов некоторого метода асинхронного интерфейса сервера и сразу же

заняться чем-нибудь еще (при использовании обычного синхронного интерфейса клиент блокируется до получения ответа от

сервера). Но при этом и клиент и сервер должны функционировать одновременно. В случае вызова, направленного асинхронному

компоненту, клиент также не блокируется, как и при вызове асинхронного интерфейса

. И, кроме того, клиент может делать вызов

сервера в тот момент, когда сервер еще не запущен.

Теперь перейдем к более подробному рассмотрению именно технологии асинхронных компонент.

До сих пор мы рассматривали только синхронную коммуникацию клиента и сервера -- клиент делает вызов и ждет ответа

сервера. Только после получения ответа от сервера

продолжается выполнение клиента. Иначе такая коммуникация называется

коммуникацией в режиме реального времени.

В случае вызова асинхронного компонента

z Клиент может не дожидаться ответа сервера и продолжать свою работу.

z Вызовы от клиента к серверу могут накапливаться на стороне клиента и отправляться серверу все за один раз.

z Клиент может вызывать метод сервера даже в тот момент, когда сервер еще не запущен.

Рассмотрим ситуации, когда предпочтительно использовать асинхронные компоненты:

z В рамках бизнес-логики данного приложения в одних случаях коммуникация клиент/сервер должна выполняться в режиме

реального времени, а в других допустима асинхронная коммуникация.

Чаще всего в литературе приводится следующий пример. Клерк принимает заказы от клиентов по телефону. Коммуникация

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

. Например, может

оказаться, что нужного товара нет на складе, и клерк может попытаться уговорить клиента купить другой товар. Однако,

коммуникация приложения, принявшего заказ, и приложения, обеспечивающего доставку товара покупателю, может

выполняться не в режиме реального времени, а, например, ночью, когда спадет поток заказов по телефону.

z Возникает проблема масштабируемости приложения

Предположим, что в рамках рассмотренного в предыдущем пункте примера, для оформления каждого нового заказа

серверное приложения формирует объект, представляющий покупателя, в который и заносятся такие данные как имя

покупателя, название товара, его стоимость, форма оплаты, адрес покупателя и т.п. В течении всего времени оформления

заказа для

некоторого покупателя соответствующий ему объект живет на сервере и связывает определенные ресурсы

(например, соединения с базами данных). При большом числе одновременно оформляемых заказов,

есурсы, необходимые

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

Масштабируемое решение связано с использованием асинхронных компонент. Во время оформления заказа данные о заказе

накапливаются в клиентском приложении и только потом, все вместе, направляются в только что созданный объект,

представляющий покупателя, который обрабатывает все пришедшие запросы и удаляется из памяти

z Клиентское приложение работает на устройстве, не подключенном к сети

Клерк из рассматриваемого примера может собирать заказы с помощью клиентского приложения, установленного на

мобильном, не подключенном к сети компьютере. Позже он может подключить свой компьютер к сети, и все

аккумулированные вызовы поступят к удаленным асинхронным компонентам.

Технология асинхронных компонент основана на технологии

MSMQ

(Microsoft Message Queuing), которая для полноты изложения и рассматривается кратко в следующем разделе (изложение

основано на статье David Chappell ``Microsoft Message Queue Is a Fast, Efficient Choice for Your Distributed Applications'' в MSJ, July

1998 и материалах из MSDN).

MSMQ

Синхронная коммуникация удаленных клиента и сервера в COM+ основана на использовании протокола DCOM - объектно-

ориентированной версии RPC. MSMQ предоставляет новую возможность - обмен сообщениями. Эта технология имеет

следующие преимущества:

z Отправитель сообщения не блокируется в ожидании ответа от получателя.

z Отправитель и получатель могут работать в различные непересекающиеся интервалы времени.

z Отправитель может направить сообщение сразу же целой группе получателей.

z Сообщение можно сохранить на диске и повторить его обработку при сбое.

z Возможна пересылка сообщений по цепочке (аналог делегирования).

Таким образом, MSMQ (вместе с другими подобными технологиями) представляет особую парадигму проектирования

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

вычислениях (MPI в кластерах ЭВМ). Можно предположить, что основанные на сообщениях технологии будут особенно

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

выше предприятия, т.е. систем, отдельные части которых

слабо или вообще не связаны друг с другом организационно.

Основными элементами технологии MSMQ являются:

z API, используемый приложением для отправки и получения сообщений

Данный API имеется в двух видах: множество C функций и множество COM объектов. MSMQ API обеспечивает

следующие возможности:

{ Создание и уничтожение очереди сообщений

{ Открытие и закрытие существующей очереди сообщений

{ Получение сообщения из очереди

синхронно, асинхронно, с удалением из очереди, чтение некоторых элементов сообщения без удаления его из очереди

и т.п.

z Сообщение

Многое о возможностях MSMQ можно узнать просто просмотрев список свойств, которые могут быть приписаны

сообщению. Эти свойства хранятся в специальной структуре, передаваемой как входной параметр в API функции,

связанные с отправлением и получением сообщения. Рассмотрим некоторые из этих свойств:

{ Body

Здесь размещается основное содержание сообщения (объемом до 4Mb). Передавать можно даже COM объект,

поддерживающий интерфейс

IPersistStream, методы которого позволяют записать состояние объекта в некоторый

поток, а затем восстановить объект, инициировав его данными из потока.

{ App Specific

Это свойство можно использовать для передачи специфичной для приложения информации. Так как отдельные

свойства сообщения можно просматривать не извлекая сообщение из очереди, наличие такого поля весьма полезно

при программировании сложной бизнес-логики.

{ Delivery

Данное свойство определяет, где очередь должна хранить данное сообщение - на диске (значение Express), либо в

оперативной памяти (значение Recoverable). В последнем случае сообщение не пропадет если, например, произойдет

отключение питания. Но в первом случае минимизируются накладные расходы.

{ Time To Be Received

Это похоже на параметр ``время жизни'' пакета в IP протоколе. Данный параметр задает число секунд, в течении

которых сообщение должно быть получено адресатом. По истечении заданного времени MSMQ автоматически

уничтожит сообщение.

{ Time To Reach Queue

Отправитель сообщения всегда отправляет его в некоторую очередь (очередь назначения), из которой это сообщение

должен забрать уже получатель. Заметим, что в процессе передачи сообщения от отправителя до очереди назначения

сообщение может временно храниться в другой очереди (например, на машине отправителя, если в данный момент

очередь назначения недоступна). Данный параметр задает

число секунд, в течении которых сообщение должно

достигнуть очереди назначения. По истечении указанного времени MSMQ уничтожит это сообщение, если оно не

успеет дойти до очереди назначения.

{ Acknowledge

Задавая подходящее значение для этого параметра, отправитель может потребовать от MSMQ автоматически

уведомить его о получении сообщения, о записи сообщения в очередь назначения, об уничтожении сообщения по той

или иной причине.

{ Admin Queue

Здесь можно задать так называемую административную очередь, в которую MSMQ будет напрвлять уведомления,

тип которых задан в свойстве Acknowledge.

{ Arrived Time

В этом свойстве MSMQ соханяет момент времени, в который сообщение достигло очереди назначения.

{ Journal

используя этот параметр отправитель может потребовать сохранение копии сообщения в специальной очереди на

своей машине (в любом случае, в случае недостижимости получателя).

{ Priority

Приоритет сообщения учитывается при его маршрутизации и при размещении в очереди.

{ Response Queue

Здесь можно указать имя очереди на стороне отправителя, в которую он хотел бы получить ответ от получателя

сообщения (если, конечно, получатель пожелает отправить ответ).

{ Message ID

Данный идентификатор формируется автоматически. Получатель сообщения, желающий послать ответ, может указать

этот идентификатор в свойстве Correlation ID, связывая тем самым ответ с полученным сообщением.

{ Correlation ID

При отправке ответа на полученное сообщение здесь следует указать значение свойства Message ID полученного

сообщения.

Ряд свойств, приписываемых сообщению, связан с аутентификацией и шифрованием сообщений. Эти вопросы излагаются

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

системой безопасности COM+, но только для случая синхронных вызовов, т.к.

вся система аутентификации, основанная на

Kerberos или NT LAN Manager, основана на синхронной коммуникации клиента и сервера. Технология асинхронных

компонент требует использования новой системы аутентификации.

Аутентификация позволяет получателю сообщения быть уверенным в том, что данное сообщение послано именно данным

отправителем и в процессе передачи в сообщение не были внесены никакие искажения (целостность сообщения).

Шифрование

сообщения (его тела - Body) позволяет защитить передаваемую информацию от несанкционированного

просмотра.

Аутентификация выполняется по запросу отправителя. Соответствующее требование задается в свойстве

Auth Level, где

определяется и тип электронной подписи, которую следует использовать при аутентификации в зависимости от типа

сообщения.

Что делает MSMQ на стороне отправителя при запросе :

{ Получает сертификат от приложения-отправителя

В простейшем случае, когда сообщение пересылается в рамках одного Windows 2000 домена, используется так

называемый внутренний сертификат, включающий SID отправителя и его публичный ключ. Если сообщение

пересылается за пределы одного домена, используется так называемый внешний сертификат, содержащий

специфичную для конкретного способа аутентификации информацию. В этом случае аутентификация выполняется

самим

приложением-получателем, а не менеджером очереди назначения, как это происходит при использовании

внутреннего сертификата. Далее мы не будем рассматривать этот случай.

Сертификат прикрепляется к сообщению и используется менеджером очереди назначения при аутентификации

полученного сообщения. До использования сертификата он должен быть зарегистрирован его владельцем в Active

Directory данного домена.

{ Получает личный ключ отправителя

Этот ключ, конечно, не будет отправляться в сообщении. Он будет использоваться при генерации цифровой подписи,

которой будет подписано отправляемое сообщение.

{ Вычисляет хешированное значение сообщения

Одно из свойств сообщения определяет алгоритм хеширования, который будет использован и на стороне отправителя,

и на стороне получателя сообщения. Хешируется информация, содержащаяся в нескольких определенных полях

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

сообщения.

{ Формирут цифровую подпись для данного сообщения

Ранее полученное хешированное значение шифруется личным ключем отправителя.

{ Сообщение с прикрепленными сертификатом и цифровой подписью отправляется в очередь назначения.

Что делает менеджер очереди назначения по получении сообщения:

{ Вычисляет хешированное значение определенных полей полученного сообщения

Используется указанный в этом же сообщении алгоритм.

{ Извлекает публичный ключ из сертификата, полученного с сообщением.

{ Расшифровывает цифровую подпись

Для расшифровки используется публичный ключ. Результатом является хешированное значение отправленного

сообщения.

{ Сравнивает хешированные значения отправленного и полученного сообщений:

 Хешированные значения равны

Если SID отправителя содержится в сообщении (в одном из его свойств, в сертификате), то это означает, что

отправитель желает, чтобы получатель не только проверил целостность полученного сообщения, но и выяснил,

пришло ли это сообщение от заявленного отправителя.

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

формирует новую цифровую подпись, пользуясь своим личным ключем. В этом случае он должен поменять и

сертификат, посылаемый с сообщением, включив в него свой собственный публичный ключ. Если он сохранит в

сообщении SID первоначального отправителя, то получатель получит искаженное сообщение не заметив

подмены.

Проблема решается проверкой владельца сертификата в Active Directory. Злоумышленник не может

зарегистрировать свой публичный ключ под чужим SID. Это позволяет менеджеру очереди назначения сравнить

SID владельца сертификата и SID,

включенный в сообщение. Если они совпадают, то аутентификация прошла

успешно. В противном случае сообщение уничтожается и отправителю высылается соответствующее

уведомление (если он об этом просил).

 Хешированные значения различны

Сообщение уничтожается и отправителю посылается соответствующее уведомление (при наличие его просьбы)

{ Если сообщение еще не уничтожено, проверяется право отправителя на включение сообщения в данную очередь

При формировании очереди ей приписывается свой ACL - Access Control List. Если известен SID отправителя, то

выполняется просмотр списка ACL до тех пор, пока не выяснится, что данный отправитель имеет или не имеет право

на включение сообщения в данную очередь. Если SID отправителя не задан

, то сообщение будет включено в очередь

только при отсутствии каких-либо ограничений на эту операцию в ACL.

{ Сообщение включается в очередь, если успешно завершилась проверка в ACL. В противном случае сообщение

уничтожается. Отправителю посылается соответствующее уведомление (по его просьбе).

По запросу отправителя выполняется шифрование тела сообщения. Информация об использованном алгоритме содержится

в специальном свойстве сообщения. На стороне отправителя шифровку выполняет либо MSMQ, либо приложение-

отправитель. На стороне получателя расшифровку выполняет

менеджер очереди назначения, и в очередь сообщение

включается уже в расшифрованном виде.

z Очередь

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

удаляться. Все очереди на одной машине управляются менеджером очереди, роль которого отчасти уже обсуждалась при

изучении свойств сообщений. Рассмотрим два класса очередей:

{ Очереди, создаваемые приложением

При создании новой очереди необходимо определить, будет ли создаваемая очередь публичной (public) или личной

(private), и будет ли она транзакционной (transactional) или нетранзакционной (non-transactional):

 Публичная очередь

Регистрируется в Active Directory и, следовательно, может быть обнаружена любым приложением. Интересно

отметить, что среди параметров, приписываемых очереди при ее создании, имеется параметр, задающий тип

очереди в виде GUID. Это позволяет приложениям искать публичные очереди нужного типа (например, очередь

печати).

 Личная очередь

Регистрируется только на локальной машине. Другие приложения могут узнать об этой очереди от создавшего

ее приложения (например, через свойство Response Queue полученного сообщения).

 Транзакционная очередь и нетранзакционная очередь

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

распределенной транзакции являются прикладные объекты, менеджеры ресурсов и менеджер транзакций.

Транзакционная очередь является менеджером транзакций. Сообщения из контекста транзакции посылаютя

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

только в нетранзакционную

очередь.

Если необходимо гарантировать доставку сообщения от отправителя до получателя, причем только одной копии

такого сообщения, следует использовать транзакционную очередь назначения на машине получателя,

отправлять сообщение из контекста транзакции и получать сообщение из контекста транзакции.

Очереди приложения делятся на

 Очередь назначения

В эту очередь приложение получает сообщения от других приложений. Для минимизации трафика обычно

локальна по отношению к приложению (обязательно локальна, если транзакционна).

 Административная очередь

В этом качестве можно использовать любую нетранзакционную очередь, обычно локальную. Именно в эту

очередь MSMQ отправляет положительные и отрицательные подтверждения относительно доставки сообщений,

отправляемых данным приложением другим приложениям.

 Очередь ответов

В эту очередь приложения-получатели сообщений, отправляемых данным приложением, отправляют свои

ответы.

{ Системные очереди

Среди системных очередей, создаваемых MSMQ, отметим

 Журнал

Служит для хранения всех сообщений, удаяемых из некоторой очереди, или для хранения всех сообщений,

отправляемых с данного компьютера.

 Dead-letter

Сообщения, которые не удалось отправить.

Завершая краткий обзор MSMQ, осталось рассмотреть типы MSMQ приложений:

z MSMQ сервер

Поддерживаются и используются очереди, менеджер очередей, MSMQ API, маршрутизация сообщений между очередями.

Хотя бы один такой сервер должен иметься в любом распределенном приложении, поддерживающем обмен сообщениями.

z Независимый клиент

Поддерживаются и используются очереди, менеджер очередей, MSMQ API. Благодаря наличию собственных очередей

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

накапливаются в некоторой очереди и передаются в очередь назначения автоматически при подключении к сети.

z Зависимый клиент

Поддерживается и используется только MSMQ API. Такой клиент может работать только при подключении к сети.

Архитектура асинхронных компонент

Вновь обратимся к рассмотрению технологии асинхронных компонент. Основными элементами ее архитектуры являются:

z Клиент

Интересно отметить, что клиент может вызывать экземпляр асинхронного компонента либо обычным, синхронным

образом, либо асинхронно. Все зависит от способа активации объекта.

При явном использовании стандартного для COM способа (функции

CoGetClassObject или CoCreateInstance[Ex]) будет

создан экземпляр асинхронного компонента, пригодный только для обычных синхронных вызовов. Точнее, на стороне

клиента будет сформирован обычный прокси, а на стороне сервера - стаб, которые и обеспечат вызовы методов экземпляра

асинхронного компонента в реальном времени.

Для использования возможностей технологии асинхронных компонент клиент должен инициировать формирование

экземпляра асинхронного компонента посредством использования

моникеров типов queue, new и функции CoGetObject.

Например,

hr = CoGetObject(L"queue:/new:My_App.My_Class",

NULL, IID_My_interface, (void**)&ppv);

Моникер иногда называют интеллектуальным именем. Моникер - это объект, который знает как найти, активировать,

инициализировать другой COM объект. Моникеры бывают как встроенные (нескольких типов), так и пользовательские.

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

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

весьма частных случаях.

Указанные выше моникеры типов

queue и new являются встроенными, т.е. мы можем использовать их не заботясь о их

реализации. Моникер освобождает клиента от участия в процессе активации объекта. Этот процесс зависит от типа объекта,

и без использования моникеров клиент должен входить во все детали (например, как активировать объект, состояние

которого хранится в заданном файле). Каждый моникер

реализует интерфейс IMoniker, скрывающий за стандартным

фасадом все детали конкретного алгоритма активации.

Функция

CoGetObject в нашем случае делает следующее:

1. Создает контекст связывания.

Связывание - процесс получения указателя на интерфейс некоторого объекта, что и является основной задачей любого

моникера. Вызывается функция

CreateBindContext, которая создает специальный объект - контекст связывания,

который будет использоваться различными функциями, связанными с построением и использованием моникеров.

Контекст связывания будет хранить данные, нужные в течение всего процесса связывания (например, ссылки на

объекты, использующиеся в процессе связывания). Освобождается этот объект по завершении связывания, что

значительно сокращает время связывания, т.к. каждая

новая функция, вызывающаяся в процессе связывания, будет

повторно использовать этот же контекст связывания и все хранящиеся в нем данные.

2. Создает моникер по его строке инициализации (текстовое представление моникера, display name).

Технология моникеров позволяет построить единое иерархическое пространство имен для объектов различных типов.

Строка инициализации моникера, связанного с данным объектом, и может рассматриваться

как его имя.

Вызывается функция

MkParseDisplayName, которая получает на входе

 Указатель на контекст связывания (полученный в предыдущем пункте)

 Строку инициализации формируемого моникера

Выходными параметрами являются

 Длина начальной части строки инициализации, распознанная данной функцией

 Указатель на построенный моникер

В нашем случае строкой инициализации моникера является строка ``

queue:/new:My_App.My_Class''. Слева от первого

разделителя ``:'' стоит префикс - тип моникера (в нашем случае

queue), который должен быть зарегистрирован как

ProgID в реестре. Справа от этого разделителя стоит специфичное для данного типа моникера строка, которая хранит

некоторую информацию об объекте, с которым должен быть связан этот моникер. В нашем случае эта строка является

строкой инициализации еще одного моникера, тип котрого

new. Таким образом, в данном случае мы имеем

композицию двух моникеров.

Алгоритм работы функции

MkParseDisplayName:

1. Сканируется строка инициализации моникера и выделяется ее префикс -

queue.

2. В реестре для ProgID

queue ищется путь к реализации соответствующего класса моникера типа queue. Либо

объект этого класса, либо его экземпляр реализует интерфейс

IParseDisplayName.

3. В функцию

IParseDisplayName::ParseDisplayName (с такими же параметрами, как и у функции

MkParseDisplayName) передается еще не обработанный остаток строки инициализации -

new:My_App.My_Class''.

4. Функция

IParseDisplayName::ParseDisplayName сканирует эту строку и выделяет тип нового моникера new и

строку, описывающую объект, с которым должен связываться моникер типа

new - ``My_App.My_Class''. Ну и,

конечно, формируется моникер типа queue.

5. В реестре для ProgID

new ищется путь к реализации соответствующего класса моникера типа new. Либо объект

этого класса, либо его экземпляр реализует интерфейс

IParseDisplayName.

6. В функцию

IParseDisplayName::ParseDisplayName передается еще не обработанный остаток строки

инициализации -

``My_App.My_Class'', который уже не содержит префикса - типа еще одного моникера. Формируется моникер

типа

new, который должен будет связываться с COM объектом с ProgID My_App.My_Class.

7. В результате вызова функции

CreateGenericComposite формируется моникер, являющийся композицией двух

построенных выше моникеров типов

queue и new. Указатель на этот моникер возвращается как результат работы

функции

MkParseDisplayName. Возвращается и число обработанных символов в строке инициализации (все символы

обработаны).

3. Выполняет связывание построенного в предыдущем пункте моникера - композиции моникеров

queue и new с COM

объектом.

Для композиции моникеров вызывается функция

IMoniker::BindToObject. Входными параметрами этой функции являются:

 Указатель на контекст связывания

 Указатель на моникер, стоящий в композиции слева от данного (в нашем случае такого нет)

 GUID запрашиваемого интерфейса объкта, с которым выполняется связывание.

Единственным выходным параметром является указатель на запрошенный интерфейс.

Алгоритм работы функции

IMoniker::BindToObject в случае композиции моникеров queue и new:

1. Вызывается функция

IMoniker::BindToObject для ранее построенного (ссылка хранится в контексте

связывания) моникера

new.

При вызове задается ненулевой указатель на моникер, стоящий в композиции слева - моникер

queue.

Если бы этот указатель был нулевым, то вызов функции

IMoniker::BindToObject для моникера new привел бы

к построению нового экземпляра класса с ProgID

``My_App.My_Class'' (этот класс обязательно должен иметь фабрику класса с реализованным интерфейсом

IClassFactory).

В нашем случае вызов функции

IMoniker::BindToObject для моникера new сводится к преобразованию ProgID

My_App.My_Class'' в соответствующий CLSID, который передается моникеру queue.

2. Вызывается функция

IMoniker::BindToObject для ранее построенного (ссылка хранится в контексте

связывания) моникера

queue.

Моникер

queue всегда используется в композиции со стоящим справа от него моникером типа new. Получив от

последнего CLSID асинхронного компонента c ProgID ``

My_App.My_Class'', моникер queue формирует на

стороне клиента прокси особого вида - Recorder, о котором речь пойдет в следующем пункте и который и

обеспечивает асинхронность работы клиента и асинхронного компонента. Указатель на Recoder возвращается

клиенту как указатель на запрошенный интерфейс асинхронного компонента.

Здесь надо еще упомянуть о параметрах, которые можно передавать моникеру типа queue. При обсуждении технологии

MSMQ уже приводился некоторый (неполный) список свойств, которые можно приписывать передаваемому собщению.

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

на отправителя на стороне получателя, использованные алгоритмы хеширования и шифрования, имя очереди назначения и

т.п. Ясно, что упомянутый выше Recoder должен формироваться с

учетом этих требований. Собственно, именно Recoder и

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

CoGetObject нужно иметь

возможность задавать свойства отправляемых сообщений (в противном случае, они будут определены по умолчанию). Эти

свойства можно указать в строке инициализации композитного моникера между ``queue:'' и ``/'' в виде списка пар

войство

= значение

z Recorder

Во многом роль Recoder ясна из вышеизложенного. Это специальный прокси, который принимает все вызовы методов

данного интерфейса данного асинхронного компонента и записывает их все в одно MSMQ сообщение. В это же сообщение

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

Только после того, как все вызовы данного интерфейса со стороны

клиента выполнены (клиент освобождает ссылку на

интерфейс асинхронного компонента и подтверждает завершение транзакции), во время своей деактивации Recoder

отправляет (через MSMQ) построенное сообщение в очередь назначения принимающего приложения. Именно это

приложение содержит данный асинхронный компонент, а имя этой очереди совпадает с именем данного приложения.

Выше уже обсуждались вопросы безопасности в MSMQ. В случае асинхронных

компонент все проще. Как правило, Recoder

выполняется в процессе клиента и имеет одинаковый с клиентом SID. SID клиента записывается Recorder в сообщение.

MSMQ при отправке этого сообщения приписывает к нему дополнительно SID отправителя, т.е. Recorder. Клиент

потенциально может сфабриковать сообщение с чужим SID, однако, он не может изменить SID отправителя. На

принимающей стороне эти два SID сравниваются и при

их равенстве аутентификация считается успешной.

z Listener

Запускается при запуске приложения на принимающей стороне. Извлекает сообщение из очереди, анализирует переданный

в нем CLSID асинхронного компонента и запускает соответствующий Player, которому и передается данное сообщение для

последующей обработки.

z Player

Аутентифицирует сообщение как описано выше. В случае успеха активирует нужный асинхронный компонент и вызывает

его методы.

В некоторых случаях некоторый вызов может завершиться ошибкой. Причиной может являться просто ошибка в

параметрах данного вызова. А может быть, через некоторое время этот же вызов завершится успехом. Player пытается

повторить вызов несколько раз, передавая в

случае неудачи этот вызов в некоторую локальную очередь с меньшим

приоритетом. Из низшей по приоритету очереди вызов может извлечь только администратор.

z Экземпляр асинхронного компонента

Очередь (транзакционная) создается автоматически при создании приложения с атрибутом queued. Имя очереди совпадает с

именем приложения.

Приложение запускается либо администратором либо программно. Если в приложении одновременно имеются обычные

(синхронные) и асинхронные компоненты, то при вызове любого синхронного компонента приложение запустится,

запустится Listener и станут возможными вызовы асинхронных компонент.

Рекомендуется не смешивать в одном

приложение компоненты этих двух типов. В этом случае запуск приложения с асинхронными компонентами будет

находиться под контролем администратора, что и соответствует духу технологии асинхронных компонент - доступ к

асинхронным компонентам открывается в удобное для них время.

Асинхронный компонент должен содержать интерфейсы помеченные как QUEUEABLE. Все методы таких

интерфейсов

должны иметь только входные (

[in]) параметры и не должны возвращать ничего специфического для данного метода. При

вызове такого метода клиенту возвращается значение типа

HRESULT не сервером, а Recoder. Это значение только уведомляет

об успехе либо неудаче записи вызова в буфер. Параметры передаются по значению, либо это может быть указатель на

COM объект, поддерживающий интерфейс

IPersistStream, либо указатель на асинхронный компонент. Последняя опция

позволяет клиенту отправить серверу свой объект, который поможет серверу возвратить ответ клиенту (например, через

электронную почту).

В асинхронных компонентах можно использовать основанную на ролях систему контроля доступа к его функциональности.

Однако, не поддерживается имперсонализация. Аутентификация уже обсуждалась ранее.

Модель событий

Необходимость использования механизма событий часто возникает при разработке распределенных приложений. Классический

пример - отслеживание курса акций определенного предприятия. Один компонент (издатель), имеющий доступ к информации с

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

получает уведомление о событии, состоящем в том, что курс акций некоторого конкретного предприятия превысил

заданный

порог.

Рассмотрим прежде всего две ранее использовавшиеся модели событий, недостатки которых устранены в более совершенной

модели событий COM+:

z Регулярный опрос издателя

Издатель имеет интерфейс, через который подписчик может обратиться к издателю с вопросом - произошло ли заданное

событие (курс акций некоторого предприятия превысил некоторый порог). Вопрос реализуется путем вызова некоторого

метода, входные параметры которого описывают само событие, а выходные представляют ответ издателя.

Данная модель имеет следующие основные недостатки:

{ Огромная доля запросов подписчиков к издателю завершается отрицательным ответом (ожидаемое событие еще не

произошло), и ресурсы и подписчика и издателя тратятся впустую.

{ От момента реального возникновения события до того момента, как об этом событии узнает подписчик, проходит

определенное время (в среднем - половина длины временного интервала между двумя последовательными опросами

издателя данным подписчиком).

z Тесно-связанные события

В рамках этой модели издатель выставляет интерфейс, используя который подписчик подписывается на получение

уведомлений об интересующем его событии, передавая издателю указатель на собственный интерфейс (реализованный

подписчиком, но описанный издателем), через который издатель и будет уведомлять подписчика о появлении данного

события.

Модель тесно связанных событий устраняет упомянутые недостатки предыдущей

модели, но не все. Остаются следующие

вопросы:

{ Реализация

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

задача, которую следует решать не разработчику приложения. Он должен сконцентрироваться на бизнес-логике, а не

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

данной модели - описаны интерфейс

IConnectionPoint и некоторые другие, но их реализация остается за

разработчиком.

{ Фильтрация уведомлений

Подписчик получает все предназначенные ему уведомления и не может отказаться от получения некоторых из них, не

отказываясь от подписки полностью.

{ Активация подписчика

Издатель получает только указатель на интерфейс подписчика, но не знает его

CLSID. Это означает, что подписчик все

время должен находиться в активном состоянии. Издатель не сможет создать подписчика при появлении

интересующего данного подписчика события.

В COM+ предлагается новая модель свободно-связанных событий. Идея состоит в разделении издателя и подписчика

посредником, хранящим описание события и подписку на это событие. В роли посредника выступает подсистема событий

(сервис операционной системы), все данные о событиях и подписках на них хранятся в COM+ каталоге. Подписчик

подписывается на

интересующие его события независимо от издателя. Издатель, при возникновении некоторого события, по

умолчанию инициирует рассылку уведомлений всем подписчикам (собственно рассылка выполняется подсистемой событий).

Однако он имеет возможность просмотреть подписку на данное событие и инициировать отправку уведомлений только тем

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

нему

уведомления.

Основными компонентами архитектуры слабо связанных событий являются издатель, подписчик, подсистема событий,

событийный интерфейс, событийный класс, экземпляр событийного класса, подписка, фильтры издателя и подписчика.

Рассмотрим перечисленные компоненты и сценарии их формирования и использования подробнее.

Событийный класс

В данной модели, как и в модели тесно связанных событий, определяется интерфейс (событийный интерфейс), который должен

реализовать каждый подписчик на события, представленные данным интерфейсом. Каждый метод этого интерфейса

соответствует некоторому событию, входные

[in] параметры метода конкретизируют событие, выходных параметров быть не

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

интерфейса, реализованного данным подписчиком.

Однако, если в модели тесно-связанных событий при возникновении некоторого события издатель самостоятельно вызывает

соответствующий метод для каждого подписчика, то в данной модели все эти вызовы выполняются

автоматически подсистемой

событий. Точнее, издатель направляет вызов подсистеме событий, которая транслирует его всем подписчикам.

Событийный класс является основным элементом в данном механизме. Он представляет в подсистеме событий событийный

интерфейс, который должны реализовать подписчики.

Рассмотрим все этапы описания и использования событийного класса:

z Разработка событийного класса

Разработчик событийного класса прежде всего разрабатывает событийный интерфейс, методы которого будут вызываться

издателем, инициирующем распространение уведомлений о наступлении некоторых событий. Реализовывать этот

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

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

быть только входными.

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

(DLL), который в процессе своей саморегистрации должен зарегистрировать в реестре машины библиотеку типов,

описывающую событийный класс, событийный интерфейс и все его методы.

z Регистрация событийного класса в подсистеме событий

Прежде всего отметим, что в COM+ не реализована распределенность базы данных подсистемы событий. Это означает, что

после выбора машины, на которой в ее подсистеме событий будет зарегистрирован событийный класс, издатель

соответствующего события должен активировать экземпляр событийного класса именно на этой машине. В подсистеме

событий именно этой

машины должны регистрироваться и подписчики на события, представленные данным событийным

классом.

При регистрации событийного класса можно использовать и

Component Services и стандартные интерфейсы для работы с подсистемой событий. Рассмотрим вначале использование

стандартных интерфейсов для работы с подсистемой событий:

{ Прежде всего формируется экземпляр реализованного в системе класса с идентификатором CLSID_CEventClass и

запрашивается указатель на интерфейс

IEventClass этого класса.

{ Интерфейс IEventClass используется для задания свойств класса CLSID_CEventClass, которые должны определить

регистрируемый событийный класс:

 CLSID регистрируемого событийного класса задается вызовом метода IEventClass::put_EventClassID(), где

параметром является BSTR строка, задающая CLSID событийного класса.

 ProgID регистрируемого событийного класса задается вызовом метода IEventClass::put_EventClassName(),

где параметром является BSTR строка, задающая ProgID событийного класса.

 IID событийного интерфейса регистрируемого событийного класса задается вызовом метода

IEventClass::put_FiringInterfaceID(), где параметром является BSTR строка, задающая IID событийного

интерфейса.

Для преобразования GUID в BSTR строку можно использовать функцию

StringFromIID.

{ Формируется экземпляр реализованного в системе класса с идентификатором CLSID_CEventSystem и запрашивается

указатель на его интерфейс

IEventSystem. Данный интерфейс предоставляет методы для добавления, удаления и

извлечения событийных классов и подписок из базы данных подсистемы событий.

{ Вызывается метод Store этого интерфейса, которому в качестве первого параметра передается PROGID_EventClass,

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

на интерфейс IEventClass экземпляра класса с идентификатором CLSID_CEventClass, параметры которого настроены

на регистрируемый событийный класс.

Событийный класс может конфигурироваться и с помощью Component Services. При этом можно задавать как

специфические именно для событийного класса настройки, так и настройки, применимые ко всем COM+ компонентам:

{ Асинхронность событийного класса

Если событийный класс сконфигурирован как асинхронный (Queued Component), то издатель, активируя экземпляр

событийного класса как асинхронный (с помощью моникера

queue), сможет не дожидаться отправки уведомлений