Интеграция приложений на основе WebSphere MQ
Лекция #1: Системы очередей сообщений В данной лекции дается краткий обзор, определяющий место очередей сообщений среди различных категорий промежуточного программного обеспечения, излагаются основные функции и особенности архитектуры очередей сообщений. Подробное использование этих функций в системе WebSphere MQ рассматривается в последующих лекциях. Кроме того, здесь приводится материал о развитии технических функций системы очередей сообщений в семействе программных продуктов MQSeries – WebSphere MQ в исторической перспективе.
### Интеграция приложений – пути решения Современные корпоративные системы характеризуются как сверхсложные и гетерогенные, распределенные по различным платформам. Положение большинства предприятий в настоящее время во многом определяется тем, что логика интеграции и взаимодействия систем встроена в отдельные приложения. Технология взаимодействия приложений ограничена транспортными механизмами для передачи данных. Потребности бизнеса и набирающего силу электронного бизнеса диктуют необходимость связи и интеграции этих гетерогенных систем и платформ. Современным корпорациям требуются надежные и тотально-распределенные вычислительные инфраструктуры, интегрирующее middleware, решающее задачи интеграции различных прикладных систем между собой. Появился даже специальный термин – Enterprise Application Integration (EAI) – Интеграция Приложений. Общепринятый в мировой практике подход к интеграции заключается в уходе от создания прямых интерфейсов приложений и в использовании интеграционного связующего программного обеспечения (ПО), которое способно обеспечить выполнение всех функций, необходимых крупной корпорации. В результате становятся возможными централизация и стандартизация подхода к интеграции, что позволит предприятиям разработать интеграционную среду, которую можно будет совершенствовать и изменять в соответствии с эволюцией бизнес среды. Для решения задач интеграции приложений существует так называемое промежуточное программное обеспечение (middleware), призванное решать проблемы взаимодействия между распределенными прикладными и системными программными компонентами. Промежуточное ПО позиционируется как системный слой между прикладными программами и операционными системами. Использование промежуточного программного обеспечение становится особенно важным когда идет речь о физически или логически (может быть даже на одной аппаратной платформе) распределенной системе. Среди разнообразного промежуточного ПО принято выделять три базовых категории, представленных рис.1.1: Промежуточное ПО для управления базами данных. Примерами из этой категории являются средства удаленного доступа в базам данным, компоненты или библиотеки Open Database Connectivity (ODBC) и Java Database Connectivity (JDBC). Коммуникационное промежуточное ПО обеспечивает программам обращение в другим удаленным программам, библиотеки удаленного вызова процедур (remote procedure call -RPC), средства передачи и обмена сообщениями (message-oriented middleware - MOM) и другие подобные технологии. Платформенное промежуточное ПО помогает взаимодействию компонент в рамках среды исполнения прикладной логики, такое как сервера приложений, мониторы транзакций, порталы, брокеры объектных запросов (object request broker- ORB). Рис. 1.1. Базовые категории промежуточного программного обеспечения Помимо базового промежуточного ПО часто выделяют специализированное интеграционное промежуточное ПО, куда относятся средства позволяющие взаимодействовать программам и системам, принципиально различным друг от друга. Примерами таких систем могут быть интеграционные брокеры, системы управления бизнес-процессами, шлюзы и адаптеры к различным системам. Системы очередей сообщений (MQ-Message Queuing) или чуть более общую группу систем, использующих технологию передачи сообщений (Messaging Oriented Middleware - МОМ), принято относить к категории middleware - промежуточного программного обеспечения или, более точно, к базовому коммуникационному программному обеспечению, однако часть функциональных возможностей систем очередей сообщений позволяют говорить об этом программном обеспечении как об интеграционном. Отметим сразу ориентацию на асинхронное взаимодействие программ как на ключевое отличие систем очередей сообщений от наиболее распространенных в среде распределенных клиент-серверных решений технологий синхронного удаленного вызова процедур (RPC). Целый ряд функций, поддерживаемых системами очередей сообщений наилучшим образом, таких как гарантированная доставка информации, разнообразные модели взаимодействия программ (один к одному, многие ко многим, контексная адресация и обработка) делают эту технологию привлекательной для ряда задач, в первую очередь интеграционных. Многие аналитики, например Gartner Group, наблюдающие современные тенденции в компьютерной индустрии, отмечают очень быстрый рост количества решения, использующих очереди сообщений в силу гибкости подобной архитектуры. На рынке присутствуют целый ряд систем очередей сообщений, каждая со своими особенностями. При этом система очередей сообщений фирмы IBM MQSeries - WebSphere MQ является, бесспорно, самой распространенной системой, занимает более 80 процентов рынка в данной категории и может считаться неофициальным стандартом и эталоном системы очередей сообщений. В качестве примеров некоторых других известных систем очередей сообщений можно назвать: Message Queue (MSMQ) Services компании Microsoft, EntireX компании SoftWareAG, Advanced Queuing (AQ) компании Oracle, FioranoMQ компании Fiorano, SonicMQ компании Sonic Software, TIB/Rendezvous компании Tibco Software. ### Функции и модели взаимодействия системы очередей сообщений Система очередей сообщений обеспечивает асинхронный метод взаимодействия для программ. Метод не требует установления прямой связи между интегрируемыми программами и позволяет поддерживать обмен данными в виде сообщений, независимо от аппаратной или операционной системы. При этом гарантируется, что сообщение не будет потеряно или получено дважды. Система очередей сообщений предоставляет прикладным программам сервис для отправки и получения сообщений. Очереди представляют промежуточное место хранение сообщений, как бы специализированную базу данных со всеми механизмами, гарантирующими сохранность: журналирование, восстановление после сбоев, транзакционная обработка. При этом приложения обращаются к очередям при помощи прикладного программного интерфейса. Сообщение, предназначенное для другой программы, должно быть доставлено в очередь назначения. Сообщение может передаваться через распределенную систему серверов - менеджеров очередей. Каждый раз, получая сообщение, менеджер очередей записывает сообщение в локальную очередь, затем передает сообщений по сети другому менеджеру очередей. При этом гарантируется, что сообщение не будет потеряно или получено дважды. Программа-адресат обращается к целевой очереди и получает доступ к сообщению. Поддержка асинхронного взаимодействия приложений при использовании очередей сообщений позволяет гибко интегрировать разнородные прикладные системы, не меняя внутренней логики их работы. Существование промежуточного звена в виде очередей сообщений позволяет вставлять промежуточную обработку передаваемой информации для решения самых различных задач: обеспечение безопасности, трансформации данных в разных форматах, динамической маршрутизации, анализа содержания передаваемых данных и так далее. Промежуточное звено позволяет применять различные топологии вычислительной среды, соединяя потоки данных для централизованной унифицированной обработки и разделяя их для функционально разнородной обработки. Средства МОМ имеют своих предшественников в виде систем для передачи файлов типа FTP, решений типа экспорта - импорта данных с использование различных промежуточных хранителей: файлов, буферов памяти, баз данных. Находяясь долгое время в виде вспомогательных и частных средств, класс подобного программное обеспечения стал бурно развиваться и стандартизироваться в связи с выходом на первый план задач интеграции прикладных систем между собой. Системы очередей сообщений позволяют программам отправлять и получать данные, не соединяясь друг с другом напрямую. Приложения изолируются друг от друга транспортным слоем, состоящим из менеджеров очередей, берущих на себя задачи обеспечения коммуникаций. С помощью очередей сообщений (рис.1.2) могут быть реализованы как традиционные модели взаимодействия программ (клиент-сервер), так и модели, которые реализуются только при помощи сервиса сообщений. Рис. 1.2. Взаимодействие клиент-сервер через очередь сообщений #### Модель клиент/сервер Запросы клиента передаются в виде сообщений в серверную очередь. После обработки запроса приложение-сервер, отправляет ответ в виде нового сообщения в очередь, указанную клиентом в сообщении-запросе. #### Асинхронное взаимодействие При использовании очередей сообщений, нет необходимости, чтобы взаимодействующие приложения были активны одновременно. Программа может отправить сообщение другому приложению, которое обработает его, когда сочтет нужным. Отправив сообщение, программа может не ожидать ответа, а продолжать выполнение других задач. #### Запуск программы Сообщение, посланное одной прикладной программой, может инициировать старт другого приложения. В таком случае по команде программы-монитора, приложение-адресат запускается и обрабатывает сообщение. #### Параллельная и распределенная обработка Исполнение прикладного процесса может быть распределено между несколькими прикладными программами. Старт, координация между программами и консолидация результатов обработки на разных системах реализуются путем пересылки сообщений через очереди. #### Адресация по принципу публикация-подписка Прикладные программы-публикаторы посылают свою информацию с указанием темы в виде сообщения менеджеру очередей. Другие приложения - подписчики присылают заявки на информацию по темам. Присланные публикации распределяются между подписчиками через очереди сообщений специальной программой - брокером в соответствии с темами публикаций. ### Основные компоненты и особенности работы системы очередей сообщений Основными элементами системы очередей сообщений являются: сообщения, которые прикладные программы посылают друг другу; очереди, где хранятся сообщения; менеджеры очередей – серверные компоненты, которые управляют очередями и обработкой сообщений; каналы передачи сообщений, которые связывают менеджеры очередей между собой. Введем следующие определения. Сообщения (Message) представляют собой структуру данных, состоящую из заголовка сообщения (MQMessageDescriptor) и прикладных данных (рис.1.3). Заголовок содержит контрольную и адресную информацию о сообщении и его характеристиках. С помощью этой информации менеджер очередей решает, каким образом обрабатывать и куда надо передавать сообщение. В создании и изменении заголовочной информации принимают участие, как приложения - отправители, так и системные компоненты менеджера очередей. Содержание контрольной информации важно для безопасности системы передачи сообщений и поэтому для изменения и перекопированния контрольной информации в новые сообщения определяются специальные права. Рис. 1.3. Структура сообщения Прикладная часть сообщения может включать данные в специальных предопределенных форматах или данные в форматах пользователя. WebSphereMQ поддерживает произвольные форматы данных, однако бывают системы очередей сообщений, которые разрешают только свои специальные форматы, например XML специального вида. Поскольку в распределенной среде для приложений, функционирующих под управлением различных ОС существуют различные кодовые страницы и методы представления данных, система очередей должна поддерживать методы конвертации передаваемых данных. Очередь сообщений (Queue) - основное место хранения и обработки сообщений. Физическое управление очередями полностью скрыто от прикладных программ. Приложения имеют доступ к очередям через программный интерфейс MQI (Message Queue Interface). Для передачи критически важной информации используется "постоянные" (persistence) сообщения, которые журналируются и восстанавливаются после рестарта менеджера сообщений. Для повышения производительности системы очередей сообщений поддерживает также и "непостоянные" сообщения, которые содержатся в оперативной памяти, не журналируются и могут быть потеряны в результате системного или аппаратного сбоя. Менеджер очередей (Queue Manager) является главным серверным компонентом и отвечает за управление очередями сообщений и прием вывозов от прикладных программ. Внутренняя реализация менеджеров очередей для каждой операционной системы своя. Однако с функциональной точки зрения менеджеры очередей поддерживают единый программный интерфейс, единую систему адресации и обмена данных через каналы, и единую систему администрирования. #### Прикладной программный интерфейс Прикладные программы взаимодействуют с WebSphereMQ через программный интерфейс MQI (Message Queue Interface). MQI имеет единую структуру на всех платформах и основан на простой системе из десятка команд: команда подключения к менеджеру очередей MQCONN команда открытия очереди MQOPEN команда помещения сообщения в очередь MQPUT команда выборки сообщений из очереди MQGET вспомогательные команды запроса и установки атрибутов очередей MQINQ и MQSET команды успешного завершения транзакции MQCMIT команда отката транзакции назад MQBACK команда закрытия очереди MQCLOSE команда отсоединения приложенияот менеджера очередей MQDISC. При создании приложений, обеспечивается поддержка интерфейса MQI для языков программирования: C/С++, Java, SmallTalk, Cobol, PL/1, Lotus LSX, Basic. Надо отметить, что разработка приложений для систем очередей сообщений имеет свои особенности, приведенные в последующих лекциях. #### Распределенная передача сообщений: Как сообщение попадает в очередь, если очередь находится на другой системе? Пользовательские приложение не обязаны знать внутреннюю структуру системы очередей сообщений, где физически размещены очереди, какие коммуникации существуют между менеджерами очередей. Приложение, обращаясь к менеджеру очередей, всегда получает доступ только к локальным очередям сообщений. Когда приложение посылает сообщение в очередь, расположенную на удаленной системе, то сообщение записывается в специальную транспортную очередь (transmission queue), что обеспечивает надежное сохранение сообщения, а уже затем сообщение переправляется по каналу передачи сообщений другому менеджеру на удаленную систему. На рис.1.4 показаны основные элементы, участвующие в передаче сообщения - от приложения к менеджеру очередей A и затем в удаленную очередь на менеджере очередей B. #### Каналы передачи сообщений: Как сообщения пересылаются по сети? В распределенной среде за передачу сообщений отвечает сетевые компоненты системы очередей сообщений. В IBM WebSphere MQ используется система каналов передачи сообщений, обеспечивающая гарантированную передачу сообщений поверх разнообразных сетевых соединений. При использовании протокола гарантированной передачи WebSphere MQ MCP (Message Channel Protocol) посылаемое сообщение не будет удалено из очереди на сервере посылки до тех пор, пока это сообщение не будет полностью принято на сервере - адресате, то есть реализуется сетевая транзакция при передачи сообщений. Рис. 1.4. Передача сообщений между системами Каналы соединяют менеджеры очередей и позволяют осуществлять направленную посылку сообщений. В 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). Рис. 1.5. Обработка событий при помощи триггеринга Триггеринг достаточно часто применяется в качестве стандартного метода автоматического старта каналов между менеджерами очередей. Для этого достаточно в качестве триггерных очередей объявить транспортные очереди, содержащие сообщения для передачи удаленному менеджеру очередей. #### Администрирование системы очередей сообщений: Как управлять распределенной системой очередей и каналов? Распределенная гетерогенная система, такая как система очередей сообщений MQSeries требует особенного внимания к вопросам удаленного администрирования. WebSphereMQ в этом аспекте предоставляет ряд интерфейсов и утилит для администрирования и конфигурации, включая администрирование очередей, каналов сообщений, безопасности. Для этих целей используются команды двух типов – скриптовые и программные. Административные скриптовые команды MQSC предназначены для работы администратора в режиме командной строки или для пакетного использования текстовых файлов-скриптов. При этом утилита командной строки RUNMQSC преобразует текстовые команды в вызовы API, а затем возвращает пользователю ответные сообщения (рис.1.6). Программный интерфейс PCF (Programmable Command Format) обеспечивает вызов административных функций непосредственно из прикладных программ. Для удаленного администрирования менеджеров очередей использует специальные командные очереди для приема/передачи административных команд-сообщений и специальные мониторы (command servers) для их исполнения. Рис. 1.6. Административные компоненты и интерфейсы WebSphereMQ Графические средства администрирования, в первую очередь WebSphereMQ Explorer позволяют удобно администрировать обьекты WebSphereMQ, создавать и изменять объекты и их параметры, следить за состоянием локальных и удаленных серверов. Более широкий подход предполагает включение системы очередей сообщений в корпоративную среду управления и использование общих пакетов управления системами: Tivoli Module for WebSphere Business Integration, Candle Omegamon, Command MQ (Bool&Babbage), Patrol KnowledgeModule для MQSeries (BMC). #### Средства безопасности в системе очередей сообщений: Как обеспечить необходимую защиту передаваемым данным? Для обеспечения безопасности при использовании приложениями системы очередей сообщений необходимо знать, какое приложение послало то или иное сообщение, контролировать, кто получает данное сообщение, обеспечить идентификацию удаленных менеджеров, а также контролировать выполнение административных команд. Обычно сама по себе система очередей сообщений не является пакетом для обеспечения безопасности, и обычно ограничивается стандартными функциями защиты каналов при помощи SSL. Вместе с тем WebSphereMQ позволяет легко подсоединять внешние компоненты безопасности. ##### Административные команды и доступ к объектам менеджера очередей Система очередей сообщений позволяет контролировать исполнение административных команд и доступ к объектам менеджера очередей - к самому менеджеру и очередям. WebSphereMQ имеет специализированную компоненту - менеджер безопасности, который позволяет определить и разграничить доступ к объектам. Кроме того, предоставляется документированный интерфейс для управления функциями безопасности, на основе которого возможно создать собственный менеджер безопасности. ##### Безопасность в каналах передачи сообщений Для защиты информации передаваемой между менеджерами очередей, WebSphereMQ поддерживает возможности подключения специально разрабатываемых модулей. Например, два менеджера очередей, устанавливающих связь по каналу, могут с помощью дополнительных программ опознать друг друга. Кроме этого, сообщения, передаваемые по каналу, могут шифроваться перед передачей и расшифровываться при приеме. ##### Безопасность приложений Программный интерфейс MQI предоставляет приложениям средства идентификации в сообщении пользователя, приложения и платформы. Идентификационная информация содержится с заголовке сообщения, передается вместе с ним и только привилегированные приложения могут ее изменять. Приложения могут использовать эту информацию для дополнительной проверки получаемых сообщений. #### Применение системы очередей сообщений Программное обеспечение систем очередей сообщений является одной из наиболее перспективных технологий для интеграции систем. Среди первостепенных достоинств систем очередей сообщений как решения для интеграции, можно указать простоту, надежность и универсальность данного подхода. Достоинства архитектуры очередей сообщений позволяют использовать ее, как для задач интеграции готовых приложений, так и разработки совершенно новых систем, базирующихся на принципах обработки событий и передачи сообщений и в полной мере использующих все преимущества новых подходов. Можно указать на следующие типичные задачи интеграции систем: Интеграция приложений в распределенной гетерогенной среде; Организация взаимодействия независимо работающих приложений или приложений, работа которых разделена во времени; Сложные распределенные и/или распараллеленные процессы обработки; Пересылка файлов, передача больших объемов данных; Синхронизация и репликация данных ; Поддержка мобильных клиентов. Достаточно частыми являются случаи кросс-платформенной интеграции, например, серверное приложение, работающее на рабочей станции под управлением операционной системы UNIX, должно посылать данные об обновлениях базы данных и проведенных транзакциях приложению на сервер системы iSeries или мейнфрейм. Между разными приложениями, работающими на одном мощном сервере, может быть организовано межсистемное взаимодействие, например, между подсистемами OS/390, когда другие технологии межсистемного взаимодействия оказываются более сложными. Многие сервисные организации, в первую очередь в области финансовых услуг, используют очередь сообщений как базовый транспорт, с помощью которого они предоставляют заказчикам свои услуги. Здесь важнейшими факторами являются гарантированная доставка сообщений, многочисленность аппаратных платформ, а также открытость решения, позволяющая подключать к системе очередей сообщений собственные прикладные компоненты, а также корпоративные и отраслевые средства обеспечения безопасности. Расширяемость системы. Важной характеристикой системы очередей сообщений является возможность расширять функциональность системы. Существование отрытых интерфейсов для встраиваемых модулей (канальные и интерфейсные user exits) и документированных интерфейсов для базовых сервисных компонент позволяет подключать к менеджеру очередей дополнительные модули, готовые или написанные пользователем, и использовать их для взаимного опознания систем, кодирования сообщений, компрессии данных и других задач. ### Развитие IBM MQSeries - WebSphere MQ История MQSeries как единого семейства программных продуктов начинается с 1992 года, когда IBM опубликовала спецификации для программного интерфейса Message Queue Interface (MQI). В том же 1992 году было заключено соглашение между IBM и фирмой System Strategies Inc.(SSI), которая тогда разрабатывала собственные продукты для передачи сообщений ezBRIDGE и Transact, которые были адаптированы для использования MQI. Местом разработки MQSeries является лаборатория IBM, находящаяся в местечке Херсли (Hursley) на юго-западе Англии. Европейское происхождение технологии возможно определило техническую проработанность продукта с одной стороны, и некоторый недостаток активной рекламы для него на рынке с другой. Первая версия MQSeries представляла собой сборный пакет из версий производства самой IBM для мейнфреймов, и продуктов System Strategies Inc.(SSI) для персональный компьютеров и UNIX платформ. Настоящей версией MQSeries можно считать только вторую, имевшую кодовое имя Mayflower. В качестве наиболее полного и четкого документа, описывающего назначение и архитектуру классической системы очередей сообщений можно порекомендовать документ IBM MQSeries Message Queue Interface Technical Reference, который еще можно найти через Интернет на сайтах компании IBM. В этом документе определяются типы сообщений и их контрольная структура, основные объекты менеджера очередей – очереди и каналы, принципы адресация и доставки сообщений на удаленные системы, вызовы и параметры программного интерфейса MQI, механизм триггеринга, транзакционные свойства, административные интерфейсы. С тех пор появилось много новых версий, существенно расширился круг платформ и функциональные возможности WebSphere MQ. Говоря о появлении новых версий, надо заметить, что менеджеры очередей MQSeries - WebSphere MQ даже разных версий взаимодействуют между собой и обеспечивают функционирование единой транспортной системы WebSphere MQ. При этом менеджер очередей устаревшей версии не сможет выполнить все новые функции обработки для сообщения, созданного на сервере последней версии, однако принять или переправить такое сообщение дальше, не потеряв его, менеджер старой версии безусловно может. Менеджер очередей для целого ряда платформ поддерживается на уровне функциональности второй версии – MQSeries V2.2 для DEC OVMS VAX V2.2, DEC OVMS AXP V2.2, Tandem NSK V2.2, SINIX and DC/OSx V2.2, AT&T NCR, V2.2. В 1997 появляется 5 версия MQSeries на новой кодовой базе Armada. В ней было ряд нововведений, в том числе: поддержка координации транзакций между очередями сообщений и внешними реляционными базами данных, увеличение предельного размера сообщений с 4 MB до 100 MB, рассылка сообщений по списку. В 1999 выходит следующая версия 5.1 [5], которая сопровождалась переделкой базового транспортного слоя, появлением многопоточных канальных агентов. Предельный размер очереди был увеличен до 2 GB. Для поддержки модели публикация-подписка IBM предложила специальный бесплатный брокер, который устанавливался поверх системы очередей сообщений. Существенным нововведением явился встроенный механизм интеллектуального администрирования и распределения нагрузки в системе из нескольких менеджеров сообщений – программные кластеры. В 2000 году появилась версия системы очередей сообщений для мобильных устройств MQSeries Everyplace. Разработанная на языке Java и существенно облегченная по потребляемым ресурсам MQSeries Everyplace была предназначена для покрытия новой быстроразвивающейся области применения информационных технологий. В 2000 году добавилось несколько новых программных интерфейсов. В MQSeries появилась поддержка JMS (Java Message Service), нового открытого стандартизированного интерфейса для передачи сообщений для программ на языке Java. Стандарт JMS разрабатывался фирмой Sun и был призван дать единый интерфейс для различных производителей систем очередей сообщений. В стандарте JMS сильно отразилось влияние MQSeries, особенно в модели взаимодействия приложений типа точка-точка. Кроме того, обобщая опыт интеграционных проектов, IBM предложило разработчикам новый программный интерфейс высокого уровня MQSeries AMI (Application Message Interface), призванный упростить разработку по сравнению со стандартным MQI. AMI позволяет использовать параметры низкого уровня MQI в сущностях сервисов и политик, удобные для разработки, настройки и администрирования. Следующая версия 5.2 была выпущена в 2001 году. Версия имела новую кодовую базу Flotilla, была направлена на улучшения производительности, в этой версии появилась поддержка операционной системы Linux. Главным видимым дополнением в версии 5.3 (проект Convoy) в 2002 году была встроенная поддержкой системы защиты каналов на базе технологии SSL. В этой версии появилась поддержка так называемых API exits – открытого интерфейса, позволяющего писать собственные модули дополнительной обработки, вызываемые при выполнении базовых программных вызовов. API exits являются очень мощным средством и, к счастью, избыточным для большинства стандартных задач. Кроме значительных для ряда задач в несколько раз улучшений производительности, эта версия система очередей сообщений расширила предельные ограничения на количество сообщений в одной очереди с 640 тысяч до миллиарда сообщений. В версии 5.3 произошло изменения привычного названия MQSeries на WebSphere MQ в целях маркетинга и рекламы семейства продуктов WebSphere как стратегической программной платформы для электронного бизнеса. В настоящее время менеджеры очередей WebSphere MQ, работают на следующих основных платформах: zOs, OS/390, MVS, VSE/ESA, OS/400, OS/2, Tandem NSK, Digital OpenVMS VAX, Digital Unix, AIX, HP-UX, SunOS, Sun Solaris, Linux, SCO UNIX, UnixWare, AT&T GIS UNIX, DC/OSx, Windows XP/2000/NT, Windows 98/95. Существуют также WebSphere MQ клиенты для многочисленных платформ.

© Макушкин В.А., Володичев Д.С. Все права защищены.