Опубликован: 11.05.2007 | Доступ: свободный | Студентов: 1699 / 236 | Оценка: 4.36 / 4.25 | Длительность: 16:06:00
Лекция 7:

Промежуточная среда COM+ и служба Enterprise Services

Ожидающие компоненты

Хотя среда MSMQ может использоваться в рамках транзакции COM+, это приводит к одновременному использованию двух технологий удаленного взаимодействия. Вероятно часто было бы удобно скрывать использование MSMQ путем создания компонент COM+, поддерживающих асинхронные коммуникации. Поэтому для реализации асинхронного удаленного вызова в промежуточной среде COM+ существуют так называемые ожидающие компоненты ( queued componenets ), которые прозрачно используют MSMQ. Использование такой компоненты подобно асинхронному удаленному вызову (рис. 6.4).

Использование ожидающих компонент COM+

Рис. 6.4. Использование ожидающих компонент COM+
  • При начале использования ожидающей компоненты на стороне клиента создается посредник, называемый протоколистом ( recorder ), сохраняющий историю вызовов компоненты.
  • После завершения использования компоненты, если не произошло отката транзакции, протоколист формирует сообщение MSMQ со всеми вызовами компоненты.
  • На стороне сервера сообщение MSMQ ожидается слушателем ( listener ), который не является COM+ компонентой. При появлении сообщения в очереди он создает специальную COM+ компоненту, называемую помощником слушателя ( listener helper ), которая считывает сообщение из очереди.
  • После считывания сообщения помощник слушателя создает исполнитель ( player ), который и создает сам экземпляр отложенной компоненты, воспроизводя затем последовательность ее вызовов в рамках той же транзакции. С точки зрения отложенной компоненты исполнитель является обычным клиентом.

Аналогичным образом происходит получение результата вызова удаленной компоненты: на сервере создается протоколист, а на клиенте – слушатель и исполнитель. Однако в этом случае до начала использования удаленной компоненты клиенту следует создать вызываемый объект ( call-back object ), который будет принимать ответ от сервера через исполнителя, и передать ссылку на такой объект (точнее, на его исполнителя), серверу (рис. 6.5).

Взаимодействие с отложенной компоненты

Рис. 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.

Взаимодействие COM+ и CLR при использовании серверных приложений

Рис. 6.6. Взаимодействие COM+ и CLR при использовании серверных приложений

Маршализация параметров методов обслуживаемой компоненты при использовании происходит под управлением службы .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 о невозможности сериализации выброшенного исключения.