|
| |||
|
Федерация сервисных шин Oracle в системе передачи сообщений «Запомнить-и-Передать» с динамической маршрутизацией в SOA (Oracle Service Bus Federation with JMS Store-and-Forward and Dynamic Routing in SOA, by Irene Rusman) Источник: сайт OTN корпорации Oracle , серия «Архитектура SOA », июнь 2008, www.oracle.com/technology/pub/articles/rusman-alsb.html В этой статье описаны архитектура, проект и конфигурация федерации сервисных шин Oracle - Oracle 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 и поток сообщений – запросов и ответов.
Рис . 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 -система читает значение этого параметра для определения пункта назначения ответа в центральном домене, прежде чем он будет перенаправлен в периферийный домен. < reply - to - saf - remote - context - name > должен быть полностью квалифицированным именем, состоящим из имени JMS -системы и имени удаленного контекста в центральном домене. Например: <reply-to-saf-remote-context-name> SystemModuleTest3!DOMAIN31-SAF-REM-CONTEXT </reply-to-saf-remote-context-name> Вы устанавливаете < 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 . |
|
Ирен Русман 
|
|
