Федерація сервісних шин Oracle в системі передачі повідомлень “Запам’ятати-і-Передати” з динамічною маршрутизацією в SOA, Інші СУБД, Бази даних, статті

У цій статті описані архітектура, проект і конфігурація федерації сервісних шин OracleOracle Service Buses (OSB, раніше AquaLogic Service Buses). Ця федерація формується кластером доменів (clustered domains) цих шин, пов’язаних системою передачі повідомлень на базі підходу ” Запам’ятати-і-Передати ” ( messaging Store – and – Forward ( SAF ) System). Зокрема, в цій статті розглядається архітектура, в рамках якої два периферійних кластера доменів ініціюють зв’язок типу запит-відповідь (request – response) з третім, центральним доменом. Периферійні домени використовують SAF для передачі запитів. Центральний домен використовує SAF для передачі відповідей периферійним доменам.


У цій статті описано, як конфігурувати домени сервісної шини Oracle Service Bus, а також уявлення про деякі периферійних, але важливих проблемах, таких як динамічна маршрутизація (dynamic routing) і кореляція відповіді (response correlation) в рамках федеративної архітектури.


Основи


Oracle Service Bus JMS – Це система передачі повідомлень рівня підприємства, заснована на Java Message Service (JMS) специфікації JMS 1.1, яка надає численні розширення до стандартних API-інтерфейсів JMS. Ця система тісно інтегрована з платформою Oracle WebLogic Server , Що дозволяє створювати безпечні програми для середовища Java EE, які можна моніторити і адмініструвати через консоль Oracle Service Bus.


Крім повної підтримки розширеної архітектури (extended architecture – XA) транзакцій Oracle Service Bus JMS забезпечує високу готовність, завдяки функції підтримки кластерів та міграції серверів. Функція SAF ( Запам’ятати-і-Передати ) Забезпечує зберігання повідомлень, які не можуть бути доставлені до тих пунктів призначення, які, можливо, розташовані на віддалених хостах, поки вони не стануть доступні. Ця SAF-функція сконфигурирована зі значеннями за замовчуванням, кожне з яких може бути налаштоване для задоволення потреб конкретного додатка


Запропоновано три типові топології для розгортання:



В якості сценарію-прикладу уявімо корпорацію, розгортають Oracle Service Bus Enterprise Hub: два периферійних домену, з’єднаних з центральним. Це сценарій описаний в секції “Deployment Topology “(Розгортання топології) за адресою architecture overview (Огляд архітектури).


Далі я опишу архітектуру розгортання хаба підприємства, яка забезпечує передачу повідомлень між його доменами (cross – domain messaging).


Архітектура розгортання і установка


Периферійні домени отримують запити від JMS-клієнтів, обробляють їх з використанням proxy-сервісів і маршрутизируют, направляють ці запити до локальних бізнес-сервісів. Ці бізнес-сервіси – просто оболонки. Вони призначені для зберігання відправлених запитів-повідомлень і передачі їх віддаленого центральному хабу.


Цей центральний хаб обробляє ці (для нього) вхідні повідомлення, використовуючи свій proxy-сервіс і направляє їх до локального фонового (backend) бізнес-сервісу. Коли бізнес-сервіс посилає повідомлення-відповідь, воно спочатку прибуває до цього локального proxy-сервісу. Цей proxy-сервіс запам’ятовує йде повідомлення-відповідь і передає віддаленим периферійним доменам, які повинні передати його до клієнтів JMS.


Як мінімум, ви повинні сконфігурувати в кластер (федерацію) три домену. У цю федерацію повинні увійти два периферійних домена (Domain 1 і Domain 2 на рис. 1 нижче), через які клієнти посилають початкові (Initial) запити центральному домену. Центральний домен (Domain 3) отримує ці запити і шле відповіді назад клієнтам через два периферійних домену. Центральний домен є хостом для центрального proxy і базових бізнес-сервісів.


На рис. 1 представлений приклад архітектури хаба підприємства. Він показує три кластерірованних домену з proxy – і бізнес-сервісами, сконфігурованими на кожному з них, пункти призначення JMS і потік повідомлень – Запитів і відповідей.


enterprise hub architecture


Рис. 1. Конфігурація від OSB до OSB через SAF з двома периферійними доменами з Proxy-сервісами, посилають запити до центрального домену з базовим бізнес-сервісом.


Для простоти припустимо, що кожен домен складається з адміністративного сервера і кластера з двох керованих серверів. Для опису цієї установки введемо імена: osb 1 і osb 2 – два периферійних домену, osb 3 – центральний домен. Сервери кластера будуть називатися:



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



