Опубликован: 28.01.2014 | Доступ: свободный | Студентов: 2074 / 180 | Длительность: 14:33:00
Лекция 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

Этот курс требует оновления https://portal.azure.com/#create/hub здесь нет пункта Web Site в разделе Compute. К тому же для создание трубуется подписка

Евгений Ермолов
Евгений Ермолов
Россия, Москва
Игорь Афанасьев
Игорь Афанасьев
Украина, Харьков, ХПИ, 2001