Доступ к сервисам предприятия с Windows Azure Service Bus

Сервис Windows Azure Service Bus представляет собой интеграционную шину (Middleware) с функциональностью переноса, безопасного обмена сообщениями и создания распределенных и слабосвязанных приложений в облаке, а также гибридных приложених, размещенных одновременно в частных и общедоступных облачных службах. Service Bus - это программная прослойка, которая позволяет интегрировать некоторые сущности, находящиеся внутри предприятия, и внешних клиентов. Windows Azure Service Bus является одним из вспомогательных компонентов облачной платформы Windows Azure, и основная его роль как вспомогательного компонента – помощь в реализации сложных сценариев взаимодействия, например, таких, как создание безопасного канала коммуникаций между веб-сервисом внутри NAT или за брандмауэром и глобально-доступного сервиса.

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

Рассмотреть применение этого принципа на практике можно на примере приложения, состоящего из трех частей – Web-интерфейса, с помощью которого пользователи оставляют заказы, сервиса трекинга заказов и сервиса, осуществляющего доставку заказов. В случае тесной связанности заказы хранятся и вращаются внутри двух сервисов – трекинга и логистики. Если один из этих сервисов выйдет из строя, то это затронет не только его работу, но и работу других частей системы. Если выйдет из строя сервис логистики, то сервис трекинга не сможет переправлять заказы от пользователей (если внутри сервиса трекинга не реализован механизм брокера). Если выйдет из строя сервис трекинга, то заказы пользователей не смогут попасть в систему в принципе – при каждом запросе пользователь будет получать ошибки.

Для того, чтобы решить проблемы тесной связанности в данном сценарии, необходимо интегрировать в приложение еще одну часть, которая будет отвечать за хранение сообщений. Этой частью может стать механизм очереди, который рассматривался в главе, посвященной хранилищу Windows Azure. Windows Azure Service Bus предоставляет механизм очередей с дополнительной функциональностью.

Добавлением в приложение очередь будет решена проблема доставки сообщений – даже в случае полного выхода из строя серверной части приложения (сервисов трекинга и логистики) сообщения пользователей не будут потеряны – они будут храниться в очереди до тех пор, пока не истечет время их жизни либо не станет доступна серверная часть.

Windows Azure Service Bus оперирует тремя основными понятиями – очередями, топиками и рилеями. Основа любой сервисной шины, и Windows Azure Service Bus в том числе – создание пула сообщений и передача их тем клиентам, которым они интересны и для которых они предназначены. Соответственно, с помощью сервисной шины разработчик может реализовать высокомасштабируемые сценарии по осуществлению коммуникаций, подключить необходимое количество клиентов, и т.д. Возможными клиентами сервисной шины могут быть SaaS-решения, десктопные клиенты, порталы, железные устройства типа телефонов, промышленные, клиенты с переменным доступом к сети, которым необходимо собрать данные и потом отправить их в главный офис. Например, в случае клиентов с переменным доступом к сети сообщения накапливаются в кэше у клиента и, когда появляется подключение, сообщения отправляются в базу.

Первым компонентов Windows Azure Service Bus является рилей –маршрутизатор, который позволяет реализовать сценарий "прохода" запросов через NAT/брандмауэр и вынести сервис наружу. Это типичный сценарий, в котором за брандмауэром в корпоративном центре обработки данных находится сервис, который нужно вынести наружу без нарушений регламентов безопасности. C помощью рилея этот сценарий решается наиболее безопасным образом.

Второй компонент Windows Azure Service Bus – это очереди. Очереди Windows Azure Service Bus – это сервис, реализующий стандартную абстракцию программирования и позволяющий обеспечить работу с переменным доступом к сети, и в то же время создать приложения с выравниванием нагрузки, при получении большого количества сообщений же разработчик может выделить несколько очередей и балансировать таким образом нагрузку.

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

Более сложным сценарием использования топиков и подписок является маршрутизатор на базе контента, когда нужно направить сообщение не всем подряд, а передать ее конкретным клиентам. Для этого существуют фильтры, на основании которых сообщения фильтруются и направляются в соответствующие очереди. Фильтры могут иметь один из трех типов: True/NotTrue (когда выполняется или не выполняется заданное условие), SQL-фильтр (когда фильтр задается в SQL-синтаксисе) и фильтр CorrelationId (когда фильтр отрабатывает, учитывая идентификатор корреляции каждого сообщения).

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

Сценарии использования Windows Azure Service Bus

