У багатьох організаціях в існуючих програмах IBM Lotus Domino є великий обсяг інформації і даних, необхідних іншим додаткам. У статті показується, як в IBM Lotus Domino Designer розробити Java-агент, підготовлений до запуску на сервері Lotus Domino. У цьому агента для відправки повідомлень JMS-провайдера і отримання від нього відповідних повідомлень використовується API Java Messaging Systems (JMS) 1.1, а також API Java Naming and Directory Interface (JNDI). Як провайдера повідомлень в статті застосовується IBM WebSphere MQ V6, однак за рахунок використання JMS 1.1 наш код дозволяє додаткам Lotus Domino підключатися до будь-якої корпоративної сервісної шини (enterprise service bus - ESB), що підтримує JMS. (Код тестувався на Lotus Domino V8, WebSphere MQ V6 і JMS 1.1 API, проте він також повинен працювати з Lotus Domino V5 і JMS 1.0 і пізніших версіях).
Пропонована архітектура
Перш ніж докладно розглянути наше рішення, ознайомимося з ним в загальних рисах. На малюнку 1 представлена діаграма розгортання на мові Unified Modeling Language (UML), з якої стає зрозуміло, як працює приклад програми. Як видно, для роботи програми потрібні два окремих фізичних сервера: сервер Lotus Domino V8 і сервер WebSphere MQ V6. Звичайно ж, можна запустити додаток, розмістивши його на одному сервері, однак більш правдоподібним і наочним сценарієм є застосування розподіленої мережевої конфігурації. Крім того, з малюнка 1 видно, що сервер WebSphere MQ надає підтримку як JNDI-провайдера, так і JMS-провайдера без необхідності використовувати додаткове ПО.
Малюнок 1. Діаграма розгортання архітектури
Чому використовується саме така архітектура?
Очевидно, що існує безліч способів отримання даних з Lotus Domino і передачі їх іншим додаткам, так навіщо використовувати обмін повідомленнями, а точніше кажучи, JMS? Обмін повідомленнями здійснюється по асинхронному каналу зв'язку, що дозволяє Lotus Domino і будь-якого JMS-провайдера обмінюватися даними в режимі слабкого зв'язку (тобто, виробник і споживач даних можуть не знати один про одного). Крім того, при використанні JMS API наш Java-код дозволить Lotus Domino взаємодіяти з будь-яким JMS-провайдером, а також підключатися до безлічі корпоративних сервісних шин.
огляд статті
Кроки, наведені в нашій статті, відповідають послідовності операцій при створенні прикладу програми. Ось ці операції:
Налаштування WebSphere MQ
WebSphere MQ V6 підтримує JMS 1.1. Це означає, що WebSphere MQ V6 може працювати в якості провайдера JMS 1.1. Пам'ятайте, що JMS - це всього лише специфікація API; система обміну повідомленнями працює за рахунок конкретної реалізації цієї специфікації JMS.
Щоб JMS-клієнти могли підключатися до WebSphere MQ, необхідно створити і налаштувати менеджер черг. Менеджер черг задає процеси середовища виконання, що забезпечують можливості JMS в JMS-клієнтів. У WebSphere MQ є оснований на Eclipse адміністративний клієнт, який може допомогти в цьому процесі.
- Запустіть WebSphere MQ Explorer, вибравши Start - All Programs - IBM Websphere MQ - Websphere MQ Explorer.
- Виберіть папку Queue Manager в навігаторі WebSphere MQ Explorer, а потім клацніть правою кнопкою миші і виберіть New - Queue Manager.
- У який з'явився майстра введіть в якості імені менеджера черг Domino.QMGR. Відзначте галочкою опцію "Make this the default queue manager". Введіть SYSTEM.DEAD.LETTER.QUEUE в поле Dead letter queue. В інших полях залиште пропоновані за замовчуванням, а потім натисніть Finish, як показано на малюнку 2.
Малюнок 2. Налаштування менеджера черг
На даний момент ми створили менеджер черг, здатний зберігати повідомлення в Websphere MQ, але JMS-клієнтам також необхідний JNDI-провайдер.
Налаштування JNDI
JNDI - це всього лише специфікація, тому для її реалізації потрібно провайдер. Цю реалізацію може забезпечити IBM WebSphere MQ V6 з допомогою supportPac ME01, якому в свою чергу потрібно supportPac MS0B (див. Розділ "Ресурси"). Ці пакети supportPac легко встановити: розпакуйте їх і скопіюйте JAR-файли в каталог
При використанні WebSphere MQ в якості JNDI-провайдера відпадає необхідність в окремому JNDI-провайдера, перетворюючої адмініструються об'єкти JMS в фізичні черзі Websphere MQ - цю можливість забезпечує supportPac ME01.
Малюнок 3. Пакети JNDI supportPac
set CLASSPATH =% CLASSPATH%; C: \ Program Files \ IBM \ Websphere MQ \ Java \ lib \ mqcontext.jar;
C: \ Program Files \ IBM \ Websphere MQ \ Java \ lib \ com.ibm.mq.pcf.jar
Малюнок 4. Оновлення CLASSPATH в JMSAdmin.bat
Після додавання в файл запуску JMSAdmin інформації про пакети supportPac можна виконувати підключення до JNDI-провайдеру для створення адмініструються об'єктів JMS. Це досягається установкою властивостей з'єднання для інструменту JMSAdmin в його файлі конфігурації (JMSAdmin.config).
# Параметри конфігурації JNDI для використання WebSphere MQ в якості JNDI-провайдера
INITIAL_CONTEXT_FACTORY = com.ibm.mq.jms.context.WMQInitialContextFactory
PROVIDER_URL = localhost: 1 414 / SYSTEM.DEF.SVRCONN
Оскільки інструмент JMSAdmin запускається з сервера WebSphere MQ, параметр PROVIDER_URL повинен мати значення localhost. Як показано на малюнку 1, Java-агент Lotus Domino віддалено підключається до JNDI-провайдеру і таким чином використовує ім'я DNS віддаленого сервера, а не локального хоста.
Тепер можна запустити інструмент JMSAdmin з командного рядка:
C: \ Program Files \ IBM \ Websphere MQ \ Java \ bin \ JMSAdmin.bat
Створення адмініструються об'єктів JMS
def cf (JMS_ConnectionFactory) qmgr (Domino.QMGR) tran (client) chan (SYSTEM.DEF.SVRCONN)
host (bpte-demo-8.austin.ibm.com) port (1414)
Таблиця 1. Послідовність команд
Ці JAR-файли були скопійовані з каталогу установки WebSphere MQ в каталог C: \ Program Files \ IBM \ Websphere MQ \ Java \ lib.
Погляньмо тепер на код і розберемося, за що відповідає кожна частина. У лістингу 1 показаний загальний код, однаковий як для провайдера, так і для споживача повідомлень. Зверніть увагу, що нумерація рядків в коді - наскрізна, і код лістингів 2 і 3 слід за загальним кодом з лістингу 1.
Лістинг 1. Загальний код
У лістингу 2 показаний код виробника JMS, що створює JMS-повідомлення та його відправку віддаленого JMS-провайдеру. Так як цей агент застосовується до документів, обраним в поданні, в рядку 16 ми отримуємо колекцію цих документів. Потім ми виконуємо цикл, конвертуючи кожен документ Lotus Domino з цієї колекції в XML-документ, який можна записати в JMS як простий текст (рядок 19).
Лістинг 2. Виробник повідомлень
Після запуску агента можна переконатися, що повідомлення дійшли до WebSphere MQ, за допомогою WebSphere MQ Explorer. У WebSphere MQ Explorer виберіть папку Queues, щоб побачити всі черги цього менеджера черг, а потім правою кнопкою миші натисніть на JMS_Queue і виберіть Browse Messages, щоб побачити повідомлення в черзі.
В результаті буде виведено повідомлення за кожним документом, обраному під час запуску агента JMS_PUT (див. Малюнок 10).
Малюнок 10. Повідомлення в черзі
Якщо двічі клацнути по одному з повідомлень, виводиться діалогове вікно Properties, в якому показано повідомлення в тому вигляді, в якому воно відображається в WebSphere MQ (див. Малюнок 11).
Малюнок 11. Повідомлення в WebSphere MQ
На даний момент ми успішно зберегли цілий документ Lotus Domino як XML в черзі WebSphere MQ. І в нашому коді відсутні характерні для WebSphere MQ класи, є тільки JMS-код, який так само легко відправляє це повідомлення у WebSphere Enterprise Service Bus.
Щоб продемонструвати, що можна також отримувати повідомлення від WebSphere MQ через JMS, ми створили ще один агент для споживання повідомлень. Як і код виробника, цей код не знає, який використовується JMS-провайдер - він просто вміє "розмовляти" на JMS. Код споживача показаний в лістингу 3.
Лістинг 3. Споживач повідомлень
Важлива відмінність коду споживача полягає в тому, що споживач повинен чекати і слухати повідомлення, як показано в рядку 16. При отриманні повідомлення ми створюємо новий документ Lotus Domino для збереження JMS-повідомлення в базі даних Lotus Domino (рядки 19-23). З метою налагодження ми виводимо інформацію про повідомленні на консоль Java, яку можна викликати, вибравши Tools - Show Java Debug Console в Lotus Domino Designer, як показано на малюнку 12.
Малюнок 12. Інформація про повідомленні в консолі Java
Крім того, якщо відкрити уявлення JMS_Imported, можна побачити документи, створені в ході виконання коду споживача JMS. Відкривши документ, ви побачите доставлений XML-текст (див. Малюнок 13).
Малюнок 13. Повідомлення, збережені у вигляді документів Domino
висновок
У нашій статті ми показали, як відправляти повідомлення з Lotus Domino JMS-провайдера, а також отримувати повідомлення. В результаті ми отримав простий і економічний спосіб спільного застосування Lotus Domino і корпоративної сервісної шини. Як провайдера повідомлень ми використовували WebSphere MQ, проте наш код працює з будь-яким JMS-провайдером.
Подяки
Висловлюємо особливу подяку Бобу Балабана і Боббі Вулфу за рецензування даної статті.