Журнал "Открытые Системы", #09-10/1999
Николай Игнатович
В статье на примере IBM MQSeries описываются основные элементы архитектуры системы управления очередями сообщений, обеспечивающей гибкое решение для организации асинхронного взаимодействия между программами в распределенной среде. Предоставляя единый программный интерфейс для большинства программно-аппаратных платформ и обеспечивая гарантированную доставку сообщений, MQSeries упрощает разработку программ и интеграцию приложений.
Системы очередей сообщений (Messaging Oriented Middleware - MOM) принято относить к категории промежуточного ПО, которое в самом общем случае призвано решать проблемы взаимодействия между различными прикладными и системными программными компонентами. Многие аналитики компьютерной индустрии, например, специалисты из Gartner Group, отмечают сегодня быстрый рост числа решений, использующих очереди сообщений и подчеркивают при этом гибкость и адаптируемость подобной архитектуры.
Системы очередей сообщений предоставляют услуги сохранения сообщений и последующей их доставки другой программе (метод store and forward). Прикладная программа передает свое сообщение серверу (менеджеру очередей), который записывает его в локальную очередь, а затем передает по сети другому менеджеру очередей, содержащему очередь-адресат. Программа-адресат обращается к целевой очереди и получает доступ к сообщению. В результате система очередей сообщений предоставляет асинхронный метод взаимодействия программ, не требующий установки между ними прямой связи. При этом гарантируется, что передаваемое сообщение не будет потеряно или получено дважды.
Предшественники средств МОМ появились при решении задач обмена данными между программами, когда разработчики писали собственные локальные или сетевые модули экспорта-импорта с использованием различных промежуточных хранителей: файлов, буферов памяти и т.д. Данное ПО долгое время существовало в виде вспомогательных и частных средств, однако в связи с выходом на первый план задач интеграции готовых прикладных систем между собой системы МОМ получили мощный стимул к развитию и стандартизации.
История MQSeries как единого семейства программных продуктов начинается с 1992 года, когда компания IBM опубликовала спецификации для программного интерфейса Message Queue Interface (MQI). В том же году было заключено соглашение между IBM и компанией System Strategies (SSI), которая тогда разрабатывала собственные продукты для передачи сообщений ezBRIDGE Transact, адаптированные для использования MQI.
Затем появилось несколько принципиально новых версий, существенно расширился круг платформ и функциональных возможностей 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 даже разных версий происходит прозрачно для внешних программ, что обеспечивает им единый интерфейс MQI и функционирование единой транспортной системы MQSeries.
Можно указать ряд направлений развития MQSeries и всей архитектуры средств МОМ: появляются новые прикладные и административные интерфейсы, упрощающие процесс создания новых систем; поддерживаются более сложные модели обработки сообщений, такие как публикация-подписка или обработка с анализом контекста сообщений; развивается интеграция между MQSeries и реляционными базами данных; появляются решения для поддержки совместной работы нескольких менеджеров очередей, соединенных в кластеры.
Основными элементами системы MQSeries являются: сообщения, которые прикладные программы посылают друг другу; очереди для хранения сообщений; менеджеры очередей, управляющие очередями и обработкой сообщений; каналы передачи сообщений, связывающие менеджеры между собой.
Сообщения (Message) MQSeries представляют собой структуру данных, состоящую из заголовка сообщения размером 324 байт (MQMessageDescriptor) и прикладных данных, в зависимости от платформы имеющих размер до 100 Мбайт. Заголовок содержит контрольную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда передавать сообщение.
Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. Для приложений, функционирующих под управлением разных ОС и оперирующих различными кодовыми страницами, поддерживаются методы конвертации данных.
Очередь сообщений (Queue) - основное место хранения и обработки сообщений. Физическое управление очередями полностью скрыто от прикладных программ - приложения могут получить доступ к очередям только через интерфейс MQI (Message Queue Interface). Для передачи критически важной информации MQSeries использует "постоянные" (persistence) сообщения, которые журналируются и восстанавливаются после рестарта менеджера сообщений. Для повышения производительности MQSeries поддерживает также и "непостоянные" сообщения, которые не журналируются и могут быть потеряны в результате системного или аппаратного сбоя.
Менеджер очередей (Queue Manager) отвечает за управление очередями сообщений и прием вывозов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы своя. Однако с функциональной точки зрения менеджеры очередей MQSeries представляют собой совокупность очередей различных типов, каналов передачи сообщений между менеджерами, программ-мониторов и административных утилит.
Прикладные программы взаимодействуют с системой MQSeries через интерфейс прикладного программирования 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: адрес физического размещения очереди, типы коммуникаций между менеджерами очередей и т.п. Приложение, обращаясь к менеджеру очередей, всегда получает доступ только к локальным очередям сообщений. Когда приложение посылает сообщение в очередь, расположенную на удаленной системе, то сообщение для надежности записывается в специальную транспортную очередь (transmission queue), а уже затем переправляется по каналу передачи другому менеджеру на удаленную систему.
На рис. 1 показаны основные элементы, участвующие в передаче сообщения - от приложения к менеджеру очередей A и затем в удаленную очередь на менеджере очередей B.
Рис. 1. Порядок передачи сообщений
Каналы соединяют менеджеры очередей и позволяют осуществлять односторонне направленную посылку сообщений под контролем пары взаимодействующих канальных агентов (Message Channel Agent-MCA). Каналы определяются парами на каждом из взаимодействующих менеджеров очередей. Существует несколько типов каналов, которые должны соответствовать друг другу в паре. Типы каналов различаются тем, какая сторона в канале инициирует установку связи, а какая играет роль источника сообщений. Комбинации соответствующих признаков дают пары типа Sender-Receiver или Requestor-Server. Инициаторами связи выступают каналы типа Sender и Requestor: в их определении содержатся сетевые адреса и параметры
Приведем пример административной команды для создания канала в MQSeries, в которой указаны основные параметры, определяющие канал:
DEFINE CHANNEL(имя канала)
CHLTYPE(тип канала) +
TRPTYPE(сетевой протокол) +
...{XMITQ(очередь трансмиссии)}
После установки связи из транспортной очереди в канале начинается передача сообщений. При передаче сообщений между двумя менеджерами очередей используется специальный протокол канала сообщения (Message Channel Protocol - MCP). Сообщения удаляются из транспортной очереди передающего менеджера только после подтверждения доставки сообщения другим менеджером. Использование протокола MCP обеспечивает передачу сообщения полностью, в том числе в случае системного или сетевого сбоя.
Если линия связи недоступна, MQSeries может автоматически совершать повторные попытки передачи после восстановления связи. Протокол МСР используется при передаче сообщений поверх транспортных протоколов более низкого уровня.
Пользуясь информацией из заголовка каждого сообщения (имя менеджера очередей для идентификации узла MQSeries и имя очереди для идентификации самой очереди) система MQSeries отправляет сообщения различным адресатам.
В стандартной двойной структуре имен, лежащей в основе системы маршрутизации MQSeries, предусмотрены дополнительные правила, расширяющие возможности идентификации очередей. Кроме прямого использования полных имен очередей реализован алгоритм разрешения имен, позволяющий указывать адресатов при помощи псевдонимов и определений удаленных очередей. Это дает возможность привязывать имена очередей, указанные разработчиками приложений в процессе кодирования программы к реальной системе очередей. В частности, при изменении физической конфигурации системы администратор сети с помощью административных команд может переопределить маршрутизацию сообщения к новому местоположению очереди без изменений кода приложения.
Для организации многошаговой маршрутизации сообщений через произвольное число промежуточных менеджеров очередей используется механизм разрешения имен. Это делается, например, при помощи определений транспортных очередей с именами, совпадающими с наименованиями удаленного менеджера очередей. Сообщения, адресованные удаленному менеджеру, автоматически пересылаются через соответствующую транспортную очередь.
В заголовке сообщения содержится информация о том, в какую очередь должен быть отправлен ответ на это сообщение. Имя очереди ответа используется для организации связи типа запрос-ответ, а также для отправки многочисленных сообщений-отчетов, информирующих о системных событиях, например, о доставке сообщения в очередь назначения или о выборке этого сообщения приложением-адресатом.
У менеджера очередей имеется специальная очередь DLQ (Dead-Letter Queue) - место для хранения недоставленных сообщений. Чаще всего сообщения появляются в DLQ, когда очереди, указанной в заголовке сообщения, не существует или когда очередь назначения оказывается полной. Сообщения из очереди DLQ позволяют разгрузить транспортные очереди и каналы от ошибочных сообщений, при этом в тело сообщения вставляется специальный информационный подзаголовок, позволяющий, если сообщение не доставлено, анализировать причины случившегося. MQSeries обладает механизмом задания правил для автоматической обработки недоставленных сообщений.
MQSeries - это транзакционное программное средство, которое может объединять группу операций по посылке и приему сообщений в единую транзакцию. Прикладная программа помечает часть своих получаемых и отравляемых сообщений специальной опцией - "участвующие в транзакции". До момента выполнения приложением команды на завершение транзакции MQCMIT, посланные им сообщения фактически "невидимы" для других приложений, а полученные реально не удаляются из очередей. В случае выполнения приложением команды на откат транзакции (MQBACK), очереди восстанавливаются к состоянию на начало транзакции.
Менеджер очередей MQSeries может играть роль менеджера ресурсов, поддерживающего XA интерфейс, а может участвовать в распределенной транзакции под управлением таких мониторов транзакций как CICS, Encina, Tuxedo. Продукты MQSeries, начиная с версии 5, сами могут быть координаторами распределенных транзакций с двухфазной фиксацией.
Асинхронный характер работы системы очередей сообщений требует специального механизма внешней активизации прикладных и системных компонентов. В MQSeries такой механизм - "триггеринг" привязан непосредственно к очередям сообщений. Триггерным событием может быть, например, появление в очереди нового сообщения или факт накопления определенного числа сообщений, имеющих приоритет выше заданного порогового значения.
Чтобы определить триггерное событие, для прикладной очереди при помощи административных команд устанавливаются опции, разрешающие триггеринг и условия триггерного события. Кроме того, администратором системы создается специальное описание обработки такого события. В описании содержится информация о приложении, которое будет вызвано при наступлении триггерного события. Если происходит такое событие, например, появляется новое сообщение в очереди, менеджер очередей автоматически генерирует специальное триггерное сообщение, которое помещается в очередь инициации (initiation queue). В триггерном сообщении содержатся данные о событии и вызываемом процессе. Все очереди инициации отслеживаются триггерным монитором, который читает триггерное сообщение и вызывает внешнюю программу обработки (рис. 2).
Рис. 2. Обработка "триггерных" событий
Приведем пример двух административных команд для создания триггерной очереди и описания процесса вызова внешней программы:
DEFINE QLOCAL(имя очереди) TRIGGER + PROCESS(имя процесса) INITQ(имя очереди инициации) + TRIGTYPE(тип триггерного события) .... DEFINE PROCESS(имя процесса) + APPLICID(имя вызываемой программы) USERDATA(параметры)...
Триггеринг достаточно часто применяется в качестве стандартного метода автоматического старта каналов между менеджерами очередей. Для этого достаточно в качестве триггерных обьявить транспортные очереди, содержащие сообщения для передачи удаленному менеджеру очередей.
Распределенная гетерогенная система, такая как MQSeries, требует особенного внимания к вопросам удаленного администрирования. MQSeries предоставляет ряд интерфейсов и достаточное количество утилит для администрирования и конфигурации, включая администрирование очередей, каналов сообщений, безопасности. Для этих целей используются команды двух типов.
Административные текстовые команды MQSC предназначены для работы администратора в режиме командной строки или при использовании текстовых файлов-сценариев. При этом утилита командной строки RUNMQSC преобразует текстовые команды в вызовы API, а затем возвращает пользователю ответные сообщения (рис.3).
Рис. 3. Администрирование MQSeries
Другая возможность предлагает использование API-интерфейса PCF (Programmable Command Format) для вызова административных функций непосредственно из прикладных программ. Для удаленного администрирования менеджеров очередей MQSeries использует специальные командные очереди приема/передачи административных команд-сообщений и специальные мониторы (command servers) для их исполнения. Графические средства администрирования входят в MQSeries как компоненты MQSeries Explorer и MQSeries Services Snapin, а также предлагаются в ряде отдельных продуктов и модулей из общих пакетов управления системами: 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 в качестве базового транспорта для передачи данных внутри банковских приложений и между ними. К числу пользователей IBM MQSeries принадлежат Центральный Банк РФ и Национальный Банк Республики Беларусь.
Вероятно, крупнейшей в стране распределенной информационной инфраструктурой располагают российские железнодорожники. Сегодня разработки на базе MQSeries ведутся в различных организациях МПС, а из готовых продуктов можно упомянуть систему предупреждений, разработанную фирмой DigitalDesign для Октябрьской железной дороги. В основе этой системы лежит построенная на базе MQSeries сеть передачи данных, которая обеспечивает гарантированную передачу предупреждений между службами железной дороги с контролем передачи, доставки и прочтения сообщений.
В качестве типичных примеров использования MQSeries в России можно также указать ряд применений MQSeries вместе с прикладными системами, функционирующими на базе системы групповой работы и электронной почты Lotus Notes.
При использовании какой-либо прикладной системы служб вместе с 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 предполагает использование и других технологий из области промежуточного ПО. Например, сервисов DCE (Distributed Computer Environment), позволяющих приложению прозрачно обращаться к очереди сообщений, относящейся к той же ячейке DCE без определения этой очереди как удаленной, а также выполнять аутентификацию пользователей и контролировать доступ к очередям при помощи служб безопасности DCE.
Рис. 4. Схема работы MQSeries Integrator
Однако только гарантированной доставкой информации и компонентами сопряжения с существующими системами проблемы интеграции приложений не исчерпываются. Важнейшей является задача распознавания и обработки прикладного содержания сообщений. Для ее решения используется MQSeries Integrator (рис.4) - брокер сообщений, имеющий репозиторий форматов, на базе которого происходит распознавание и переформатирование содержания сообщений. В этом брокере имеется также база правил, определяющих процедуры обработки и маршрутизации сообщений.
Решения, обеспечивающие взаимодействие между распределенными компонентами в рамках одной прикладной системы, (например клиент-серверное решение от одного разработчика) чаще всего не обеспечивают взаимодействия между различными прикладными системами, особенно если это взаимодействие не было спланировано еще на этапе разработки. Именно в возможностях поддержки межсистемной интеграции заключается особая ценность систем передачи сообщений. Использование ПО, предоставляемого системами очередей сообщений в качестве асинхронного механизма для организации взаимодействия между программами позволяет создать унифицированную транспортную шину для транзакционных и информационных вычислительных систем различного масштаба. При создании информационной инфраструктуры в России с ее географической протяженностью и множеством часовых поясов весьма актуально, а порой жизненно необходимо использовать системы очередей сообщений.
Николай Игнатович - эксперт компании IBM. С ним можно связаться по электронной почте по адресу: Ignatovich@ru.ibm.com
Системы очередей сообщений позволяют программам отправлять и получать данные, не соединяясь друг с другом напрямую. Приложения изолируются друг от друга транспортным слоем, который состоит из менеджеров очередей, обеспечивающих коммуникации. С помощью очередей сообщений можно реализовать как традиционные модели взаимодействия программ (клиент-сервер), так и модели, которые создаются только при помощи сервиса сообщений.
Архитектура клиент/сервер. Запросы клиента передаются в виде сообщений в серверную очередь. После обработки запроса приложение-сервер отправляет ответ в виде нового сообщения в очередь, указанную клиентом.
Асинхронное взаимодействие. При использовании очередей сообщений взаимодействующие приложения не обязательно должны быть одновременно активны. Программа может отправить сообщение другому приложению, которое обработает его, когда сочтет нужным. Отправив сообщение, программа может не ожидать ответа, а продолжать выполнять другие задачи.
Запуск программы. Сообщение, посланное одной прикладной программой, может инициировать старт другой. В таком случае по команде программы-монитора запускается приложение-адресат, которое обрабатывает сообщение.
Параллельная и распределенная обработка. Исполнение прикладного процесса может быть распределено между несколькими прикладными программами. Старт, координация между программами и консолидация результатов обработки на разных системах реализуются путем пересылки сообщений через очереди.
Архитектура публикация-подписка. Прикладные программы-публикаторы посылают в виде сообщения менеджеру очередей свою информацию с указанием темы. Другие приложения - подписчики присылают заявки на информацию по темам. Полученные публикации распределяются в соответствии с темами между подписчиками через очереди сообщений специальной программой - брокером.