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

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