Опубликован: 28.01.2014 | Уровень: для всех | Доступ: свободно
Лекция 8:

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

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

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

Windows Azure Service Bus: сценарий -  управление очередьми заказов

увеличить изображение
Рис. 11.6. Windows Azure Service Bus: сценарий - управление очередьми заказов

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

Специализированный сервис, провайдер вычислительных мощностей для обработки данных по запросу

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

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

Предоставление доступа к внутреннему корпоративному сервису внешним клиентам

увеличить изображение
Рис. 11.8. Предоставление доступа к внутреннему корпоративному сервису внешним клиентам

Windows Azure Notification Hubs

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

  • Мультиплатформенность. Сервис Notification Hubs объединяет в себе функциональность, необходимую для рассылки уведомлений на популярные платформы (Windows 8, Windows Phone 8, iOS, Android), и автоматизирует работу по их формированию и рассылке.
  • Рассылка уведомлений на основе правил. Каждый объект, подписанный на Notification Hub, может использовать в своей работе один или более тегов-маркеров, позволяющих хабу определить, куда необходимо рассылать уведомления и кто является заинтересованным в этих уведомлениях, а кто их получать не должен.
  • Масштабирование. 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 может помочь решить множество различных интеграционных задач, например:

  • реализации промышленных архитектурных паттернов
  • интеграции компонент инфраструктуры и облака (гибридный сценарий)
  • интеграции своих и сторонних компонент
  • реализации сценариев распределенных систем любой сложности
Руслан Муравьев
Руслан Муравьев
Свежевыданный код Dreamspark
Andriy Zymenko
Andriy Zymenko
Устаревший курс по Azure
Евгений Ермолов
Евгений Ермолов
Россия, Москва
Игорь Афанасьев
Игорь Афанасьев
Украина, Харьков, ХПИ, 2001