НТУ «ХПІ»
Кафедра: ПІІТУ
Дисципліна: Архітектури та технології розподілених програмних систем
Лектор: доц. Р.О. Гамзаєв
ЛАБОРАТОРНИЙ ПРАКТИКУМ
ЛАБОРАТОРНА РОБОТА № 5
ТЕМА: Технологія JMS (Java Messaging Services )
МЕТА РОБОТИ: Ознайомитись з технологією JMS (Java Messaging Services )
Загальні відомості
Обмін повідомленнями
Обмін повідомленнями – це метод комунікації між програмними компонентами або додатками. Компонент відправляє повідомлення в пункт призначення, і одержувач може отримати повідомлення від адресата. Проте, відправник і одержувач не повинні бути доступні в той же час, щоб спілкуватися. Насправді, відправник не повинен нічого знати про одержувача, а також одержувачу непотрібно нічого знати про відправника. Відправник і одержувач повинні знати тільки, який формат повідомлення та який пункт призначення необхідно використовувати.
Message-Oriented Middleware (MOM)
Традиційні розподілені системи, побудовані на основі RMI, мають ряд суттєвих недоліків, таких як синхронність (клієнт, зробивши запит, повинен чекати відповіді від сервера) в тому випадку, коли процес обробки запиту займає відносно великий проміжок часу; клієнт і сервер повинні бути активні в мережі (якщо клієнт спробує зробити запит до сервера, який не активний в даний момент, він отримає повідомлення про помилку). Виходом з даної ситуації може служити Messaging System.
Messaging System - це розподілена система, що заснована на асинхронному обміні повідомленнями (messages) між компонентами систем за допомоги Message-Oriented Middleware.
Message-Oriented Middleware - це проміжний шар, що орієнтований на обмін повідомленнями в розподіленому оточенні, який призначений для реалізації відкладеного обміну повідомленнями. Якщо один компонент системи хоче послати повідомлення іншому компоненту, він посилає дане повідомлення MOM, а вже MOM потім пересилає його адресату (рис. 1).
Рисунок 1 – Обмін повідомленнями за допомоги МОМ
MOM дозволяє позбутися від вище згаданих недоліків. Додаток, що послав повідомлення, не повинен чекати відповіді, і може продовжувати свою поточну діяльність. Ні додаток, що посилає повідомлення, ні адресат даного повідомлення не зобов'язані бути активними в один і той же час. Якщо адресат повідомлення не активний, то MOM гарантує, що повідомлення буде доставлено як тільки адресат стане активним.
Моделі обміну повідомленнями
Існує дві "основних" моделі обміну повідомленнями:
point-to-point (PTP);
publish-subscribe (pub/sub).
PTP продукт або програма побудована на концепції черг повідомлень, відправників і одержувачів. Кожне повідомлення адресоване певній черзі, і клієнти-отримувачі витягують повідомлення з черг, встановлених для зберігання своїх повідомлень. Черги зберігають всі повідомлення, відправлені на них, поки повідомлення будуть використовуватись або не закінчиться термін їх зберігання.
Рисунок 2 – РТР
РТР повідомлення, що показані на рисунку 2, мають наступні характеристики:
Кожне повідомлення має тільки один одержувач.
Відправник і одержувач повідомлення не мають ніяких залежностей синхронізації. Одержувач може одержати повідомлення і не має значення був він запущений чи ні, коли клієнт посилав повідомлення.
Одержувач підтверджує успішне обробку повідомлення.
У pub/sub продукті або програмі, клієнти надсилають повідомлення в тему, яка функціонує щось на кшталт дошки оголошень. Видавці (publishers) і абоненти (subscribers), як правило, є анонімними і можуть динамічно публікувати або підписатися на ієрархії контенту. Система дбає про поширення повідомлень, що надходять від декількох видавців теми, до своїх численних абонентів. Теми зберігають повідомлення тільки до тих пір, поки це потрібно, щоб розподілити їх існуючим абонентам. Рисунок 3 ілюструє pub/sub обмін повідомленнями.
Pub/sub обмін повідомленнями має наступні характеристики:
Кожне повідомлення може мати кілька споживачів.
Видавці і абоненти мають залежність від часу. Клієнт, який підписується на тему може одержувати тільки ті повідомлення, що опубліковані після того, як клієнт створив підписку, і абонент повинен продовжувати бути активним для того, щоб отримувати повідомлення.
Рисунок 3 – Pub/sub
JMS API розслабляє цю тимчасову залежність в деякій мірі, дозволяючи абонентам створити міцні підписки (durable subscriptions), які отримують повідомлення, відправлені в той час як абоненти не активні. Міцні підписки забезпечують гнучкість і надійність черг, але як і раніше дозволяють клієнтам відправляти повідомлення декільком одержувачам.