Важливо пам’ятати, що Oracle Service Bus розроблена з розрахунком на контракт. І користувач повинен виконати свою частину контракту.



Ця архітектура з центральним хабом масштабируема. Периферійних доменів може бути більше, ніж два. З кожним додатковим периферійним доменом число черг для вхідних повідомлень-відповідей буде зростати для обслуговування цих додаткових доменів. Клієнт вільний посилати запит через будь периферійний домен щоб запросити сервіс центрального домену. Отже, будь-який периферійний домен може бути переведений в offline, не впливаючи на здатність клієнта звернутися до сервісу в центральному домені. Наявність фонового програми в центральному домені підводить до повторного використання централізованого сервісу. У клієнтів є перевага використання периферійних доменів для локальних сервісів і центрального домену для централізованих. Тим самим організація доменів OSB в Enterprise Hub сприяє оптимізації використання сервісів.


Далі в цій статті описується, як конфігурувати такий Enterprise Hub.


Конфігурування Configuration


В наступних секціях ви дізнаєтеся, як конфігурувати домени, складові Enterprise Hub.


Конфігурування SAF


Почніть з главою “Configure JMS SAF” в документації (documentation) по WebLogic Server. Там є докладні інструкції з адміністрування і конфігурації SAF.


Примітка автора: Ця стаття призначена для просунутих користувачів, у яких вже є досвід з роботи з SAF. Я тільки викладу специфіку конфігурації SAF для Enterprise Hub.


У кожного домена є SAF-агент, розгорнутий на кластері. Proxy-сервіс в центральному домені osb 3 працює з експортованої фізичної чергою класу UDO (uniform distributed queue) для запитів:



Ви повинні специфікувати локальні черзі для відповідей (або UDQ на кожен керований сервер, якщо потрібно) для бізнес-сервісу при використанні шаблону ID кореляції JMS-повідомлення, як пояснюється в документації Understanding Message ID and Correlation ID Patterns for JMS Request / Response. Отже, proxy-сервіс в доменах osb 1 і osb 2 буде мати локальні експортовані черзі для відповідей.



Proxy-сервіс в центральному домені osb 3 буде мати відповідні локальні черзі для відповідей, перенаправляється до osb 1:



Для перенаправляється до osb 2:



Важливий елемент периферійної SAF-конфігурації osb 1 і osb 2 – це параметр < reply – to – saf – remote – context – name >. SAF-система читає значення цього параметра для визначення пункту призначення відповіді в центральному домені, перш ніж він буде перенаправлений в периферійний домен. повинен бути повністю кваліфікованим ім’ям, що складається з імені JMS-системи та імені віддаленого контексту в центральному домені. Наприклад:


<reply-to-saf-remote-context-name>


SystemModuleTest3!DOMAIN31-SAF-REM-CONTEXT


</reply-to-saf-remote-context-name>


Ви встановлюєте серед інших імпортованих параметрів пункту призначення, використовуючи адміністративну консоль WebLogic, як описано в розділі “Configure JMS SAF “документації з WebLogic Server.


Конфігурація каналу зв’язку в Oracle Service Bus


Деталі конфігурації каналу зв’язку для SOAP – повідомлень поверх JMS


Код “движка” WebLogic JAX – RPC Web services включає наступний алгоритм для кореляції повідомлень-відповідей: якщо ID кореляції JMS заданий у повідомленні-запиті, движок JAX – RPC Web services встановить той же самий ID кореляції JMS в повідомлення-відповідь, а якщо цей ідентифікатор не заданий в запиті, то ID кореляції відповіді встановиться в (поле) ідентифікатора повідомлення-запиту.


Для федеративної архітектури потрібно встановлювати кореляції за допомогою ID-повідомлень. Отже, ми повинні гарантувати, що фонове додаток отримує повідомлення-запит без кореляційного JMS-набору ID-ідентифікаторів. Оскільки обидва транспорту, вхідний та минає, – це JMS, має забезпечити код движка WebLogic JAX – RPC Web services з необхідними заголовками, явно проходячи крізь транспортні заголовки минає повідомлення-запиту з використанням дії Transport Headers в Route-сайті.


Для виключення ID з кореляційного JMS-набору переданих заголовків, слід видалити ID з використанням іншої дії Transport Headers. Це гарантує, що фоновий (backend) код движка JAX-RPC сервісів буде корелювати (співвідносити) відповіді по ID JMS повідомлення.


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


Якщо для використовуваної статичної конфігурації кінцевих точок proxy – і бізнес-сервісів не достатньо, то можна маршрутизувати повідомлення, використовуючи заголовок, прочитані під час виконання. Щоб здійснити це, потрібно настроїти дію Dynamic Routing (або Dynamic Publishing, якщо відповідь не очікується).


