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 - запрос.
Шаблон Enterprise Service Bus (ESB)
Enterprise Service Bus, или сервисная шина предприятия — подход к построению распределённых корпоративных информационных систем. Обычно включает в себя промежуточное ПО, которое обеспечивает взаимосвязь между различными приложениями по различным протоколам взаимодействия.
- интегрированных механизмов идентификации и управления доступом
- механизма присваивания имен сервисам
- общей среды обмена сообщениями
Шаблон ESB помогает преодолеть различия между сервисами с точки зрения управления идентификацией, соглашений о присваивании имен, форматов сообщений и протоколов связи. Как только сервис попадает в шину, все остальные сущности, входящие в нее, могут связываться с ним, даже несмотря на то, что в обычных условиях взаимодействие между ними напрямую было бы невозможным.
К продуктам и технологиям реализации ESB можно отнести:
Сервисная шина Интернета (Internet Service Bus – ISB)
Концепция сервисной шиной Интернета - разрабатываемый подход, при котором возможности шаблона ESB используются в рамках Интернета. Основное отличие от обычного ESB подхода заключается в том, что компоненты ESB должны быть спроектированы и реализованы для работы в вычислительном "облаке".
ISB сделала бы возможным интегрировать вашу локальную ESB с вашими сервисами, выполняющимися в "облаке", с различными сервисами сторонних производителей, RIA и веб - приложениями.
Проблемы реализации двусторонней Интернет связи:
- нехватка IPv4-адресов;
- безопасность - как правило, локальное программное обеспечение практически полностью отгорожено от внешнего мира множеством уровней межсетевых экранов и другими защитными сетевыми устройствами.
Тем не менее на сегодняшний день можно говорить о наличии двунаправленных приложений, таких как:
сервисы мгновенного обмена сообщениями (ICQ, MSN)
сетевые игры
приложения совместного использования файлов (torrent - клиенты)
Обмен сообщениями
Центральной частью .Net Services Bus является сервис ретрансляции, обеспечивающий возможность обмена сообщениями.
Сервис ретрансляции поддерживает:
- однонаправленный обмен сообщениями;
- синхронный обмен сообщениями;
- обмен сообщениями между равноправными участниками сети.
В этом случае вашим сервисам больше нет необходимости создавать локальных слушателей транспортного уровня; они полностью полагаются на сервис ретрансляции в вопросах обработки указанных транспортных аспектов связи. Сервис ретрансляции просто пересылает входящие сообщения на ваш локальный сервис.
Список источников для самостоятельного изучения
.Net Service Bus
- http://msdn.microsoft.com/ru-ru/library/ee872418.aspx
- http://www.microsoft.com/windowsazure/AppFabric/Overview/default.aspx#top
- http://itechthoughts.wordpress.com/2009/04/12/windows-azure-service-bus-publishsubscribe-example/
Работа с .Net Service Bus
Сервисная шина Интернета
Enterprise Service Bus