Современная информационная система состоит, как правило, из целого набора приложений, взаимодействие между которыми установить порой бывает не просто. Разработчикам приходится достраивать дополнительные блоки, позволяющие реализовать обмен информацией между приложениями. Но чем сложнее система, тем сложнее спроектировать и организовать взаимодействие между ее компонентами. Для решения подобных проблем можно использовать несколько решений, например, применять программное обеспечение промежуточного слоя на базе обмена сообщениями. Об одном из таких продуктов, IBM MQSeries, шла речь в [1]. В этой статье рассматривается другой программный продукт этого класса — SonicMQ от компании Progress Software.
SonicMQ построена на базе платформы J2EE с использованием языка XML в качестве формата сообщений

Система передачи сообщений — это особый вид ПО промежуточного слоя, которое занимается передачей блоков информации (сообщений) между различными приложениями. Отправителю сообщения достаточно указать только один параметр-адрес получателя. Все остальные действия по поиску получателя, выбору средств и протоколов доставки система выполняет самостоятельно. При этом допускается преобразование информации при передаче для согласования форматов, поэтому отправленное и полученное сообщения не всегда тождественно равны.

Поскольку такая система должна, как правило, работать в гетерогенной среде, то одно из важных требований к ней — это независимость от платформы, а данных от форматов. Немаловажными факторами являются также масштабируемость, надежность и совместимоcть с современными открытыми стандартами Internet. ИТ-индустрия уже выработала стандартные технологии, которые отвечают перечисленным требованиям. Это использование в качестве инструментария создания приложений технологии Java, в качестве стандарта представления информации — семейство языков XML, а в качестве среды передачи — стек протоколов TCP/IP. Именно поддержка этих технологий в системе SonicMQ и отличает ее от своей знаменитой предшественницы — IBM MQSeries. Из архитектурных особенностей и вытекают основные достоинства SonicMQ — интеграция с новыми приложениями и возможность работы через Internet.

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

Следование спецификации J2EE

В спецификации J2EE есть специальный раздел, посвященный системам передачи сообщений — Java Message Service (JMS), где определены основные элементы, которые должна реализовывать система передачи сообщений. Это такие службы, как балансировка нагрузки в кластере, средства для обеспечения отказоустойчивости системы, обработка ошибок, средства защиты и хранения сообщений, поэтому разработчикам SonicMQ пришлось заранее предусмотреть в своем детище все перечисленные возможности.

Среди набора интерфейсов, опубликованных корпорацией Sun Mcrosystems в 1997 году, JMS отводится роль организации асинхронных взаимодействий между серверами приложений. Данный набор интерфейсов потребовался для решения проблем синхронных технологий, таких как RMI и CORBA, при работе в компьютерной сети с неустойчивыми связями. Именно поэтому надежности, безопасности и управляемости системы уделяется большое внимание. В более поздней спецификации благодаря усилиям разработчиков появились требования и распределения нагрузки, и отказоустойчивости, и обработки ошибок.

SonicMQ реализует полную спецификацию JMS вместе с функциями, отнесенными к необязательным. Основным компонентом обработки сообщений является брокер, который получает от клиента необходимую информацию и пытается доставить ее указанному адресату: клиенту или другому брокеру. Клиентом же является приложение, которое участвует в обмене сообщениями в качестве отправителя или получателя информации. Брокеры могут функционировать автономно или объединяясь в кластеры. Соединения между брокерами устанавливаются только в том случае, когда возникает необходимость передать сообщения. Все остальные операции по взаимодействию с клиентами каждый брокер или кластер выполняют автономно.

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

Есть целый набор клиентов SoniсMQ. Основным и наиболее стандартным является Java-клиент. Этот клиент работает в среде виртуальной машины и реализует все необходимые интерфейсы для передачи/получения сообщений и организации транзакций. Этот клиент сертифицирован под платформы Windows, Sun Solaris, HP-UX, IBM AIX и Linux. Есть аналогичный клиент, реализованный на ActiveX/COM и работающий только в Windows-средах, который позволяет разработчикам воспользоваться популярными инструментами, такими как Visual Studio. Есть также клиент, реализованный на Си/Си++, который не требует дополнительных виртуальных сред и работает на платформах Windows NT/2000 и Solaris. Есть также клиенты, реализующие взаимодействие с системами управления базами данных на языке 4GL. Уже сертифицированы клиенты для СУБД Progress, Oracle и Microsoft SQL Server.