Коли конфігурується Dynamic Routing, ви повинні специфікувати сервіс. Якщо це простий (plain) JMS-сервіс, ви спеціфіціруете повну дорогу до нього. Якщо ж сервіс заснований на WSDL, ви обираєте його з WSDL. Специфікування операції опционально. Dynamic Routing і Dynamic Publishing дозволяють динамічно вибирати сервіси на основі змісту повідомлення або заголовків, причому можливо перетворення повідомлень за допомогою цільового сервісу.


Нижче наведені приклади, що показують, як надати ім’я сервісу безпосередньо або використовуючи XQuery:


<ctx:route>
<ctx:service isProxy=”false”>soapjms/JMSTransportService-BS</ctx:service>
<ctx:operation>{$operation}</ctx:operation>
</ctx:route>
<ctx:route>
<ctx:service isProxy=”false”>{$header/service[0]/text() }</ctx:service>
<ctx:operation>{$operation}</ctx:operation>
</ctx:route>

Ви можете також створити Query for Dynamic Routing, як ресурс, і специфікувати ім’я цього ресурсу в конфігурації. Така маршрутна команда буде відповідати сервісу та операції, якщо це забезпечено у визначенні бізнес-сервісу, і викличе цей сервіс (операцію).


Dynamic Routing-потужна функція. Застосування Dynamic Routing в розподіленому середовищі федеративних OSB-доменів забезпечує відсилання повідомлень до будь-якого віддаленого домену. Dynamic Routing – це обчислення пункту призначення, що виконується в Route-сайті під час виконання. Результат такого обчислення пригнічує попередньо визначений цільової сервіс і, можливо, операцію, якщо це задано.


Кращий спосіб організувати Dynamic Routing – це створити таблицю роутінга (Routing Table). Ця Routing Table являє собою просто XML-файл, зареєстрований як XQuery ресурс, наприклад:


<routing>
<row>
<logical>osb1</logical>
<physical>soapjms/JMSTransportService-BS1</physical>
</row>
<row>
<logical>osb2</logical>
<physical>soapjms/JMSTransportService-BS2</physical>
</row>
</routing>

Тоді можна використовувати дію Assign класу обробки повідомлень, щоб дійти до фізичного пункту призначення, проходячи через логічний:


<ctx: route>
<ctx: service>
{$routingtable/row[logical/text()=$logicalidentifier]/physical/text()}
</ctx: service>
</ctx: route>

$ Logicalidentifier буде дійсним XPath для вилучення логічного ідентифікатора з повідомлення. Якщо повідомлення містить цей логічний ідентифікатор в своєму тілі, вираз XPath почнеться з $ body .


Конфігурування OSB для Dynamic Routing описано в секції “Using Dynamic Routing” документа Modeling Message Flow в OSB.


Установка атрибутів маршрутизації з опціями маршрутизації


Дія Routing Options призначено для установки різних властивостей у змінній Message Context минає повідомлення. Ці властивості включають Quality – of – Service, URI і Mode, які впливають на дії по публікації і маршрутизації (Publish and Route). Хоча ці елементи можуть бути встановлені з застосуванням Assign, Insert, Replace і Delete, їх використання вимагає деякого знання XPath та / або XQuery, також як і знання XML-структури контекстного значення минає повідомлення.


Мета дії Routing Options – полегшити для користувача установку цих властивостей. Крім того, продуктивність – це додаткова мета, тому що основне уявлення змінних контексту входять і йдуть (повідомлень), починаючи з AquaLogic Service Bus 2.5 – це POJO (Plain Old Java Object). Ця дія дозволяє пряму маніпуляцію POJO, замість обробки у форматі XML, що вимагає більше дій перетворень.


Набір властивостей, з якими можна маніпулювати за дією Routing Options:



Зауваження: При виконанні дії Routing Options, значення контексту минає повідомлення вибирається з Message Context. Якщо ця значення ще не визначено, буде згенеровано помилка. Інакше, це дія перейде до установки цих елементів в минає повідомленні як специфікована в конфігурації дії.


Висновок


Мета цієї статті у тому, щоб показати, що Oracle Service Bus розроблена з можливістю формування федерацій. Ми хочемо звернути увагу IT-департаментів на переваги розгортання з самого початку мережі сервісних шин. Такий підхід виявиться правильним в стратегічному відношенні в передбаченні майбутнього зростання IT-інфраструктури.


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


Ірен Русман (Irene Rusman) – старший софтверний інженер корпорації Oracle. Вона працює над системною інтеграцією на основі Oracle Service Bus.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*