Средства поддержки очередей сообщений в WebSphere MQ

3.2.5. Предоставление услуг в инфраструктуре WebSphere MQ

Приложение, предоставляющее услугу, ждет поступления сообщений в очередь, названную в инфраструктуре именем самого приложения.

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

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

3.2.6. Очереди WebSphere MQ как интерфейс доступа к службам

Для доступа к службе инфраструктуры очередей сообщений WebSphere MQ приложение требует нижеперечисленной информации.

• Данные о размещении службы. В WebSphere MQ это название очереди в модели межточечного обмена или темы в модели публикации-подписки.
• Способ подключения к инфраструктуре. В WebSphere MQ это имя и параметры подключения к менеджеру очереди инфраструктуры. Менеджер может находиться на той же машине, что приложение, или располагаться на удаленной машине с подключением к сети.
• Детали интерфейса конкретной службы. Указывают, реализован ли интерфейс по принципу "отправил – забыл", "запрос – ответ" или по модели публикации-подписки. Содержат структуру данных тех сообщений, которые передаются между приложениями, стремящимися получить доступ к службе и предоставляющими ее.
• Механизм отправки и получения сообщений. Прикладной интерфейс программирования (API), реализующий функции, совместимые с используемой инфраструктурой. WebSphere MQ содержит целый спектр разнообразных API, способных использоваться из разных языков программирования и с различных платформ.

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

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

Подобный доступ к службам гибок и удобен в сопровождении. Собственную инфраструктуру и службы, а также внешний доступ к последним могут поддерживать отдельные департаменты фирм и компании в целом.

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

Инфраструктура может претерпевать изменения, такие как межмашинный перенос приложений, расширение памяти, модификации при обслуживании, а также реструктуризацию и объединение инфраструктур, не влияющие на работу или доступность служб, предоставленных интерфейсом.

3.2.7. Стандартизованные API-интерфейсы

Использование стандартизованного API для обращения к службам через инфраструктуру очередей может сделать данный процесс еще более гибким. В этом курсе понятие стандартизованного API служит для обозначения интерфейсов, не являющихся специфичной составной частью таких конкретных продуктов, как WebSphere MQ.

Примерами стандартизованных интерфейсов, которые могут использоваться для обращения к службам, предоставляемым инфраструктурой WebSphere MQ, являются:

• Java™ Message Service (JMS)
• IBM Message Service Client (XMS)

Подробнее мы рассмотрим их в "Создание приложений для доступа к инфраструктуре WebSphere MQ" "Стандартизованные API-интерфейсы для WebSphere MQ".

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

Например, брокер, реализующий функции публикации-подписки в инфраструктуре WebSphere MQ, может быть обновлен с брокера публикации-подписки WebSphere MQ до WebSphere Business Integration Message Broker или WebSphere Business Integration Event Broker.

WebSphere Business Integration Message Broker и WebSphere Business Integration Event Broker – это независимые системы-брокеры, которые в процессе своей работы задействуют базовую функциональность обмена сообщениями WebSphere MQ и предлагают дополнительные возможности, максимально использующие модель сообщений публикации-подписки.

Широкому распространению этих API могут помочь многочисленные продукты. Так, API-интерфейс JMS – промышленный стандарт на API-интерфейсы обмена сообщениями в спецификации Java 2 Platform Enterprise Edition (J2EE™).

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

В случае с WebSphere MQ данные каталога содержат параметры подключения к менеджеру и названия очередей.

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

3.2.8. WebSphere MQ и WebSphere Application Server

Такие J2EE-совместимые серверы приложений, как IBM WebSphere Application Server, предоставляют структуру (framework) для разработки и размещения приложений.

В свою очередь, приложения на J2EE-сервере могут обращаться к целому ряду функций через интерфейсы API, заданные в спецификации J2EE.

Одним из множества стандартизованных API-интерфейсов в спецификации J2EE является интерфейс JMS, который описывает API межточечного обмена и приема-передачи сообщений по принципу публикации-подписки. Для обеспечения широкого спектра иных возможностей, в которых также могут нуждаться прикладные продукты, служат прочие интерфейсы. Так, приложение может получить внешний запрос по интерфейсу, доступному через сеть Интернет и Web-браузер, а может самостоятельно послать запрос и обновить информацию в базе данных.

