Системы очередей сообщений
Каналы передачи сообщений: Как сообщения пересылаются по сети?
В распределенной среде за передачу сообщений отвечают сетевые компоненты системы очередей сообщений. В IBM WebSphere MQ используется система каналов передачи сообщений, обеспечивающая гарантированную передачу сообщений поверх разнообразных сетевых соединений. При использовании протокола гарантированной передачи WebSphere MQ MCP ( Message Channel Protocol ) посылаемое сообщение не будет удалено из очереди на сервере посылки до тех пор, пока это сообщение не будет полностью принято на сервере - адресате, то есть реализуется сетевая транзакция при передаче сообщений .
Каналы соединяют менеджеры очередей и позволяют осуществлять направленную посылку сообщений. В WebSphere MQ каналы являются однонаправленными и состоят из пары взаимодействующих канальных агентов (Message Channel Agent - MCA). Для двусторонней связи необходимо определить два канала. Существует несколько типов каналов. Типы каналов различаются тем, какая сторона в канале является инициатором установки связи, а какая источником сообщений. В комбинации каналов типа Sender-Receiver одна сторона Sender является инициатором связи и источником сообщений, вторая сторона Receiver только откликается на инициирующий запрос и принимает поток сообщений, в другой комбинации канал Requestor-Server, инициирующая соединение сторона Requestor принимает сообщения от стороны Server.
После установки связи из транспортной очереди в канале начинается передача сообщений. Сообщения удаляются из транспортной очереди передающего менеджера, только после подтверждения доставки сообщения другим менеджером. Использование в протоколе MCP контрольных точек позволяет концам канала синхронизировать передачу числа сообщения в случае системного или сетевого сбоя. Если линия связи недоступна, MQSeries может автоматически совершать повторные попытки передачи после восстановления связи. Протокол МСР используется при передаче сообщений поверх транспортных протоколов более низкого уровня TCP/IP, LU6.2, DECnet, NetBios, IPX/SPX.
Адресация и маршрутизация сообщений: Как сообщение находит очередь назначения в распределенной среде?
Сервер системы очередей сообщений отправляет сообщения различным адресатам, пользуясь информацией из заголовка каждого сообщения: имя менеджера очередей для идентификации узла и имя очереди для идентификации самой очереди.
В стандартной двойной структуре имен, лежащей в основе системы маршрутизации MQSeries - WebSphere MQ, предусмотрены дополнительные правила, расширяющие возможности идентификации очередей. Кроме прямого использования полных имен очередей реализован алгоритм разрешения имен, позволяющий указывать адресатов при помощи псевдонимов очередей и определений удаленных очередей. Это дает возможность привязывать имена очередей, заложенные разработчиками приложений в процессе кодирования программы к реальной системе очередей. В частности, при изменении физической конфигурации системы администратор сети при помощи административных команд может переопределить маршрутизацию сообщения к новому местоположению очереди без изменений кода приложения.
Механизм разрешения имен системы очередей сообщений используется для организации многошаговой маршрутизации сообщений через произвольное число промежуточных менеджеров очередей.
Для обработки сообщения важным является адрес очереди ответа, то есть хранящаяся в заголовке сообщения информация о том, в какую очередь должен быть отправлен ответ на это сообщение. Имя очереди ответа используется для организации связи типа запрос- ответ, а также для организации отправки многочисленных сообщений -отчетов, информирующих о системных событиях, например, о доставке сообщения в очередь назначения или о выборке этого сообщения приложением - адресатом.
Для отслеживания и исправления ошибок у менеджера очередей имеется специальная очередь DLQ (Dead-Letter Queue) для хранения недоставленных сообщений. Чаще всего сообщения попадают в DLQ, когда очередь, указанная в заголовке сообщения, не существует или когда очередь назначения оказывается полной. Очереди недоставленных сообщений позволяют разгрузить транспортные очереди от ошибочных сообщений и освободить каналы от непрерывных повторных обработок. При попадании сообщения в очередь недоставленных сообщений в его тело вставляется специальный информационный подзаголовок, позволяющий анализировать причины попадания в DLQ. MQSeries обладает механизмом задания правил для автоматической обработки недоставленных сообщений.
Транзакционные свойства: Как обеспечивается целостность данных и синхронизация изменения в сообщениях?
Корпоративная система очередей сообщений должна обязательно включать в себя механизмы транзакций. Прикладная программа помечает часть своих получаемых и отправляемых сообщений специальной опцией - участвующие в транзакции. До выполнения приложением команды на завершение транзакции, посланные этим приложением сообщения являются фактически "невидимыми" для других приложений, а полученные приложением сообщения реально не удаляются из очередей. В случае выполнения приложением команды на откат транзакции, сообщения в очереди восстанавливаются к состоянию на начало транзакции.
WebSphereMQ обладает своим внутренним менеджером ресурсов, который кроме того поддерживает внешний XA интерфейс, и может участвовать в распределенной транзакции под управлением таких мониторов транзакций как CICS, Encina, Tuxedo. Сами по себе сервера WebSphereMQ, начиная с версии 5, могут быть координаторами распределенных транзакций с двухфазной фиксацией.
Триггерные возможности: Как активизировать программу обработки?
Асинхронный характер работы системы очередей сообщений требует специального механизма внешней активизации для старта прикладных и системных компонентов. В WebSphereMQ такой механизм - "триггеринг" привязан непосредственно к очередям сообщений. В качестве триггерных событий могут выступать, например, появление в очереди нового сообщения или энного сообщения с приоритетом выше определенного порогового значения.
Чтобы определить триггерное событие, для прикладной очереди при помощи административных команд устанавливаются опции, разрешающие триггеринг и условия триггерного события. Кроме того, администратором системы создается специальное описание обработки триггерного события. В этом описании содержится информация о приложении, которое будет вызвано при наступлении триггерного события. В случае возникновения такого события, например появления нового сообщения в очереди, менеджер очередей автоматически генерирует специальное триггерное сообщение, которое помещается в специальную очередь инициации (initiation queue). В триггерном сообщении содержатся данные о событии и вызываемом процессе. Все очереди инициации отслеживаются триггерным монитором, который читает триггерное сообщение и вызывает внешнюю программу обработки (рис.1.5).
Триггеринг достаточно часто применяется в качестве стандартного метода автоматического старта каналов между менеджерами очередей. Для этого достаточно в качестве триггерных очередей объявить транспортные очереди, содержащие сообщения для передачи удаленному менеджеру очередей.