Федерация сервисных шин Oracle в системе передачи сообщений "Запомнить-и-Передать" с динамической маршрутизацией в SOA

В этой статье описаны архитектура, проект и конфигурация федерации сервисных шин 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 -функция сконфигурирована со значениями по умолчанию, каждое из которых может быть настроено для удовлетворения потребностей конкретного приложения

Предложены три типичные топологии для развертывания:

• Распределенные хабы ( Distributed Hubs ) - распределенные OSB -домены, ответственные за маршрутизацию между ними, причем без центрального координатора. Распределенные хабы обслуживают домены приложений соответствующих дивизионов.
• Хаб предприятия ( Enterprise Hub ) - центральный OSB -домен предприятия в качестве центрального координатора или сервисной шины предприятия для доменов дивизионов, или департаментов предприятия. Домены дивизионов, в свою очередь, обслуживают прикладные домены для соответствующих дивизионов.
• Композитная модель ( Composite Model ) - комбинация обоих этих сценариев, распределенного и централизованного. В этом случае распределенные OSB -домены по-прежнему обеспечивают маршрутизацию между собой, например, при высоком уровне взаимодействия сервисов. Центральный OSB -домен может поддерживать вновь приобретенную компанию, соединяя федерацию (распределенных OSB -доменов) c внешними приложениями этой компании.

В качестве сценария-примера представим корпорацию, развертывающую 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 - центральный домен. Серверы кластера будут называться:

• Domain osb1 - osb1Slave0, osb1Slave1
• Domain osb2 - osb2Slave0, osb2Slave1
• Domain osb3 - osb3Slave0, osb3Slave1

Используя эту архитектуру, давайте немного подробнее рассмотрим проектируемый нами сценарий:

• Первый JMS -клиент посылает запросы к JMS Proxy -сервисам по запросам-ответам сервера osb 1.
• Второй JMS -клиент посылает запросы к JMS Proxy -сервисам по запросам-ответам сервера osb 2.
• Чтобы обеспечить корректное распределение ответов, запросы содержат рубрику " reply - to ", которое читается Oracle Service Bus во время выполнения.
• Запросы направляются к локальному JMS Business Services по запросам-ответам в их собственным доменах osb 1 и osb 2.
• Запросы перенаправляются через SAF к JMS Proxy Services по запросам-ответам сервера osb 3.
• Запросы направляются к базовому сервису, сконфигурированному как JMS Business Services по запросам-ответам сервера osb 3.
• Базовое приложение устанавливает идентификатор ( ID ) корреляции с ответом в рубрику ID сообщения запроса, чтобы коррелировать сообщение-ответ через ID сообщения-запроса.
• Базовое приложение читает рубрику " reply - to " запроса для определения очереди ответов.
• Ответы размещаются в очереди ответов этого базового Business Service .
• Ответы отсылаются из очередей ответов этого базового Business Service в очереди ответов JMS Proxy Services в osb 3.
• Ответы перенаправляются через SAF в очереди ответов Business Services в osb 1 и osb 2.
• Ответы пересылаются дальше в очереди Uniform Distributed Queues ( UDQ ) Proxy -сервисов в osb 1 и osb 2.
• Если клиенты коррелируют по ID входящего и ID ответного сообщения, который соответствует ID JMS запроса-сообщения, клиенты получают ответы (каждый раз, когда JMS -сервер производит это сообщение, он назначает ему ID сообщения).

Важно помнить, что Oracle Service Bus разработана с расчетом на контракт. И пользователь должен выполнить свою часть контракта.

• Фоновое пользовательское приложение в центральном домене osb 3 должно читать рубрику " reply - to " из заголовка сообщения и послать сообщение-ответ этому пункту назначения.
• Пользователь должен установить корреляцию значением идентификатора в proxy -сервисе в центральном домене osb 3. Только тогда пункты назначения ответа будут устанавливаться динамически на основе " reply - to " и запросов перенаправленных к корректным периферийным доменам.

Эта архитектура с центральным хабом масштабируема. Периферийных доменов может быть больше, чем два. С каждым дополнительным периферийным доменом число очередей для входящих сообщений-ответов будет возрастать для обслуживания этих дополнительных доменов. Клиент волен посылать запрос через любой периферийный домен чтобы запросить сервис центрального домена. Следовательно, любой периферийный домен может быть переведен в 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 ) для запросов:

• ExpReqProxyUDQ-Domain3
• Бизнес-сервисы в периферийных доменах aslb 1 и osb 2 получат соответствующие импортированные UDQ :
• ImpReqBusUDQ-Domain1
• ImpReqBusUDQ-Domain2

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

• osb1:
  • ExpResBusQ1-Slave0
  • ExpResBusQ1-Slave1
• osb2:
  • ExpResBusQ2-Slave0
  • ExpResBusQ2-Slave1

Proxy -сервис в центральном домене osb 3 будет иметь соответствующие локальные очереди для ответов, перенаправляемых к osb 1:

• ImpResBusQ1-Domain31
• ImpResBusQ2-Domain31

Для перенаправляемых к osb 2:

• ImpResBusQ3-Domain32
• ImpResBusQ4-Domain32

Важный элемент периферийной 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 :

• URI - специфицирует место посылки сообщения
• Mode - специфицирует шаблон коммуникаций - запрос только или запрос-ответ
• Quality - of - service - специфицирует качество сервиса - наилучшее ( best - effort ) или однократное ( exactly - once )
• Retry - count - специфицирует число попыток, которые транспортный слой должен предпринять в случае ошибок
• Retry - interval - специфицирует время ожидания в миллисекундах между попытками

Замечание: При выполнении действия Routing Options , значение контекста уходящего сообщения выбирается из Message Context . Если эта значение еще не определено, будет сгенерирована ошибка. Иначе, это действие перейдет к установке этих элементов в уходящем сообщении как специфицировано в конфигурации действия.

Заключение

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

Подробности такого конфигурирования вооружат продвинутых пользователей уверенностью в реальности сети сервисных шин. Гаданиям нет места, нужно шире использовать лучшие практики.

Ирен Русман ( Irene Rusman ) - старший софтверный инженер корпорации Oracle . Она работает над системной интеграцией на основе Oracle Service Bus