Асинхронне спілкування, Світ ПК, Видавництво «Відкриті системи»
Синхронний та асинхронний режими взаємодії можуть бути реалізовані з використанням різних транспортних протоколів. Стосовно Java-технологій часто синхронний виклик називають «дзвінком у стилі RPC» (Remote Procedure Call), а асинхронний — «відправкою повідомлення» (англійською — messaging). Асинхронна взаємодія в стилі messaging займає важливе місце у розподілених системах. Мабуть, основними перевагами такого способу взаємодії є:
На рівні використання мови Java формалізацією інтерфейсів такої взаємодії є технологія JMS Java Messaging Service.
Основні поняття JMS Основна ідея використання цієї технології полягає в тому, що розробники створюють лише клієнтські програми, частина з яких є відправниками, а частина - одержувачами повідомлень. Звичайно, можна і надсилати, і отримувати повідомлення в одному додатку. Сервер (його часто називають message broker) зазвичай створюється великими компаніями - IBM, Tibco, Sonic, і прикладні розробники просто використовують його подібно до веб-серверів або серверів БД. Як правило, перед початком роботи програмної системи, що використовує JMS, на стороні сервера створюються так звані об'єкти, що адмініструються. Це, по-перше, фабрики з'єднань (connection factories), а по-друге, «цільові» об'єкти двох видів — топіки (topics) та черги (queues). Основна відмінність топіків від черг полягає в тому, що топіки розмножують повідомлення для всіх, хто бажає його отримати, а черга є просто каналом передачі повідомлення єдиному споживачеві - першому, хто встиг. Відповідно черги реалізують програмну модель "відправник-одержувач" (sender-receiver), а топики - "видавець-передплатник" (publisher-subscriber). Отримувач повідомлень - при використанні як топіків, так і черг - може отримувати повідомлення з потрібного цільового об'єкта в двох режимах - синхронному та асинхронному. У разі терміни «синхронний» і «асинхронний» характеризують режим отримання повідомлення у додатку-одержувачі. У синхронному режимі програма-одержувач явно викликає для спеціального об'єкта-отримувача, зіставленого з необхідним цільовим об'єктом, спеціальний метод (receive()). Цей метод повертає повідомлення, якщо воно доступне. Якщо повідомлення немає, то виклик цього методу блокує потік виконання команд і програма чекає надходження повідомлення. В асинхронному режимі одержувач реалізує callback-метод onMessage() спеціального інтерфейсу MessageListener. Розробник створює клас, що реалізує цей інтерфейс, потім - екземпляр цього класу і зіставляє його з необхідним цільовим об'єктом. При надходженні повідомлення відбувається виклик і виконання коду методу onMessage(). Об'єкти, що адмініструються, зазвичай створюються адміністратором брокера повідомлень з використанням поставляються розробниками сервера спеціальних утиліт адміністратора. Найчастіше такі об'єкти є глобальними, тобто. доступні для різних програм, а доступ до них здійснюється за допомогою служби імен — JNDI. Важливо розуміти, що JMS забезпечує доставку повідомлень лише цільовим об'єктам, а чи не «істинним» споживачам. Завдання правильного отримання подій у програмі від топіка або з черги може бути дуже нетривіальним. Найважливішим поняттям JMS є сесія (session). Найпростіше трактувати сесію як контекст потоку, у якому виконується передача повідомлень. Фабрикою сесій є з'єднання (connection). У свою чергу, сесія відіграє роль фабрики для об'єктів — відправників повідомлень, об'єктів — одержувачів.повідомлень та самих повідомлень. Відправники, одержувачі подій і самі події є звичайними локальними об'єктами Java. Під час передачі події (повідомлення) виконується його серіалізація — знову ж таки за звичайними правилами Java. У більш складному випадку — з використанням розподілених транзакцій — сесія виступає як одержувач повідомлень і водночас як диспетчер.
JMS та Geronimo/WAS CE Використання JMS у Geronimo/WAS CE має певну специфіку (яка збережеться до появи версії WAS CE 1.2). Ця специфіка пов'язана з отриманням доступу до об'єктів JMS, що адмініструються. Суть цієї проблеми (якщо це є проблемою) полягає в наступному: стандартний підхід до застосування JMS API заснований на використанні глобальних (тобто загальнодоступних) об'єктів, що адмініструються. Передбачається, що вони створюються адміністратором системи, а програмний код просто використовує їх, причому для пошуку застосовується типовий J2EE підхід - використання служби імен JNDI. Філософія Geronimo/WAS CE побудована на відмові від глобальних контекстів служби імен з метою підвищення продуктивності системи. Це означає, що виникають певні труднощі для отримання об'єктних посилань на об'єкти, що адмініструються, поза єдиним простором XML-дескрипторів, іншими словами, поза EAR-архівами J2EE. Проблема усвідомлюється розробниками. Звичайно, радикально питання вирішується підтримкою глобального контексту JNDI та автоматичною реєстрацією об'єктних посилань на об'єкти, що адмініструються, JMS у цьому контексті при розгортанні цих об'єктів на сервері. Підтримка глобального контексту обіцяна у версії 1.2. Поки що цього немає, використовується паліативне рішення. При запуску сервера встановлюється (для версій 1.0.x сервера) конфігурація з ім'ям geronimo/activemq/1.0/car,якої створюються спеціальний екземпляр служби імен з глобальним контекстом і кілька об'єктів, що адмініструються, причому в їх число входять три фабрики з'єднань. Отримати доступ до цих об'єктів можна, наприклад, за допомогою такого коду:
Properties props = New Properties();
props.setProperty(Context.INITIAL_CONTEXT_FACTORY, “org.activemq.jndi.ActiveMQInitialContextFactory“); props.setProperty(Context.PROVIDER_URL, “tcp://localhost:61616“);
Context initContext = New InitialContext(props);
Якщо після цього для отриманого контексту викликати метод list(), наприклад:
NamingEnumeration enum = initContext.list(““); while (enum.hasMore()) Object o = enum.next(); System.out.println(o); >
то інформація, що виводиться, матиме такий вигляд:
QueueConnectionFactory: org.activemq.ActiveMQConnectionFactory dynamicTopics: org.activemq.jndi.ActiveMQInitialContextFactory$2 ConnectionFactory: org.activemq.ActiveMQConnectionFactory TopicConnectionFactor Queues: org.activemq.jndi .ActiveMQInitialContextFactory$1
Як видно, створено три фабрики з'єднань (одна — загального призначення, одна — лише для топіків та одна — лише для черг). Крім цих об'єктів, що адмініструються, створено два дочірні контексти — dynamicTopics і dynamicQueues. З точки зору прав доступу JNDI ці контексти доступні лише читання. Проте помістити в них інформацію (об'єктні посилання на черги та топіки) все-таки можна. Про використання цих фабрик з'єднань та контекстів (dynamicTopics і dynamicQueues) буде розказано нижче. Найважливіше, що треба мати на увазі при використанні JMS разом з WAS CE: для створення об'єктів, що адмініструються, потрібно створити RAR-модулі(конектори) і відповідні їм конфігурації GBeans, а доступ до ресурсів - об'єктам, що адмініструються, задається за допомогою XML-дескрипторів. Це означає, що все робиться швидко і просто лише за умови використання JMS між різними компонентами системи у складі одного EAR-архіву. В іншому випадку розробник повинен сам забезпечити доступ до об'єктів JMS. У кожному конкретному випадку це не є великою складністю.
Запуск брокера повідомлень у WAS CE WAS CE дозволяє створювати та запускати кілька різних брокерів повідомлень. Зокрема, можна використовувати WebSphere MQ або іншу комерційну реалізацію. За замовчуванням до комплекту поставки входить брокер ActiveMQ, створений у рамках OpenSource-проекту. Він знаходиться у конфігурації geronimo/activemq-broker/1.0/car, яка запускається за замовчуванням під час старту сервера. Файл конфігурації сервера .varconfigconfig.xml містить наступний опис параметрів цієї конфігурації:
Брокер повідомлень ActiveMQ підтримує різні протоколи взаємодії. Консоль адміністратора (див. малюнок) дозволяє побачити список протоколів та відповідні параметри налаштування (у колонці навігації вибрано елемент JMS Server).
Це цілком функціональний і потужний брокер повідомлень, можливостей якого цілком достатньо більшості реальних додатків.
Про те, як створювати об'єкти, що адмініструються, за допомогою консолі адміністратора, ви зможете прочитати в повній версії статті на «Світ ПК-диску».