НОУ ІНТУІТ, Лекція, Системи черг повідомлень
Канали надсилання повідомлень: Як повідомлення надсилаються через мережу?
Канали з'єднують менеджери черг і дозволяють здійснювати надсилання повідомлень. WebSphere MQ канали є односпрямованими і складаються з пари взаємодіючих канальних агентів (Message Channel Agent - MCA ). Для двостороннього зв'язку необхідно визначити два канали. Існує кілька типів каналів. Типи каналів відрізняються тим, яка сторона каналу є ініціатором установки зв'язку, яка джерелом повідомлень . У комбінації каналів типу Sender-Receiver одна сторона Sender є ініціатором зв'язку та джерелом повідомлень , друга сторона Receiver тільки відгукується на запит, що ініціює, і приймає потік повідомлень , в іншій комбінації канал Requestor-Server, ініціююча з'єднання сторона Requestor приймає повідомлення від сторони Server.
Після встановлення зв'язку з транспортної черги у каналі починається передача повідомлень. Повідомлення видаляються з транспортної черги менеджера , що передає , тільки після підтвердження доставки повідомлення іншим менеджером . Використання протоколу MCP контрольних точок дозволяє кінцям каналу синхронізувати передачу числа повідомлення у разі системного або мережного збою. Якщо лінія зв'язку недоступна, MQSeries може автоматично виконувати повторні спроби передачі після відновлення зв'язку. Протокол МСР використовується під час передачі повідомлень поверх транспортних протоколів нижчого рівня TCP/IP, LU6.2, DECnet , NetBios, IPX/SPX.
Адресація та маршрутизація повідомлень: Як повідомлення знаходить чергу призначення у розподіленому середовищі?
Механізм дозволу імен системи черг повідомлень використовується для організації багатокрокової маршрутизації повідомлень черездовільне число проміжних менеджерів черг.
Для відстеження та виправлення помилок менеджер черг має спеціальну чергу DLQ (Dead-Letter Queue) для зберігання недоставлених повідомлень . Найчастіше повідомлення потрапляють у DLQ, коли черга , зазначена в заголовку повідомлення , немає чи коли чергу призначення виявляється повної. Черги недоставлених повідомлень дають змогу розвантажити транспортні черги від помилкових повідомлень та звільнити канали від безперервних повторних обробок. При попаданні повідомлення в чергу недоставлених повідомлень до його тіла вставляється спеціальний інформаційний підзаголовок, що дозволяє аналізувати причини потрапляння до DLQ. MQSeries має механізм завдання для автоматичної обробки недоставлених повідомлень .
Транзакційні властивості: Як забезпечується цілісність даних та синхронізація зміни у повідомленнях?
Корпоративна система черг повідомлень повинна обов'язково включати механізми транзакцій. Прикладна програма позначає частину своїх повідомлень, що отримуються і надсилаються спеціальною опцією - що беруть участь у транзакції. До виконання додатком команди на завершення транзакції, надіслані цим додатком повідомлення є фактично "невидимими" для інших додатків, а отримані додатком повідомлення реально не видаляються з черг. У разі виконання додатком команди на відкат транзакції повідомлення в черзі відновлюються до стану початку транзакції.
WebSphereMQ володіє своїм внутрішнім менеджером ресурсів, який також підтримує зовнішній XA інтерфейс, і може брати участь у розподіленій транзакції під управлінням таких моніторів транзакцій як CICS, Encina, Tuxedo. Самі по собі сервери WebSphereMQ , починаючи з версії 5, можуть бутикоординаторами розподілених транзакцій із двофазною фіксацією.
Тригерні можливості: Як активізувати програму обробки?
Асинхронний характер роботи системи черг повідомлень потребує спеціального механізму зовнішньої активізації для старту прикладних та системних компонентів. У WebSphereMQ такий механізм - "тригерінг" прив'язаний безпосередньо до черг повідомлень. Як тригерні події можуть виступати, наприклад, поява в черзі нового повідомлення або енного повідомлення з пріоритетом вище певного порогового значення.
Щоб визначити тригерну подію, для прикладної черги за допомогою адміністративних команд встановлюються опції, що дозволяють тригеринг та умови тригерної події. Крім того, адміністратором системи створюється спеціальний опис обробки тригерної події. У цьому описі міститься інформація про програму, яка буде викликана при настанні тригерної події. У разі виникнення такої події, наприклад, появи нового повідомлення в черзі, менеджер черг автоматично генерує спеціальне тригерне повідомлення, яке міститься в спеціальну чергу ініціації (initiation queue). У тригерному повідомленні містяться дані про подію і процес, що викликається. Усі черги ініціації відстежуються тригерним монітором, який читає тригерне повідомлення та викликає зовнішню програму обробки (рис.1.5).
Тригерінг досить часто застосовується як стандартний метод автоматичного старту каналів між менеджерами черг. Для цього достатньо як тригерні черги оголосити транспортні черги, що містять повідомлення для передачі віддаленому менеджеру черг.