Распространение сообщений

В SonicMQ предусмотрено два способа рассылки сообщений: «индивидуальная» (point-to-point) и «массовая» (publish and subscribe). В первом случае отправитель указывает адрес получателя. Во втором случае указывает только категорию сообщения, а брокер доставляет его всем получателям, которые подписались на указанную категорию сообщений. В первом случае отправитель должен точно знать адрес получателя, в то время как во втором количество и расположение получателей может быть любым.

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

Службы взаимодействия

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

  • Целостность. Для гарантии целостности информации — ее неизменности при передаче, в SonicMQ предусмотрены специальные контрольные данные. Перед передачей сообщения для него генерируется своеобразный «дайджест», уникальный для каждого сообщения. Этот дайджест передается вместе с сообщением, и у получателя появляется возможность проверить соответствие полученной информации и дайджеста.
  • Шифрование. Система SonicMQ позволяет шифровать передаваемые сообщения, используя для этого внешние алгоритмы. Сообщение шифруется до передачи его брокеру, поэтому гарантируется конфиденциальность даже при передачи по незащищенным каналам связи. Если же совместить шифрование с обеспечением целостности, то можно обеспечить полную защиту информации как от подделки, так и от перехвата.
  • Оповещение. В SonicMQ предусмотрены специальные сообщения, подтверждающие доставку информации. Их могут посылать брокеры отправителям, сигнализируя о факте приема сообщения, или получатели — брокерам и отправителям. Такие подтверждения гарантируют, что сообщения были переданы правильно.
  • Временное хранение. Еще одной службой, которая гарантирует доставку сообщений, является временное хранение информации в хранилище брокера. Переданные сообщения хранятся до тех пор, пока не будет получено извещение от получателя о приеме сообщения. Объединяя извещения на всех этапах вместе с промежуточным хранением, можно добиться гарантированной доставки сообщений.
  • Аутентификация и авторизация. Одним из ключевых моментов любой системы защиты является аутентификация пользователей и авторизация их доступа к ресурсам системы. Аутентификация отправителей и получателей в SonicMQ производится брокерами по имени пользователи и его паролю. Кроме того, предусмотрена схема авторизации с защищенным соединением по протоколу SSL. Авторизация действий выполняется по списку доступа, который устанавливается системными администраторами и размещается в хранилищах брокера.

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

Коммуникации

Передача сообщений в SonicMQ может вестись по двум независимым схемам: от отправителя к получателю (индивидуальная рассылка) и от издателя к подписчикам (массовая рассылка). При этом процедуры доставки сообщений в этих схемах сильно отличаются. В первом случае отправитель должен указать адрес получателя, во втором — категорию. В первом случае сообщения распространяются как электронная почта, а во втором — как группы новостей Usenet или FIDO. В первом случае используется специальный механизм маршрутизации — Dynamic Rouring Architectire (DRA) — архитектура динамической маршрутизации, а во втором — сообщения рассылаются всем подписчикам категории в соответствии со списками доступа.

Следует отметить, что распространение информации по подписке использует более простой механизм и вполне может эмулировать распространение сообщений конкретному получателю. Однако распространение при помощи очередей (индивидуальная рассылка) имеет много дополнительных функций, которые позволяют организовать более быструю или более надежную и безопасную доставку. Одним из основных преимуществ является промежуточное хранение сообщений и поддержка извещений о доставке, позволяющих гарантировать доставку. Работа с приоритетами и функция немедленной передачи сообщений дает возможность доставлять информацию быстрее. Шифрование и криптографическая подпись сообщений позволяют обезопасить передачу. Таким образом, индивидуальная рассылка реализует все основные преимущества системы передачи сообщений. Тем не менее, массовая рассылка также будет полезна для распространения информации как можно большему числу респондентов. В листинге 1 приведены фрагменты программ для передачи обоих видов сообщений.

