IBM MQSeries: архітектура системи черг повідомлень

Микола Ігнатович

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

Системи черг повідомлень (Messaging Oriented Middleware - MOM) прийнято відносити до категорії проміжного ПЗ, яке у загальному випадку покликане вирішувати проблеми взаємодії між різними прикладними та системними програмними компонентами. Багато аналітиків комп'ютерної індустрії, наприклад, фахівці з Gartner Group, відзначають сьогодні швидке зростання кількості рішень, що використовують черги повідомлень і підкреслюють при цьому гнучкість і адаптованість подібної архітектури.

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

Сімейство MQSeries

Попередники коштів МОМ з'явилися при вирішенні завдань обміну даними між програмами, коли розробники писали власні локальні чи мережеві модулі експорту-імпорту з використанням різних проміжних зберігачів: файлів, буферів пам'яті і т.д. Дане ПЗ довгий час існувало у вигляді допоміжних і приватних коштів, однак у зв'язку з виходом на перший план завдань інтеграції готових прикладних систем між собою системи МОМ отримали потужний стимул до розвитку і стандартизації.

Історія 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

Асинхронний характер роботи системи черг повідомлень вимагає спеціального механізму зовнішньої активізації прикладних і системних компонентів. У MQSeries такий механізм - "тріггерінг" прив'язаний безпосередньо до черг повідомлень. Тригерні подією може бути, наприклад, поява в черги нового повідомлення або факт накопичення певної кількості повідомлень, що мають пріоритет вище заданого порогового значення.

Щоб визначити тригерній подія, для прикладної черзі за допомогою адміністративних команд встановлюються опції, що дозволяють тріггерінг та умови тригерній події. Крім того, адміністратором системи створюється спеціальний опис обробки такої події. В описі міститься інформація про додатку, який буде викликано при настанні тригерній події. Якщо відбувається така подія, наприклад, з'являється нове повідомлення в черзі, менеджер черг автоматично генерує спеціальне тригерній повідомлення, що міститься в чергу ініціації (initiation queue). У тригерній повідомленні містяться дані про подію і викликається процесі. Всі черги ініціації відслідковуються триггерным монітором, який читає тригерній повідомлення і викликає зовнішню програму обробки (рис. 2).

Рис. 2. Обробка "тригерних" подій

Наведемо приклад двох адміністративних команд для створення тригерній черги та описи процесу виклику зовнішньої програми:

DEFINE QLOCAL (ім'я черги)

TRIGGER +

PROCESS (ім'я процесу) INITQ (ім'я

черги ініціації) +

TRIGTYPE (тип тригерній події)

....

DEFINE PROCESS (ім'я процесу) +

APPLICID (ім'я викликається програми)

USERDATA (параметри )...

Тріггерінг досить часто застосовується в якості стандартного методу автоматичного старту каналів між менеджерами черг. Для цього досить у якості тригерних оголосити транспортні черги, що містять повідомлення для передачі віддаленою менеджеру черг.

Адміністрування MQSeries

Розподілена гетерогенна система, така як 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 як у процесі інтеграції готових програм, так і для розробки абсолютно нових систем, керованих повідомленнями. Можна перерахувати наступні типові завдання:

інтеграція додатків в розподіленої гетерогенної середовищі;

організація взаємодії додатків, робота яких розділена в часі;

складні розподілені і/або распараллеленние процеси обробки;

завдання гарантованої доставки даних;

підтримка мобільних клієнтів.

Багато фінансові організації та установи використовують сьогодні 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) - брокер повідомлень, що має репозиторій форматів, на базі якого відбувається розпізнавання і переформатування змісту повідомлень. У цьому брокер має також база правил, що визначають процедури обробки та маршрутизації повідомлень.

Висновок

Рішення, що забезпечують взаємодію між розподіленими компонентами в рамках однієї прикладної системи, (наприклад клієнт-серверне рішення від одного розробника) частіше за все не забезпечують взаємодії між різними прикладними системами, особливо якщо ця взаємодія не було сплановано ще на етапі розробки. Саме в можливості підтримки міжсистемна інтеграції полягає особлива цінність систем передачі повідомлень. Використання ПЗ, що надається системами черг повідомлень як асинхронного механізму для організації взаємодії між програмами дозволяє створити уніфіковану транспортну шину для транзакційних та інформаційних обчислювальних систем різного масштабу. При створенні інформаційної інфраструктури в Росії з її географічної протяжністю і безліччю часових поясів досить актуально, а інколи життєво необхідно використовувати системи черг повідомлень.

Список літератури

Для підготовки даної роботи були використані матеріали з сайту http://www.citforum.ru/