Follow Me Widget

пятница, 11 ноября 2011 г.

Введение в AppFabric Service Bus. Сценарии применения.

Привет, всем ! Сегодня я начну небольшую серию статей, посвященную очень классной технологии под названием AppFabric Service Bus. В моих предыдущих постах я вскользь упоминал об этой технологии и давал ей определение (например, вот здесь Введение в интеграционную инфраструктуру). Сегодня же мы более подробно остановимся на механизме, основных сценариях применения сервисной шины, а также посмотрим с чего начинать работу и как создать свой первый неймспейс.

Итак, давайте представим себе, что мы строим приложение, которому необходимо взаимодействовать с другими приложениями. Что-то вроде соединения peer-to-peer. Самая большая проблема, которая как правило возникает при разработке – это большое количество ограничений, накладываемых на сам процесс коммуникации (файрволлы, NAT-трансляторы и т.д.) Как правило сетевые устройства позволяют инициировать исходящие соединения, но все входящие отбрасываются моментально из соображений безопасности. Поэтому, нам с вами всегда приходится дико извращаться, чтобы обходить эти ограничения сетевого оборудования, при этом придумывая довольно таки сложную функциональность. А так как сетевых топологий существует бесчисленное множество, то и менять “костыли” приходится довольно таки часто. Именно для решения подобных проблем и была придумана технология Service Bus, которая позволяет относительно легко организовывать соединение между различными приложениями. Механизм поддерживает большое множество паттернов взаимодействия, включая такие как: двунаправленные соединения, peer-to-peer – соединения, сценарии publish/subscribe, сценарии, предполагающие сохранение и форвардинг сообщений и др.
Несколько фактов, относительно технологии:
  • Шина построена на базе технологии Windows Communication Foundation и использует стандартные Интернет протоколы
  • Сервис хостится в облаке. Техническая сторона механизма подразумевает упрощение взаимодействия сервисов и приложений, даже если они находятся за “бронированными стенами” файрволов и NAT маршрутизаторов
  • Построение приложений, использующих шину, не требует внесения значительных изменений в исходный код
  • Как часть интеграционной инфраструктуры Service Bus позволяет снизить стоимость построения, разворачивания и поддержки систем по сравнению со всеми существующими ныне аналогами
Какие существуют основные сценарии применения Service Bus ?  В моем понимании из всего разнообразия можно выделить 4 основных.
Безымянный
Первый вариант – это тот, о котором я уже не раз сегодня вспоминал, а именно ретрансляция сообщений. Очень удобна для тех ситуаций ,в которых нам необходимо получить доступ к удаленному сервису и при этом необходимо преодолеть множество барьеров, включая NAT-трансляторы и файрволлы (очень часто для подобных ситуация используют термин Service Remoting). Для таких ситуаций сервисная шина будет чрезвычайно удобна.
Безымянный
Сервисную шину можно также использовать как удобный и производительный вариант распространения событий согласно сценарию publish/subscribe. Это очень распространенный сценарий, согласно которому у нас есть определенные события, генерировать которые может один или более источников, а также существуют подписчики, которые должны быть в обязательном порядке оповещены о произошедшем событии. Вот как раз сам механизм распространения и помещения событий, а также подписку и подключение/отключение от шины берет на себя Service Bus, что значительно облегчает жизнь разработчику.
Безымянный
Кроме всего прочего шину можно использовать как механизм организации очередей сообщений. Это чем-то похоже на событийную модель, кроме некоторых кардинальных различий. Во-первых в случае использования шины в качестве очереди, гарантируется хранение сообщений вплоть до момента доставки подписчику. Например, если в системе события поступают в очередь нескончаемым потоком и обработчики просто не успевают справляться с поступающими задачами, очередь будет хранить все события до тех пор пока они не будут обработаны. Во-вторых как правило очереди применяются в совершенно других сценариях – для организации слабо связанных систем с целью построения более масштабируемых приложений.
Последний вариант применения, о котором я хотел бы рассказать – это расширенная событийная модель, позволяющая настраивать гибкий роутинг сообщений. Называется эта штука Service Bus Topics. В такой системе разработчик имеет возможность создавать топики и настраивать правила фильтрации сообщений на основании выбранного критерия. На рисунке ниже показан пример применения топиков.
Безымянный
Допустим у нас есть обычный интернет магазин, позволяющий клиентам покупать книги и CD-диски. Как только клиент оформил заказ, нам необходимо уведомить фоновые подсистемы, ответственные за дальнейшую обработку заказа. Первая подсистема умеет обрабатывать только заказы книг. Вторая – умеет обрабатывать лишь заказы дисков. И третья подсистема предназначена для логирования любого заказа. В таких условиях идеальным решением будет использование топиков. В описанном выше сценарии будет создан топик, а в нем правила, определяющие, что заказы книг должны перенаправляться подсистеме обработки книг и подсистеме аудита, а заказы дисков – подсистемам обработки дисков и аудита. Все, что нам нужно – это задать набор правил согласно которым будут маршрутизироваться сообщения, все остальное за нас сделает Service Bus Topic

Итак, что нужно сделать для начала работы  с Service Bus? Необходимо прежде всего создать неймспейс. Неймспейс служит своего рода контейнером для приложения, содержащем все точки доступа к сервисной шине. Для этого необходимо на портале разработчика перейти в раздел “Service Bus, Access Control and Caching” и нажать кнопку создания нового неймспейса.

New Service Namespace Button
После этого у нас откроется интересное окошко, в котором в качестве активируемых сервисов выберем Service Bus, определимся с именем (оно должно быть уникальным так как будет использоваться в качестве уникального идентификатора шины в Интернете), целевой регион, а также максимально возможное количество подключений. В моем случае получилась следующая ситуация:

New Service Bus Namespace
После нажатия кнопочки Create Namespace придется немного немного подождать пока он активируется. Как только это произойдет напротив неймспейса появится статус Activated, что будет свидетельствовать о его полной боевой готовности.
На этом знакомство с технологией можно считать завершенным. В последующих статьях мы углубимся в детали организации и функционирования Service Bus на реальном примере

Комментариев нет: