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

В последующем на фоне всеобщего «сдвига ИТ-парадигм», вызванного взрывным ростом Internet-технологий, в этой области сохранялась несколько необычная ситуация стабильности. Она настолько затянулась, что, например, в мае 2000 года в статье «Демистификация программного обеспечения промежуточного слоя», опубликованной в журнале CIO Magazine, средства MOM (message-oriented middleware) были названы «старыми и добрыми» (dear old MOM). И вот неожиданно эта «пожилая» технология оказалась в центре внимания. За последние два года она вышла из тени и попала в число самых «горячих». Что же произошло?

«Электронная почта» для корпоративных приложений

Итак, десятилетиями события, происходившие в лагере MOM, не отличались особой экстраординарностью. Все здесь развивалось на редкость спокойно. Первое оживление датируется 1993 годом, когда была образована ассоциация Message Oriented Middleware Association (MOMA). Затем на протяжении нескольких лет в этой области доминировали две всем известные корпорации со своими известными продуктами, а именно IBM с программным обеспечением MQSeries, которой принадлежало 75% рынка, а также несколько позже вышедшей на него Microsoft с продуктом MSMQ. Оставшийся небольшой сегмент достался компаниям существенно меньшего масштаба, скажем, Talarian с продуктом SmartSockets или Tibco с Tibco RV. Традиционное видение места средств MOM до событий последних дней в общей картине ПО промежуточного слоя описано в [1].

Изменение ситуации вызвано развитием разного рода Internet-приложений. Признание электронной почты в качестве классического примера «убойного приложения» (killer application), давшего сильнейший импульс развитию Internet, стало каноническим. Но это уже история, а вот теперь, когда не только люди, но и приложения вышли в Сеть, возникла логическая необходимость сделать следующий шаг в этом направлении, установить привычный «почтовый» способ взаимодействия, но теперь не между людьми, а на этот раз между приложениями, наступил момент для конвергенции MOM и электронной почты.

Справедливости ради надо сказать, что раньше специализированных ИТ-компаний идею интеграции корпоративных приложений на почтовых принципах, близкую к современному видению предложили специалисты из корпорации Cargill, крупнейшего дистрибьютора продуктов питания. Они построили ее непосредственно на базе корпоративной почтовой системы HP OpenMail.

А затем обнаружилось, что подобный подход соответствует более широкому классу приложений. Разумеется, речь не идет об универсальном подходе, и не ко всем приложениям вообще, а только о таких приложениях, где транзакции осуществляются в основном через Internet, т.е. для взаимодействий категорий business-to-business и business-to-consumer. Примечательная особенность этого типа приложений заключается в том, что в отличие от, скажем, сложных математических вычислений или управления объектами в реальном времени, эти приложения слабо связаны между собой (loosely coupled) и, следовательно, допускают асинхронный обмен сообщениями (asynchronous messaging). Именно такой стиль взаимодействия и реализует электронная почта.

Однако почему именно в последнее время так обострился интерес к новым системам для обмена сообщениями? Дело в том, что асинхронный обмен показал свою эффективность как коммуникационная модель при разработке критически важных приложений уровня предприятия. По сравнению с традиционными системами клиент-сервер, система с обменом сообщениями обладает большей масштабируемостью и гибкостью, она не требует, чтобы все приложения «шагали в ногу». (Английское слово lockstep, переведенное в данном случае как «в ногу», гораздо шире по смыслу, оно не просто означает единообразие шага, но еще и относится к строгим процедурам, требующим отказ от индивидуальности, бессловесное подчинение. — Л.Ч.) Приложения деловой направленности не нуждаются в подобной жесткости. Отсюда и возник интерес к более «демократическим» решениям.

Архитектура систем МОМ

Теоретически существует два альтернативных архитектурных подхода к системам обмена сообщениями приложениями: топология «ступица и спицы» (hub-and-spoke) и шинная топология.

В централизованной архитектуре hub-and-spoke все приложения подключаются к центральному процессу, называемому сервером сообщений (message server), он отвечает за корректность маршрутизации сообщений, аутентификацию и авторизацию пользователей. Сами приложения рассматриваются как клиенты; они могут быть передатчиками и/или приемниками.

Централизация в стиле hub-and-spoke обладает рядом преимуществ.

  • Ограниченное количество сетевых соединений: каждому приложению достаточно иметь одну единственную связь с сервером сообщений.
  • Гибкость, поскольку маршрутизацией управляет сервер; приемники и передатчики независимы друг от друга, они могут изменяться с минимальной деформацией всей системы в целом.
  • Минимальные требования к клиентскому программному обеспечению, поскольку вся логика соединений сосредоточена на сервере.
  • Возможность обеспечения требуемой степени отказоустойчивости, один логический процесс на сервере может быть физически размещен на аппаратном сервере с кластерной конфигурацией.

Этих преимуществ лишена шинная архитектура, где каждое приложение (обычно оно подключается на сетевом уровне многоуровневого стека протоколов TCP/IP) должно обладать функциональностью сервера.

Но в этом году все радикально изменилось: появилась созданная в корпорации Sun Microsystems служба сообщений Java Message Service (JMS), для того чтобы обеспечить асинхронный обмен сообщениями по IP-сетям между слабо связанными Java-приложениями. И вот она-то и внесла заметную смуту в этот остров стабильности.

Однако если представить МОМ на самом поверхностном уровне, то можно сказать, что прикладные системы, построенные на основе механизма обмена сообщениями, целесообразно разделить на три основные категории в соответствии с тем, как именно организована дисциплина обмена. (См. рис. 1.)

  1. «Точка-точка» (P2P — point-to-point messaging) где разные приложения могут посылать сообщения одному из них (рис. 1а). Клиент может выступать в роли передатчика, приемника, а также одновременно и приемника и передатчика. В JMS использована концепция очереди (queue). Передатчик помещает сообщение в очередь, а приемник их последовательно выбирает — полная аналогия с электронной почтой.
  2. «Публикация и подписка» (P/S — publish-and-subscribe messaging) где множество приложений получают одно и то же сообщение (рис. 1б). Сообщения помещаются в общую разделяемую область, называемую topic (в данном случае это слово можно перевести как «предмет обсуждения»). Помещенное туда сообщение становится доступным всем клиентам, которые могут выступать и в роли передатчика, и в роли приемника.
  3. «По запросу» (request-reply messaging) где приложение посылает запрос приемнику.

Системы нового поколения

Итак, технологической основой для всех сред обмена сообщениями нового поколения стала спецификация Java Message Service, в деталях определяющая, как взаимодействуют клиенты и серверы в среде асинхронных сообщений (рис. 2). Она была очень быстро воспринята рынком. К числу достоинств JMS относится то, что она соответствует современным представлениям о взаимодействии приложений и не требует специальных знаний и доступна для любого программиста, работающего на языке Java. Этими качествами она заметно отличается от инструментария MQSeries, где необходима специальная подготовка. В сентябре этого года, 21 месяц спустя после релиза J2EE 1.2, корпорация Sun Microsystems объявила о версии 1.3 Java 2 Enterprise Edition куда JMS уже включена как стандартный компонент.

Еще один стимул для второго рождения MOM — появление расширяемого языка разметки данных XML в качестве своеобразного «лингва-франка» для Internet-приложений, позволяющего одним приложениям понимать другие.

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

Сегодня JMS стала основой целого инженерного направления; полноценно ее можно представить только в объеме большой книги, и такая книга уже есть. Первый труд, полностью посвященный JMS, написан коллективом авторов из нескольких лидирующих в этой области компаний [2].

Почти мгновенно JMS оказалась востребованной со стороны бизнеса. Вскоре появился класс новых программных продуктов категории МОМ: MQ Express (компания Talarian), Tib/Rendezvous (Tibco Software), SonicMQ (Progress Software), iBus (Softwired) FioranoMQ (Fiorano Software), возможно, есть и другие. Эти новые представители программного обеспечения промежуточного слоя, построенные на фундаменте Java, оказались в состоянии составить конкуренцию MQSeries и по цене, и по гибкости, производительности и другим показателям — но не в одночасье. Как считают эксперты, никакого резкого отхода от MQSeries не будет.

Среди новых продуктов наибольшей популярностью обладают SonicMQ и FioranoMQ; сейчас именно эти две системы следует рассматривать в качестве наиболее близких конкурентов. SonicMQ обеспечивает полную реализацию JMS; помимо моделей P2P и P/S поддерживаются клиенты ActiveX/COM. В FioranoMQ также реализованы все основные функции сервера сообщений, есть возможность интегрировать его с другими серверами приложений. FioranoMQ и SonicMQ обеспечивают работу с такими расширениями, как сообщения XML и кластеризация серверов. Хотя эти две программные системы часто сравнивают между собой, однако в качестве эталона обе компании — Progress Software и Fiorano Software — неизменно используют MQSeries.

Существует несколько свойств, по которым их можно сравнивать между собой, например, по качеству управления потоками, по способности к масштабированию и по времени задержки сообщений. Одним из важнейших показателей серверов сообщений, естественно, является их способность управлять потоками сообщений. Обычно скорость, с которой сообщения производятся, превосходит скорость их потребления, поэтому очень важно «дросселировать» эти потоки, чтобы исключить потерю сообщений. В частности, для модели «публикации и подписки» существенно, чтобы самый медленный клиент не тормозил работу всей системы в целом.

Общепризнанной выработанной методики для сравнения систем MOM пока еще не существует. Поэтому у каждого из производителей есть возможность доказать преимущество своих программных продуктов над другими. Если кому-то покажется это интересным, рекомендую скачать с сайтов Progress Software и Fiorano Software документы под приблизительным названием «High-performance Messaging with JMS» и убедиться в их взаимной ортогональности. Каждая из компаний умело доказывает преимущество собственной разработки над другой и над IBM с ее MQSeries.

Литература

[1] David E. Bakken, «Middleware», глава из готовящейся к выходу в свет книги Encyclopedia of Distributed Computing, Kluwer Academic Press, 2001, www.eecs.wsu.edu/~bakken/middleware.pdf.

[2] Scott Grant, Michael P. Kovacs, Meeraj Kunnumpurath, Silvano Maffeis, K. Scott Morrison, Gopalan Suresh Raj, Paul Giotta, «Professional JMS». (Информацию об этой книге и отдельные главы из нее можно найти в Web по адресу http://www.execpc.com/ ~gopalan/jms/ jms.html.)