Россия, г. Москва |
Промежуточная среда COM+ и служба Enterprise Services
Ожидающие компоненты
Хотя среда MSMQ может использоваться в рамках транзакции COM+, это приводит к одновременному использованию двух технологий удаленного взаимодействия. Вероятно часто было бы удобно скрывать использование MSMQ путем создания компонент COM+, поддерживающих асинхронные коммуникации. Поэтому для реализации асинхронного удаленного вызова в промежуточной среде COM+ существуют так называемые ожидающие компоненты ( queued componenets ), которые прозрачно используют MSMQ. Использование такой компоненты подобно асинхронному удаленному вызову (рис. 6.4).
- При начале использования ожидающей компоненты на стороне клиента создается посредник, называемый протоколистом ( recorder ), сохраняющий историю вызовов компоненты.
- После завершения использования компоненты, если не произошло отката транзакции, протоколист формирует сообщение MSMQ со всеми вызовами компоненты.
- На стороне сервера сообщение MSMQ ожидается слушателем ( listener ), который не является COM+ компонентой. При появлении сообщения в очереди он создает специальную COM+ компоненту, называемую помощником слушателя ( listener helper ), которая считывает сообщение из очереди.
- После считывания сообщения помощник слушателя создает исполнитель ( player ), который и создает сам экземпляр отложенной компоненты, воспроизводя затем последовательность ее вызовов в рамках той же транзакции. С точки зрения отложенной компоненты исполнитель является обычным клиентом.
Аналогичным образом происходит получение результата вызова удаленной компоненты: на сервере создается протоколист, а на клиенте – слушатель и исполнитель. Однако в этом случае до начала использования удаленной компоненты клиенту следует создать вызываемый объект ( call-back object ), который будет принимать ответ от сервера через исполнителя, и передать ссылку на такой объект (точнее, на его исполнителя), серверу (рис. 6.5).
Слабо связанные события
Среда COM+ позволяет компонентам подписаться на события, создаваемые какими либо объектами COM+ (издателями событий). При этом подписчики и издатели могут не знать о существовании друг друга, но должны знать о существовании общего интерфейса COM+, который используется для публикации событий. Наравне с отложенными компонентами, слабо связанные события предоставляют второй вариант реализации асинхронного обмена данными в среде COM+.
Обеспечение безопасности
Определение политики управления доступом для компонент COM+ осуществляется на основе ролей безопасности. Компоненты COM+ должны иметь возможность использовать встроенные в операционную систему механизмы обеспечения безопасности. Для абстрагирования от конкретных пользователей операционной системы в COM+ введено понятие ролей безопасности.
Роль безопасности – это категории пользователей приложения COM+, имеющих определенные права на доступ к компонентам данного приложения, их интерфейсам и методам. Разработчик компоненты COM+ задает роли как некоторые символьные значения и определяет уровни доступа для всех использующихся ролей. При разворачивании приложения ролям ставятся в соответствие учетные записи пользователей и групп Microsoft Windows. Следует отметить, что роли COM+ не связаны напрямую с ролями CLI, поскольку COM+ существует независимо от .NET Framework.
Прежде чем назначать роли группам, необходимо понять политику обеспечения безопасности приложения. В идеале названия ролей должны соответствовать категориям пользователей, которым они будут назначены. Кроме того, с помощью оснастки служб компонентов можно получить описание каждой роли, в котором могут содержаться сведения о том, какие пользователи могут назначаться на данную роль.
6.3. Использование среды COM+ в приложениях .NET Framework
Взаимодействие среды COM+ и среды CLR
Среда COM+ была создана до технологии .NET, поэтому она работает с неуправляемым кодом и не является носителем исполняемой среды CLR. Для использовании сервисов COM+ из .NET Framework необходимо получить возможность использовать управляемый код в контексте COM+. Для решения данной проблемы была создана достаточно сложная схема взаимодействия сред CLR и COM+, основанная на понятии компоненты, использующей сервисы COM+ ( serviced component ), называемой далее обслуживаемой (средой COM+) компонентой. Такая компонента состоит из объекта управляемого кода, принадлежащему наследованному от System.EnterpriseServices.ServicedComponent классу. Благодаря наследованию от ServicedComponent при исполнении методов этого объекта имеется доступ к контексту COM+. Использование таких компонент упрощенно показано на рис. 6.6.
Маршализация параметров методов обслуживаемой компоненты при использовании происходит под управлением службы .NET Remoting (с использованием класса форматирования BinaryFormatter ), а среда COM+ используется только для реализации своих сервисов.
Как видно из рис. 6.6, обслуживаемая компонента .NET Framework не является, строго говоря, компонентой COM+. Аналогично и промежуточная среда .NET Enterpsise Services является не новым названием среды COM+, а средством использования сервисов COM+ в управляемом коде. Хотя часто можно упрощенно считать, что обслуживаемые компоненты – это компоненты COM+ на управляемом коде, но при разработке обслуживаемых компонент существуют случаи, когда желательно понимать взаимосвязь CLR и COM+. Например, если при вызове метода управляемой компоненты происходит ошибка в момент выполнения неуправляемого кода среды COM+, то полученная от посредником COM+ информация преобразуется в исключение типа System.Runtime.InteropServices.COMException. В качестве текста сообщения в этом исключении фигурируют ошибки среды COM+, достаточно малопонятные с точки зрения управляемого кода, например такие.
Unhandled Exception: System.Runtime.InteropServices.COMException (0x8000FFFF): Catastrophic failure (Exception from HRESULT: 0x8000FFFF (E_UNEXPECTED)) Unhandled Exception: System.Runtime.InteropServices.COMException (0x8004D082): Exception from HRESULT: 0x8004D082
При возникновении исключения в управляемом коде обслуживаемой компоненты происходит обычное исключение .NET, которое, тем не менее, должно уметь маршализироваться по значению с помощью .NET Remoting между доменами приложений, иначе вместо него к клиенту придет исключение от инфраструктуры .NET Remoting о невозможности сериализации выброшенного исключения.