Первый распространенный сценарий - это Web-сервис, например это Web-сервис, обрабатывающий бизнес-логику работы ритейлера. Для решения интеграционной задачи объединения и доставки сообщений по неограниченно большому количеству мобильных клиентов, устройств и точек продаж будут использованы все компоненты Windows Azure Service Bus: очереди - для управления очередями заказов. Каждый из агентов, точек продаж, устройств и клиентов отправляет сообщение в очередь о формировании заказа, далее сообщение обрабатывается сервисом, и эти сервисы, обрабатывая заказы, могут обращаться к корпоративному приложению, находящемуся за брандмауэром в корпоративном центре обработки данных, которое управляет данными, которые нельзя выставлять на внешний мир. Для решения этой задачи используются безопасные рилеи Windows Azure Service Bus. Для уведомления клиентов о различных действиях системы – например, скидках и так далее – используются топики и подписки.

Второй сценарий - специализированный сервис, провайдер вычислительных мощностей для обработки данных по запросу. Пользователи отправляют данные для задачи в облачное хранилище, формируя таким образом очередь задач и сообщение для контроллера (контроллером может выступать Cloud Service), принимающего сообщение и решающего, что надо создать новую задачу для обработки данных. Используя сообщения с низкой латентностью внутри инфраструктуры Windows Azure, он обращается к системе и выделяет некоторые мощности. Для мониторинга состояния задач используются подписки, и каждый экземпляр обработчика регулярно сообщает о статусе обработки задачи, клиенты же могут подписаться на эти подписки. На эти подписки подписан также контроллер, на основании данных откуда он может принимать решения. Решение работает следующим образом: пользователь отправляет задачи через клиентское приложение; задачи обрабатываются в HPC-стиле (распределенном и параллельно обрабатывающемся несколькими обработчиками) на Windows Azure; пользователи могут следить за прогрессом и получать уведомления.

Третий сценарий – это предоставление доступа к внутреннему корпоративному сервису внешним клиентам, вендорам, устройствам. Например, есть данные о сотрудникам, которые необходимо передать в государственное учреждение. Для этого может быть создан рилейный сервис, промежуточный сервис и который будет оперировать с внешним миром. Рилейный сервис, обращаясь к рилею Windows Azure Service Bus, создает новый сервис, который находится по этому URL (заглушке), который будет использоваться внешними клиентами для обращения к данным за NAT. Теперь клиенты могут обращаться к корпоративному сервису или данным по урлу, с помощью которого эти запросы будут безопасно транслироваться в корпоративную закрытую сеть.

Windows Azure Notification Hubs

Notification Hubs – это сервис, который помогает разработчику, решая проблему управления Push-уведомлениями. Вместо реализации собственных механизмов управления разработчик может воспользоваться Notification Hubs и получить инфраструктуру, обеспечивающую поддержку следующих сценариев:

Таким образом, можно сказать, что Notification Hubs являются аналогичным, но более мощным механизмом, по сравнению с Windows Azure Mobile Services Push Notifications. Безопасность проводимых с Notification Hub операций обеспечивается сервисом Windows Azure Access Control Service, который позволяет регламентировать доступ к операциям на основе трех основных прав: Listen (прослушивание), Send (отправка) и Manage (управление).

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

Транзакции в Windows Azure Service Bus

Windows Azure Service Bus предоставляет возможность сущностям Windows Azure Service Bus участвовать в транзакциях, что позволяет разработчикам выплонять несколько операций в пределах одной транзакций, и быть уверенными в том, что все действия будут выполнены либо, если возникнет ошибка, ни одно из этих действий не будет выполнено. В контексте выполнения в транзакции не поддерживается операция Abandon, необходимая для отказа от сообщений от обработки. Все остальные операции могут выполняться в пределах транзакции. Реализацией транзакционного механизма занимается Windows Azure SQL Databases, которые лежат в основе хранилища для Windows Azure Service Bus.

Определение дубликатов сообщений

Встроенные механизм автоматического определения дубликатов сообщений позволяет избавиться от проблемы хранения одинаковых сообщений, которые могут привести к непрогнозируемому результату. Дубликаты сообщений могут возникать в тех ситуациях, когда разработчик в ответ на ошибку принятия сервером сообщения (например, по тайм-ауту) реализует логику повторной отправки сообщений. Однако, может возникнуть ситуация, когда сообщение дошло до сервера, но, тем не менее, была выдана какая-то ошибка. Тогда возникают дубликаты сообщений.

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

namespaceManager.CreateQueue( 
    new QueueDescription(queueName) 
    { 
        RequiresDuplicateDetection = true,
        DuplicateDetectionHistoryTimeWindow = TimeSpan.FromHours(1)    
    });

Заключение

Windows Azure Service Bus – это масштабируемый облачный сервис сообщений, доступный по требованию и являющимся совершенным средством интеграции корпоративных автоматизированных систем и сервисов. К компонентам Windows Azure Service Bus относятся рилеи, очереди, топики и подписки. Windows Azure Service Bus может помочь решить множество различных интеграционных задач, например: