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

Архитектура развертывания и установка

Периферийные домены получают запросы от 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.