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