Технологии, реализующие функциональность J2EE, могут быть встроены в сервер приложений J2EE, а могут быть выполнены как независимые продукты, настроенные на работу с сервером приложений J2EE как поставщики (provider) этих функций.

В поставку WebSphere Application Server Version 5 входит встроенный поставщик JMS-функций на базе WebSphere MQ.

В поставку WebSphere Application Server Version 6 входит встроенный поставщик JMS-функций WebSphere Platform Messaging. WebSphere Platform Messaging – это независимая от WebSphere MQ технология межточечного обмена и организации очередей сообщений по принципу публикации-подписки.

WebSphere MQ может быть настроен как JMS-поставщик для WebSphere Application Server V6.0. Инфраструктуры WebSphere Platform Messaging могут быть связаны с инфраструктурами WebSphere MQ.

3.2.9. Web-службы как интерфейс доступа к службам

Самостоятельно стандартизованные API не решают проблему описания интерфейса доступа к службе. Приложение по-прежнему должно знать формат передаваемых службе сообщений и данных, необходимых ей для выполнения операций.

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

Для описания Web-служб используется универсальный язык – Web Services Description Language (WSDL). WSDL-описание каждой Web-службы может содержать данные о том, каков порядок обращения к службе, какая информация требуется, каков возвращаемый результат, и способно дать общее представление о службе, к примеру описание действий, которые она выполняет.

WSDL-описание Web-службы может быть сгенерировано по коду реализации бизнес-логики самой службы. Такой подход называется "снизу – вверх".

Допускается и обратное: предварительно созданное WSDL-описание может служить основой при создании кода реализации службы. Такой подход называется "сверху – вниз".

В обоих случаях WSDL-описание службы может являться общим для приложения, реализующего Web-службу, и всех обращающихся к ней приложений. Тем самым формируется общий регламент взаимодействия перечисленных приложений.

WSDL-описание каждой входящей в состав системы Web-службы может храниться в общедоступном реестре (registry. Это дает возможность приложениям (разработчикам) запрашивать в реестре WSDL-описания служб, к которым они желают получить доступ, в том числе уточняя порядок взаимодействия.

Посредником в подобных взаимодействиях является функциональный слой, именуемый Simple Object Access Protocol (SOAP). Он описывает общий формат данных Web-службы и приложения, которое обращается к такой службе. Для обеспечения гарантии передачи только корректно заданной информации данные могут проверяться на соответствие WSDL-описанию.

Протокол SOAP описывает, как занятые в обмене данные определяются приложениями. Однако как таковой он не дает механизма взаимодействия приложений внутри сети. Для связи независимых приложений необходим транспортный слой.

Использование как среды транспорта инфраструктуры очередей сообщений WebSphere MQ может соединить преимущества Web-служб при описании взаимодействий с асинхронной природой, надежностью и присущей WebSphere MQ гарантией однократной доставки.

Подробнее о Web-службах, включая правила пользования WebSphere MQ как транспортом для Web-служб, читайте в следующих руководствах:

• WebSphere MQ Solutions in a Microsoft .NET Environment, SG24-7012
• WebSphere MQ Transport для SOAP, SC34-6651

3.2.10. Упрощенная обработка сбоев в WebSphere MQ

Используя любой из интерфейсов доступа к WebSphere MQ, приложение может выиграть от применения механизма обработки ошибок, упрощенного в сравнении с синхронным взаимодействием со службой по сети связи.

Так, после размещения сообщения в инфраструктуре очередей WebSphere MQ гарантирует его доставку по назначению, причем один раз.

Предоставляемая WebSphere MQ гарантия однократной доставки снимает с приложения ответственность за обработку сбоев коммуникации.

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

Приложению как таковому достаточно лишь знать название очереди. Порядок доставки сообщения по назначению и возможность отправки любых ответов менеджеру очередей, к которому подключено приложение, определяют настройки инфраструктуры WebSphere MQ.

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