Microsoft .Net Service Bus: обзор, обмен сообщениями, управление доступом

Обзоp

Основной задачей .Net Service Bus является обеспечение коммуникаций между приложениями. Использование данных служб решает проблемы:

• передачи запросов через брандмауэр;
• определения конечных точек (endpoints) сервисов.

На сегодняшний день, наиболее популярным способом решения вышеобозначенных проблем являются веб - службы, базирующиеся на SOAP - протоколах. Клиентские приложения используют WSDL для генерации прокси - классов, для определения конечных точек и получения доступа к сервисам через firewall.

Вторым способом решения данных проблем является Windows Communication Foundation (WCF), использующий основанные веб-протоколы передачи данных, в т.ч. SOAP.

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

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

Рассмотрим более подробно .Net Service Bus, чтобы понять, как данный сервис справляется с обеспечением эффективного обмена сообщениями.

Концепция .Net Service Bus

Первоначально для того, чтобы воспользоваться возможностями .Net Service Bus, приложения должны зарегистрироваться в соответствующем реестре. Когда приложение обращается к службе, находящейся за брандмауэром, с помощью ,Net Service Bus определяется конечная точка службы и с ней устанавливается связь., т.е. непосредственно сам сервис выполняется за брандмауэром, а соединение с ним обеспечивает Service Bus. Клиенты видят только IP адрес, предоставляемый Service Bus, а не IP, предоставляемый компанией. Данный подход использует возможности .Net Access Control для обеспечения безопасности доступа.

Фактически, приложение использующее .Net Service Bus, реализует WCF функционал, но это не является обязательным. Приложение, обращающееся к сервисам за брандмауэром также может сформировать SOAP или REST - запрос.

Рис. 25.1. (Источник -книга " Introducing Windows Azure" Henry Li)

Шаблон Enterprise Service Bus (ESB)

Enterprise Service Bus, или сервисная шина предприятия — подход к построению распределённых корпоративных информационных систем. Обычно включает в себя промежуточное ПО, которое обеспечивает взаимосвязь между различными приложениями по различным протоколам взаимодействия.

Шаблон ESB требует:

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

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

К продуктам и технологиям реализации ESB можно отнести:

• Active Directory
• UDDI
• BizTalk Server
• MSMQ
• WCF

Сервисная шина Интернета (Internet Service Bus – ISB)

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

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

Проблемы реализации двусторонней Интернет связи:

• нехватка IPv4-адресов;
• безопасность - как правило, локальное программное обеспечение практически полностью отгорожено от внешнего мира множеством уровней межсетевых экранов и другими защитными сетевыми устройствами.

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

сервисы мгновенного обмена сообщениями (ICQ, MSN)

сетевые игры

приложения совместного использования файлов (torrent - клиенты)

Обмен сообщениями

Центральной частью .Net Services Bus является сервис ретрансляции, обеспечивающий возможность обмена сообщениями.

Сервис ретрансляции поддерживает:

• однонаправленный обмен сообщениями;
• синхронный обмен сообщениями;
• обмен сообщениями между равноправными участниками сети.

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

Список источников для самостоятельного изучения

.Net Service Bus

1. http://msdn.microsoft.com/ru-ru/library/ee872418.aspx
2. http://www.microsoft.com/windowsazure/AppFabric/Overview/default.aspx#top
3. http://itechthoughts.wordpress.com/2009/04/12/windows-azure-service-bus-publishsubscribe-example/

Работа с .Net Service Bus

1. http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Сервисная шина Интернета

1. http://msdn.microsoft.com/en-us/library/bb906065.aspx

Enterprise Service Bus

1. http://www.ibm.com/developerworks/ru/library/ws-whyesb/