Архитектура, проект и конфигурация федерации сервисных шин Oracle - Oracle Service Buses

В этой статье описано, как конфигурировать домены сервисной шины 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 -инфраструктуры.

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