Учебная работа. Статья: IBM MQSeries: архитектура системы очередей сообщений

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (5 оценок, среднее: 4,80 из 5)
Загрузка...
Контрольные рефераты

Учебная работа. Статья: IBM MQSeries: архитектура системы очередей сообщений

Николай Игнатович

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

системы очередей сообщений (Messaging Oriented Middleware — MOM) принято относить к группы промежного ПО (то есть программное обеспечение — комплект программ для компьютеров и вычислительных устройств), которое в самом общем случае призвано решать трудности взаимодействия меж разными прикладными и системными программными компонентами. Почти все аналитики компьютерной промышленности, к примеру, спецы из Gartner Group, отмечают сейчас резвый рост числа решений, использующих очереди сообщений и подчеркивают при всем этом упругость и адаптируемость схожей архитектуры.

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

Семейство MQSeries

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

История 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, который имеет единую структуру на всех платформах и основан на обычный системе из 10-ка установок.

Взаимодействие с системой хоть какой прикладной программки начинается с команды подключения к менеджеру очередей 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(очередь коробки)}

Опосля установки связи из транспортной очереди в канале начинается передача сообщений. При передаче сообщений меж 2-мя менеджерами очередей употребляется особый протокол канала сообщения (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

Асинхронный нрав работы системы очередей сообщений просит специального механизма наружной активизации прикладных и системных компонент. В MQSeries таковой механизм — «триггеринг» привязан конкретно к очередям сообщений. Триггерным событием быть может, к примеру, возникновение в очереди новейшего сообщения либо факт скопления определенного числа сообщений, имеющих Ценность выше данного порогового значения.

Чтоб найти триггерное событие, для прикладной очереди с помощью административных установок инсталлируются функции, разрешающие триггеринг и условия триггерного действия. Не считая того, админом системы создается особое описание обработки такового действия. В описании содержится информация о приложении, которое будет вызвано при пришествии триггерного действия. Если происходит такое событие, к примеру, возникает новое сообщение в очереди, Менеджерочередей автоматом генерирует особое триггерное сообщение, которое помещается в очередь инициации (initiation queue). В триггерном сообщении содержатся данные о событии и вызываемом процессе. Все очереди инициации отслеживаются триггерным монитором, который читает триггерное сообщение и вызывает внешнюю программку обработки (рис. 2).

Рис. 2. Обработка «триггерных» событий

Приведем пример 2-ух административных установок для сотворения триггерной очереди и описания процесса вызова наружной программки:

DEFINE QLOCAL(имя очереди)

TRIGGER +

PROCESS(имя процесса) INITQ(имя

очереди инициации) +

TRIGTYPE(тип триггерного действия)

….

DEFINE PROCESS(имя процесса) +

APPLICID(имя вызываемой программки)

USERDATA(характеристики)…

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

Администрирование MQSeries

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

Административные текстовые команды 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 как в процессе интеграции готовых приложений, так и для разработки совсем новейших систем, управляемых сообщениями. Можно перечислить последующие обычные задачки:

Интеграция приложений в распределенной гетерогенной среде;

организация взаимодействия приложений, работа которых разбита во времени;

сложные распределенные и/либо распараллеленные процессы обработки;

задачки гарантированной доставки данных;

поддержка мобильных клиентов.

Почти все денежные организации и учреждения употребляют сейчас 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) — брокер сообщений, имеющий репозиторий форматов, на базе которого происходит определение и переформатирование содержания сообщений. В этом брокере имеется также база правил, определяющих процедуры обработки и маршрутизации сообщений.

Заключение

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

]]>