Архитектура системы очередей сообщений на примере IBM MQSeries
Николай Игнатович
Данная статья описывает основные элементы архитектуры системе управления очередями сообщений на примере IBM MQSeries. Очереди сообщений обеспечивают гибкое решение для организации асинхронного взаимодействия между программами в распределенной среде. Являясь наиболее распространенным в мире и зрелым по своей функциональности ПО очередей сообщений, IBM MQSeries демонстрирует возможности и особенности этой архитектуры. Предоставляя единый программный интерфейс для большинства программно-аппаратных платформ и обеспечивая гарантированную доставку сообщений, MQSeries упрощает разработку программ и интеграцию приложений.
Системы очередей сообщений (Messaging Oriented Middleware - MOM) принято относить к категории промежуточного ПО, которое в самом общем случае призвано решать проблемы взаимодействия между различными прикладными и системными программными компонентами. Многие аналитики компьютерной индустрии, например Gartner Group, отмечают сегодня быстрый рост числа решений, использующих очереди сообщений, подчеркивая гибкость и адаптируемость подобной архитектуры.
Система очередей сообщений, такие как IBM MQSeries, предоставляют программам сервис очередей для сохранения сообщений и последующей доставки их другой программе-адресату (метод store and forward). Прикладная программа передает свое сообщение серверу-менеджеру очередей MQSeries, который записывает сообщение в локальную очередь, а затем передает его по сети другому менеджеру очередей MQSeries, содержащему очередь-адресат. Программа-адресат обращается к целевой очереди и получает доступ к сообщению. В результате такой технологии система очередей сообщений предоставляет асинхронный метод взаимодействия программ, не требующий установки между ними прямой связи. При этом гарантируется, что передаваемое сообщение не будет потеряно или получено дважды.
Средства МОМ имеют своих предшественников, появившихся в задачах обмена данными между программами, когда разработчики писали собственные локальные или сетевые решения типа экспорта-импорта данных с использование различных промежуточных хранителей: файлов, буферов памяти и т.д. Оставаясь долгое время в виде вспомогательных и частных средств, подобное программное обеспечение недавно стало бурно развиваться и стандартизироваться в связи с выходом на первый план задач интеграции готовых прикладных систем между собой.
История MQSeries как единого семейства программных продуктов начинается с 1992 года, когда компания IBM опубликовала спецификации для программного интерфейса Message Queue Interface (MQI). В том же 1992 году было заключено соглашение между IBM и компанией System Strategies (SSI), которая тогда разрабатывала собственные продукты для передачи сообщений ezBRIDGE Transact, адаптированные для использования MQI.
Местом разработки MQSeries стало и является до сих пор лаборатория IBM, находящаяся в местечке Херсли (Hursley) на юго-западе Англии.
В последующем появилось несколько принципиально новых версий, существенно расширился круг платформ и функциональные возможности MQSeries. MQSeries является кросс-платформенным ПО. Менеджеры очередей MQSeries, работают на большом числе платформ, в их числе: OS/390, MVS, VSE/ESA, OS/400, OS/2, Tandem Guardian и Himalaya, OpenVMS VAX, Digital Unix, AIX, HP-UX, SunOS, Sun Solaris, SCO UNIX, UnixWare, AT&T GIS UNIX, DC/OSx, Windows NT/95/3.1. Для еще большего числа платформ, в том числе для DOS, Java, MacOS, Linux существуют MQSeries клиенты.
Упоминая о существовании нескольких поколений и версий MQSeries, надо только заметить, что менеджеры очередей MQSeries даже разных версий прозрачно взаимодействуют между собой, предоставляют внешним программам единый интерфейс MQI и обеспечивают функционирование единой транспортной системы MQSeries.
Можно указать ряд направлений, в которых происходит развитие MQSeries и всей архитектуры средств МОМ:
появляются новые прикладные и административные интерфейсы, упрощающие разработку новых систем; поддерживаются более сложные модели обработки сообщений, такие как публикация-подписка или обработка с анализом контекста сообщений; развивается интеграция между MQSeries и реляционными базами данных, рещения для поддержки совместной работы нескольких менеджеров очередей, соединенных в кластеры и многое другое.
Модели взаимодействия программ при помощи сообщений
Системы очередей сообщений позволяют программам отправлять и получать данные, не соединяясь друг с другом напрямую. Приложения изолируются друг от друга транспортным слоем, состоящим из менеджеров очередей, берущих на себя задачи обеспечения коммуникаций. С помощью очередей сообщений (Рис. 1в) могут быть реализованы как традиционные модели взаимодействия программ (клиент-сервер) так и модели, которые реализуются только при помощи сервиса сообщений.
Архитектура клиент/сервер. Запросы клиента передаются в виде сообщений в серверную очередь. После обработки запроса приложение-сервер, отправляет ответ в виде нового сообщения в очередь, указанную клиентом в сообщении-запросе.
Асинхронное взаимодействие. При использовании очередей сообщений, нет необходимости, чтобы взаимодействующие приложения были активны одновременно. Программа может отправить сообщение другому приложению, которое обработает его, когда сочтет нужным. Отправив сообщение, программа может не ожидать ответа, а продолжать выполнение других задач.
Запуск программы. Сообщение, посланное одной прикладной программой, может инициировать старт другого приложения. В таком случае по команде программы-монитора, приложение-адресат запускается и обрабатывает сообщение.
Параллельная и распределенная обработка. Исполнение прикладного процесса может быть распределено между несколькими прикладными программами. Старт, координация между программами и консолидация результатов обработки на разных системах реализуются путем пересылки сообщений через очереди.
Архитектура публикация-подписка. Прикладные программы-публикаторы посылают свою информацию с указанием темы в виде сообщения менеджеру очередей. Другие приложения - подписчики присылают заявки на информацию по темам. Присланные публикации распределяются между подписчиками через очереди сообщений специальной программой - брокером в соответствии с темами публикаций. <<<<<<
Основными элементами системы MQSeries являются:
Сообщения (Message) MQSeries представляют собой структуру данных, состоящую из заголовка сообщения (MQMessageDescriptor) и прикладных данных (Рис.1). Заголовок содержит контрольную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда надо передавать сообщение.
Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. Для приложений, функционирующих под управлением различных ОС и оперирующих различными кодовыми страницами, поддерживаются методы конвертации данных.
Очередь сообщений (Queue) - основное место хранения и обработки сообщений. Физическое управление очередями полностью скрыто от прикладных программ. Приложения могут получить доступ к очередям только через интерфейс MQI (Message Queue Interface). Для передачи критически важной информации MQSeries использует "постоянные" (persistence) сообщения, которые журналируются и восстанавливаются после рестарта менеджера сообщений. Для повышения производительности MQSeries поддерживает также и "непостоянные" сообщения, которые не журналируются и могут быть потеряны в результате системного или аппаратного сбоя.
Менеджер очередей (Queue Manager) отвечает за управление очередями сообщений и прием вывозов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы своя. Однако с функциональной точки зрения менеджеры очередей MQSeries представляют собой совокупность очередей различных типов, каналов передачи сообщений между менеджерами, программ-мониторов и административных утилит.
Прикладные программы взаимодействуют с системой MQSeries через интерфейс прикладного программирования MQI (Message Queue Interface). MQI имеет единую структуру на всех платформах и основан на простой системе из десятка команд.
Взаимодействие любой прикладной программы начинается с команды подключения к менеджеру очередей MQCONN. Для того чтобы начать использовать очередь приложение должно сначала открыть ее - команда MQOPEN. При успешном открытии программе возвращается специальный указатель (object handle), на который она будет ссылаться при последующих обращениях к данной очереди. Для помещения сообщения в очередь используется команда MQPUT, для выборки сообщений - команда MQGET, для вспомогательных целей запроса и установки атрибутов очередей существуют вызовы - MQINQ и MQSET. При этом многочисленные опции команд позволяют реализовать различные режимы работы приложений с очередями сообщений. Например, путем установки опций команды MQGET можно осуществлять просмотр и навигацию вдоль очереди сообщений (по типу курсора CУБД) или выборку сообщений, например, удовлетворяющих какому-либо признаку. Для начала и завершения транзакции имеется команда MQCMT и команда отката транзакции назад MQBACK.
Для закрытия очереди и отсоединения от менеджера очередей применяются команды MQCLOSE и MQDISC соответственно.
При создании приложений, обеспечивается поддержка интерфейса MQI для языков программирования: Cи, С++, Java, SmallTalk, Cobol, PL/1, Lotus LSX, Basic. Многие распространенные пакеты для быстрой разработки приложений могут быть использованы для создания программ, использующих MQSeries: VisualAge, Delhi, PowerBuilder, VisualBasic и другие.Хотя надо отметить, что разработка приложений для систем очередей сообщений имеет свои особенности, связанные с асинхронным характером взаимодействия, пример требуется программирование процедур-мониторов очередей.
Пользовательские приложение не обязаны знать внутреннюю структуру системы менеджеров MQSeries: где физически размещены очереди, какие коммуникации существуют между менеджерами очередей. Приложение, обращаясь к менеджеру очередей MQSeries, всегда получает доступ только к локальным очередям сообщений. Когда приложение посылает сообщение в очередь, расположенную на удаленной системе, то сообщение записывается в специальную транспортную очередь( transmission queue), что обеспечивает надежное сохранение сообщения, а уже затем сообщение переправляется по каналу передачи сообщений другому менеджеру на удаленную систему.
На Рис.2 показаны основные элементы, участвующие в передаче сообщения - от приложения к менеджеру очередей A и затем в удаленную очередь на менеджере очередей B.
Каналы передачи сообщений: Как сообщения пересылаются по сети.
Каналы соединяют менеджеры очередей и позволяют осуществлять односторонне направленную посылку сообщений под контролем пары взаимодействующих канальных агентов (Message Channel Agent-MCA). Каналы определяются парами на каждом из взаимодействующих менеджеров очередей. Существует несколько типов каналов, которые должны соответствовать друг другу в паре. Типы каналов различаются тем, какая сторона в канале является инициатором установки связи, а какая источником сообщений.. Комбинации соответствующих признаков дают пары типа Sender-Receiver или Requestor-Server. Инициаторами связи выступают каналы типа Sender и Requestor - в их определении содержатся сетевые адреса и параметры
Приведем пример административной команды для создания канала в MQSeries, в которой указаны основные параметры, определяющие канал:
DEFINE CHANNEL(имя канала) CHLTYPE(тип канала) + TRPTYPE(сетевой протокол) + :{XMITQ(очередь трансмиссии)}
После установки связи из транспортной очереди в канале начинается передача сообщений. При передаче сообщений между двумя менеджерами очередей MQSeries используется специальный протокол канала сообщения (Message Channel Protocol - MCP). Сообщения удаляются из транспортной очереди передающего менеджера, только после подтверждения доставки сообщения другим менеджером. Использование протокола MCP обеспечивает передачу сообщения полностью, в том числе в случае системного или сетевого сбоя.
Если линия связи недоступна, MQSeries может автоматически совершать повторные попытки передачи после восстановления связи. Протокол МСР используется при передаче сообщений поверх транспортных протоколов более низкого уровня TCP/IP, LU6.2, DECnet, NetBios, IPX/SPX.
Адресация и маршрутизация сообщений в MQSeries: Как сообщение находит очередь назначения в распределенной среде.
Система MQSeries отправляет сообщения различным адресатам, пользуясь информацией из заголовка каждого сообщения: имя менеджера очередей для идентификации узла MQSeries и имя очереди для идентификации самой очереди.
В стандартной двойной структуре имен, лежащей в основе системы маршрутизации MQSeries, предусмотрены дополнительные правила, расширяющие возможности идентификации очередей. Кроме прямого использования полных имен очередей реализован алгоритм разрешения имен, позволяющий указывать адресатов при помощи псевдонимов очередей и определений удаленных очередей. Это дает возможность привязывать имена очередей, заложенные разработчиками приложений в процессе кодирования программы к реальной системе очередей. В частности, при изменении физической конфигурации системы администратор сети при помощи административных команд может переопределить маршрутизацию сообщения к новому местоположению очереди без изменений кода приложения.
Механизм разрешения имен MQSeries используется для организации многошаговой маршрутизации сообщений через произвольное число промежуточных менеджеров очередей. Это можно сделать, например, при помощи определений транспортных очередей с именами, совпадающими с наименованиями удаленного менеджера очередей. Сообщения, адресованные удаленному менеджеру, автоматически пересылаются через соответствующую транспортную очередь.
Важнейшей является хранящаяся в заголовке сообщения информация о том, в какую очередь должен быть отправлен ответ на это сообщение. Имя очереди ответа используется для организации связи типа запрос-ответ, а также для организации отправки многочисленных сообщений-отчетов, информирующих о системных событиях, например, о доставке сообщения в очередь назначения или о выборке этого сообщения приложением-адресатом.
У менеджера очередей имеется специальная очередь DLQ (Dead-Letter Queue) - место для хранения недоставленных сообщений. Чаще всего сообщения появляются в DLQ, когда очереди, указанная в заголовке сообщения, не существует или когда очередь назначения оказывается полной. Очереди недоставленных сообщений позволяют разгрузить транспортные очереди и каналы от ошибочных сообщений. При попадании сообщения в очередь недоставленных сообщений в его тело вставляется специальный информационный подзаголовок, позволяющий анализировать причины недоставки. MQSeries обладает механизмом задания правил для автоматической обработки недоставленных сообщений.
MQSeries - это транзакционное программное средство, которое может объединять группу операций по посылке-приему сообщений в единую транзакцию. Прикладная программа помечает часть своих получаемых и отравляемых сообщений специальной опцией - участвующие в транзакции. До выполнения приложением команды на завершение транзакции MQCMIT, посланные этим приложением сообщения является фактически "невидимыми" для других приложений, а полученные приложением сообщения реально не удаляются из очередей. В случае выполнения приложением команды на откат транзакции (MQBACK), очереди восстанавливаются к состоянию на начало транзакции.
Менеджер очередей MQSeries может выступать как менеджер ресурсов, поддерживающий XA интерфейс, и может участвовать в распределенной транзакции под управлением таких мониторов транзакций как CICS, Encina, Tuxedo. Продукты MQSeries, начиная с версии 5, сами могут быть координаторами распределенных транзакций с двухфазной фиксацией.
Асинхронный характер работы системы очередей сообщений требует специального механизма внешней активизации для старта прикладных и системных компонентов. В MQSeries такой механизм - "триггеринг" привязан непосредственно к очередям сообщений. В качестве триггерных событий могут выступать, например, появление в очереди нового сообщения или энного сообщений с приоритетом выше определенного порогового значения.
Чтобы определить триггерное событие, для прикладной очереди при помощи административных команд устанавливаются опции, разрешающие триггеринг и условия триггерного события. Кроме того, администратором системы создается специальное описание обработки триггерного события. В этом описании содержится информация о приложении, которое будет вызвано при наступлении триггерного события. В случае возникновения такого события, например появления нового сообщения в очереди, менеджер очередей автоматически генерирует специальное триггерное сообщение, которое помещается в специальную очередь инициации (initiation queue). В триггерном сообщении содержатся данные о событии и вызываемом процессе. Все очереди инициации отслеживаются триггерным монитором, который читает триггерное сообщение и вызывает внешнюю программу обработки (Рис. 3).
Приведем пример двух административных команд для создания триггерной очереди и описания процесса вызова внешней программы:
DEFINE QLOCAL(имя очереди) TRIGGER + PROCESS(имя процесса) INITQ(имя очереди инициации) + TRIGTYPE(тип триггерного события) :. DEFINE PROCESS(имя процесса) + APPLICID(имя вызываемой программы) USERDATA(параметры):
Триггеринг достаточно часто применяется в качестве стандартного метода автоматического старта каналов между менеджерами очередей. Для этого достаточно в качестве триггерных обьявить транспортные очереди, содержащие сообщения для передачи удаленному менеджеру очередей, .
Распределенная гетерогенная система, такая как MQSeries требует особенного внимания к вопросам удаленного администрирования. MQSeries в этом аспекте предоставляет ряд интерфейсов и достаточное количество утилит для администрирования и конфигурации, включая администрирование очередей , каналов сообщений, безопасности. Для этих целей используются команды двух типов.
Административные текстовые команды MQSC предназначены для работы администратора в режиме командной строки или при использовании текстовых файлов-скриптов. При этом утилита командной строки RUNMQSC преобразует текстовые команды в вызовы API, а затем возвращает пользователю ответные сообщения (Рис.4).
Другая возможность - использование API интерфейса PCF (Programmable Command Format) для вызова административных функций непосредственно из прикладных программ. Для удаленного администрирования менеджеров очередей MQSeries использует специальные командные очереди для приема/передачи административных команд-сообщений и специальные мониторы (command servers) для их исполнения.
Удобные графические средства администрирования MQSeries входят в MQSeries как компоненты: MQSeries Explorer и MQSeries Services Snap-in, так и предлагаются в ряде отдельных продуктов и модулей из общих пакетов управления системами : TME 10 Module for MQSeries (Tivoli), Command Center for MQSeries (Candle Corp.), Command MQ (Bool&Babbage), Patrol KnowledgeModule for MQSeries (BMC).
Для обеспечения безопасности при использовании приложениями системы очередей сообщений необходимо знать, какое приложение послало то или иное сообщение, контролировать, кто получает данное сообщение, обеспечить идентификацию удаленных менеджеров, а также контролировать выполнение административных команд. Само по себе ПО MQSeries не является пакетом для обеспечения безопасности, в частности, не имеет собственных специальных модулей шифрования сообщений, но зато позволяет легко подсоединять внешние компоненты безопасности.
Административные команды и доступ к объектам менеджера очередей. MQSeries позволяет контролировать исполнение административных команд и доступ к объектам менеджера очередей - к самому менеджеру и очередям. На большинстве платформ имеется менеджер безопасности, который позволяет определить и разграничить доступ к объектам. Кроме того, поскольку MQSeries предоставляет документированный интерфейс для управления функциями безопасности, возможно создать собственный менеджер безопасности.
Безопасность в каналах передачи сообщений. Для защиты информации передаваемой между менеджерами очередей, MQSeries поддерживает возможности подключения специально разрабатываемых модулей. Например, два менеджера очередей, устанавливающих связь по каналу, могут с помощью дополнительных программ опознать друг друга. Кроме этого, сообщения, передаваемые по каналу, могут шифроваться перед передачей и расшифровываться при приеме.
Безопасность приложений. Интерфейс MQI предоставляет приложениям средства идентификации себя (приложения и платформы) и пользователя. Идентификационная информация содержится с заголовке сообщения, передается вместе с ним и только привилегированные приложения могут ее изменять. Приложения могут использовать эту информацию для дополнительной проверки получаемых сообщений.
Возможности архитектуры очередей сообщений позволяют использовать MQSeries, как для задач интеграции готовых приложений, так и разработки совершенно новых систем, управляемых сообщениями.
Можно указать на следующие типичные задачи:
Многие финансовые и банковские организации и учреждения, используют MQSeries в качестве базового транспорта для передачи данных внутри и между банковскими приложениями. Важнейшими свойствами MQSeries являются гарантированная доставка сообщений, многочисленность аппаратных платформ, а также открытость решения, позволяющая подключать к MQSeries собственные прикладные компоненты, а также средства обеспечения безопасности. Среди пользователей IBM MQSeries, для которых подобные факторы являются важнейшими, можно указать Центральный Банк Российской Федерации и Национальный Банк Республики Беларусь, которые используют MQSeries для передачи банковской информации.
Крупнейшей организацией в России с огромной распределенной информационной инфраструктурой являются Российские железные дороги. Использование MQSeries обещает интеграцию разнообразных приложений, функционирующих на различных уровнях в единую систему. Разработки на базе MQSeries ведутся в различных организациях Министерства путей сообщений.
Среди готовых систем можно упомянуть Систему предупреждений, разработанную фирмой DigitalDesign для Октябрьской железной дороги. В основе Системы предупреждений лежит построенная на базе MQSeries сеть передачи данных, которая обеспечивает гарантированную передачу предупреждений между службами железной дороги с контролем передачи, доставки и прочтения сообщений.
Среди других типичных примеров использования MQSeries в России можно указать ряд применений MQSeries вместе с прикладными системами, функционирующими на базе распространенной системы групповой работы и электронной почты Lotus Notes.
При использовании какой-либо прикладной системой сервисов MQSeries требуется разработать компонент доступа к очередям MQSeries через MQI. Для многих распространенных программных средств уже существуют готовые модули. Для случаев, когда необходимы дополнения к базовой функциональности системы передачи сообщений, существуют документированные и открытые интерфейсы подключения внешних модулей, которые, например, позволяют взаимное опознание систем, кодирование сообщений, компрессию данных и т.д.
MQSeries Link for SAP R/3. Этот модуль позволяет интегрировать R/3 c другими прикладными системами или удаленными системами R/3. MQSeries Link взаимодействует с компонентом ALE (Application Link Enabling) системы R/3, который отвечает за коммуникацию между распределенными подсистемами R/3. Прикладные данные, циркулирующие в форматах внутренних промежуточных документов IDoc системы R/3, преобразуются в сообщения MQSeries и посылаются другой системе. Посылка/прием сообщений MQSeries происходит под контролем транзакций R/3.
Сопряжение MQSeries с LotusNotes. Для организации взаимодействия MQSeries с Lotus Notes существует целый ряд программных компонентов: MQ Enterprise Integrator, MQSeries LSX, MQSeries Link, MQSeries Extra Link, которые позволяют пользователям посылать данные и документы Lotus Notes в другие системы через MQSeries и получать в ответ сообщения из других систем для обновления документов Lotus Notes.
Расширение стандартного языка программирования Lotus Script - MQSeries LSX, предоставляет набор из нескольких классов, реализующих интерфейс MQI для клиентских и серверных приложений Lotus.
Использование других компонент, таких как MQEnterprise Integrator, и представляющих собой настраиваемые приложения Lotus Notes, не требует непосредственного программирования. При настройке обычно используются специальные базы данных Notes, содержащие сведения об очередях MQSeries, описания структуры посылаемого и возвращаемого сообщения, названия обновляемых документов и информацию о конвертации пересылаемых данных.
Доступ в Internet. MQSeries Internet Gateway представляет собой шлюз между Web сервером и системой MQSeries, преобразующий запросы пользователей броузеров в сообщения MQSeries с последующей отправкой сообщений приложениям и преобразующий полученные обратно сообщения в данные для форм HTML. Кроме того, с Web сервера может быть загружен в виде апплета MQSeries Java клиент, который будет принимать и посылать сообщения с гарантированной доставкой через менеджеры MQSeries.
MQSeries предполагает использование и других технологий из области промежуточного ПО. Например, использование MQSeries сервисов DCE (Distributed Computer Environment) позволяет приложению прозрачно обращаться к очереди сообщений, относящейся к той же ячейке DCE без определения этой очереди как удаленной, а также выполнять аутентификацию пользователей и контролировать доступ к очередям при помощи сервисов безопасности DCE.
Однако гарантированной доставкой информации и компонентами сопряжения с существующими системами проблемы интеграции приложений не исчерпываются. Важнейшей является задача распознания и обработки прикладного содержания сообщений. Для решения такой задачи существует MQSeries Integrator.
MQSeries Integrator представляет собой брокер сообщений. Созданный совместно фирмами IBM и NEON, MQSeries Integrator имеет репозиторий форматов, на базе которого происходит распознание и переформатирование содержания сообщений, а также базу правил, определяющих процедуры обработки и маршрутизации сообщений. Брокер сообщений предлагает централизованную интеллектуальную обработку потоков сообщений внутри организаций и вне ее.
Быстрое распространение программных средств промежуточного уровня связано с многими причинами и тенденциями, в частности, с усложнением функциональности программных средств, приводящей к многочисленности взаимодействующих компонентов в распределенных вычислительных системах. Решения, хорошо обеспечивающие взаимодействие между распределенными компонентами в рамках одной прикладной системы, скажем клиент-серверное решение от одного разработчика, чаще всего не обеспечивают взаимодействия между различными прикладными системами, особенно, если это взаимодействие не было спланировано на этапе разработки. Именно в возможностях поддержки межсистемной интеграции заключается особая ценность систем передачи сообщений.
Использование ПО предоставляемого системами очередей сообщений в качестве асинхронного механизма для организации взаимодействия между программами позволяет создать унифицированную транспортную шину для транзакционных и информационных вычислительных систем различного масштаба. При создании информационной инфраструктуры в России с ее географической и временной протяженностью весьма актуально, а порой жизненно важно использование систем очередей сообщений, таких как MQSeries.
Об авторе: Николай Игнатович, эксперт компании IBM. С ним можно связаться по email: Ignatovich@ru.ibm.com