Индивидуальная рассылка в SonicMQ, как и в MQSeries базируется на очередях. Различают локальные и глобальные очереди. Локальные существуют только на одном брокере (или кластере) и снаружи не видны. К глобальным очередям могут также получить доступ и удаленные брокеры. Имя глобальной очереди начинается с последовательности «::», а для доступа к удаленной глобальной очереди нужно указать имя брокера, а затем имя очереди, которые отделены друг от друга двумя двоеточиями, например Broker::Queue.

Маршрутизацией сообщений от отправителя к получателю занимается компонент DRA, контролирующий передачу сообщений между брокерами. Сообщение, предназначенное для удаленного брокера, помещается в специальную транспортную очередь, из которой они передаются соответствующему брокеру в соответствии с правилами маршрутизации, установленными администратором системы. Если включен механизм хранения сообщений, то после их отправки они помещаются в специальную очередь —Dead Message Queue (DMQ), в которой хранится установленное время, либо до получения извещения от получателя о приеме сообщения. В эту очередь невозможно ничего записать, а просмотреть ее можно лишь при определенных условиях. Эта очередь гарантирует восстановление сообщения, которое было потеряно или изменено при передаче.

Кластеризация

Кластер — набор постоянно связанных между собой брокеров. Брокеры кластера могут иметь свои собственные серверы. В кластере есть один выделенный сервер конфигурации, который управляет работой кластера. С помощью этого сервера можно добавлять новые брокеры в кластер и удалять ненужные, а также устанавливать единую политику безопасности: пользователей, их права доступа, защиту сообщений и многое другое. При этом сам сервер конфигурации может принадлежать кластеру или находиться за его приделами и даже управлять несколькими кластерами.

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

Транзакции

Важным аспектом современной системы передачи сообщений является поддержка транзакций — неделимых последовательностей сообщений, которые гарантированно переводят информационную систему из одного устойчивого состояния в другое. В SonicMQ поддержка транзакций базируется на стандартном наборе интерфейсов — Java Transaction Services (JTS). В этот набор входят пять интерфейсов для работы с менеджером транзакций, сервером приложений, приложением, участвующим в транзакции, менеджером ресурсов и коммуникационным менеджером. Наиболее важным из них является интерфейс высокоуровневого управления менеджером транзакций. Все остальные интерфейсы нужны для организации сложных распределенных транзакций с участием внешних систем, например монитора транзакций.

В SonicMQ транзакцию инициирует менеджер ресурсов, который направляет соответствующий запрос менеджеру транзакций. В случае локальной транзакции всеми остальными операциями управляет менеджер транзакций. При распределенной транзакции в ней также участвуют и удаленные менеджеры транзакций, которые контролируют выполнение операций транзакции своими локальными менеджерами ресурсов (рис. 1). Еще одной особенностью распределенной транзакции является двухфазная фиксация. В первой фазе выполняется подготовка к фиксации, когда каждый менеджер независимо от других выполняет свою часть транзакции. Если все менеджеры успешно выполнили все операции транзакции, то система переходит во вторую фазу — собственно фиксация. Если же хотя бы на одном брокере или кластере возникла ошибка, то вся система на всех брокерах возвращается в первоначальное состояние — выполняется откат транзакции.

Рис. 1. Контроль выполнения транзакции

Все функции по работе с транзакциями в SonicMQ собраны в стандартных интерфейсах JTA XAResource и JMS XA SPI. Первый относится к пакету java.transaction.xa и содержит интерфейсы XAResource, Xid и XAExeption, дающие приложению возможность управлять транзакционными компонентами. Второй набор интерфейсов является частью клиента и обеспечивает работу системы передачи сообщений в режиме транзакций. Для этого предусмотрены специальные соединения по организации подключения клиентов для индивидуальных (XAQueueConnection) и массовых (XATopicConnection) транзакций. Все сеансы, открытые в рамках этих соединений, будут обслуживаться как компоненты транзакции.

Для того чтобы управлять транзакцией, приложение должно получить объект XAResource, используя специальное транзакционное соединение. Пример программы, которая передает сообщение с поддержкой индивидуальной транзакции, приведен в листинге 2. Аналогичным образом можно реализовать интеграцию SonicMQ с сервером приложений и внешним монитором транзакций.

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

Литература

[1] Николай Игнатович. IBM MQSeries: архитектура системы очередей сообщений. «Открытые системы», 1999, № 9-10

Поделитесь материалом с коллегами и друзьями