Интеграция: Oracle Service Bus vs Oracle SOA Suite

Несмотря на то, что лицензионно Oracle Service Bus входит в состав Oracle SOA Suite, фактически это - два пакета, соответственно инсталлировать и использовать можно как каждый из них в отдельности, так и оба вместе. В данной заметке мы разберемся для каких задач, решаемых при интеграции приложений, следует использовать Oracle Service Bus, а для каких - композитные приложения, реализуемые с помощью Service-Component Architecture(SCA)-контейнера Oracle SOA Suite.

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

Интеграция на уровне данных

Интеграция на уровне данных предполагает обмен сообщениями, содержащими данные, между информационными системами с помощью промежуточного ПО, реализующего паттерн Message Broker. Реализовать данный паттерн можно как на Oracle Service Bus, так и с помощью SCA-контейнера, используя сервисный компонент Mediator.

Выбор данных технологий обусловлен следующим: брокер сообщений реализует короткоживущие процессы, основная задача которых - считать сообщение из одной очереди, выполнить его валидацию, обогащение, трансформацию и маршрутизацию в другую очередь (в англоязычной литературе часто встречается аббревиатура VETRO-pattern). При этом обогащение в данном случае как правило не предусматривает сложной оркестровки сервисов, поэтому его можно реализовать средствами Message Flow Oracle Service Bus, не прибегая к использованию BPEL-процессов.

С технической точки зрения Oracle Service Bus имеет следующие преимущества:

• Меньшая нагрузка на базу данных, возможность работать вообще без нее: OSB требует подключение к базе данных только при использовании Oracle WebService Manager'а (OWSM), который отвечает за обработку политик. Oracle SOA Suite без базы данных работать не может. Т.е. выставить, например, нулевой уровень логирования можно, но в случае возникновения проблемы понять ее причину будет очень трудно.
  
  
• Подсистема мониторинга и обеспечения Service Layer Agreement (SLA): OSB содержит очень мощные средства мониторинга, встроенные в sbconsole. Помимо этого есть механизм Message Report'ов, который можно расширять, добавляя свои средства обработки отчетов. По-умолчанию отчеты выводятся на соответствующей странице sbconsole. OSB позволяет декларативно назначать правила уведомления администраторов при нарушении SLA. Сам SLA может быть основан на времени ответа сервиса, отношении количества удачных и неудачных вызовов, числе обработанных сообщений за единицу времени и т.д.
  
  
• Кэширование: в бизнес-сервисах можно настроить кэширование результата выполнения запроса. Таким образом, после первого выполнения запроса, все последующие обращения к прокси-сервису не будут приводить к реальным вызовам провайдера сервиса. Вместо этого результат будет возвращаться из кэша. В случае работы с медленно изменяемыми данными, такими как записи в MDM-системе, механизм кэширования может существенно повысить скорость работы системы.
  
  
• Троттлинг: в бизнес-сервисах можно настроить порог одновременно поступающих сообщений, при достижении которого шина перестает вызывать провайдер сервиса, а начинает складывать сообщения в очередь. Тем самым осуществляется защита провайдера сервиса от атак вида "Отказ в обслуживании".
  
  
• Трансформация на основе XQuery и XSLT. Mediator поддерживает трансформацию только на основе XSLT.

С технической точки зрения Mediator имеет следующие преимущества:

• Валидация семантики сообщений с помощью Schematron.
  
  
• Переупорядочивание (Reordering) сообщений на основе заданных правил.
  
  
• Поддержка Domain Value Mappling (DVM) и Cross References (XRef). Поддержку данных компонентов можно обеспечить и в OSB, но она будет не полной и это потребует дополнительных усилий.

С методологической точки зрения Oracle Service Bus должна отвечать за:

• Передачу сообщений между бизнес-доменами (это могут быть как подразделения предприятия, так и несколько подразделений, объединенных по функциональному признаку). Например, за передачу сообщений между финансами и логистикой.
  
  
• Передачу сообщений между композитными приложениями. Т.е. подход SCA - OSB - SCA вполне имеет право на жизнь.

С методологической точки зрения Mediator должен отвечать за:

• Передачу сообщений между компонентами внутри композита.
  
  
• Связь композита с внешним миром. В данном случае уместно использовать возможности сервисного компонента Mediator по переупорядочиванию сообщений и семантической валидации.
  
  
• Сами композитные приложения можно использовать для интеграции внутри одного бизнес-домена.

Интеграция на уровне бизнес-процессов

Напомню, что интеграция на уровне бизнес-процессов предполагает, что на предприятии имеется набор сервисов и средство оркестровки этих сервисов. Таким средством может быть как BPM-система, так и конечные приложения: CRM, ERP, MES и т.д. Сами сервисы выставляются с помощью сервисной шины предприятия. При этом для реализации сервисов можно применить как Oracle Service Bus, так и SCA-контейнер, используя сервисный компонент BPEL.

При этом говорить о преимуществах той или иной технологии в данном случае неуместно, т.к. они предназначены для решения разных задач.

Oracle Service Bus предназначена для реализации синхронного взаимодействия между потребителем и провайдером сервиса. Данная технология не содержит средств реализации долгоживущих процессов, асинхронных сервисов и улучшенной адресации, такой как WS-Addressing. Следует заметить, что синхронные сервисы можно реализовать не только на OSB, но и с помощью сервисного компонента Mediator. Подробное сравнение OSB и Mediator'а приведено выше.

Сервисный компонент BPEL предназначен для реализации как долгоживущих, так и синхронных процессов, осуществляющих оркестровку сервисов. Долгоживущие процессы могут быть выставлены наружу в виде асинхронных сервисов. Сервисный компонент BPEL содержит средства реализации улучшенной адресации (WS-Addressing), поддерживает дегидрацию (временное сохранение состояния процесса в базе данных), а так же интеграцию с механизмом бизнес-правил (Oracle Business Rules) и пользовательскими задачами (Human Workflow).

Интеграция на уровне композитных приложений

Бизнес-логика отдельного приложения строится путем вызова сервисов, предоставляемых как данным приложением, так и другими системами. Oracle SOA Suite предназначен прежде всего для реализации данной бизнес-логики. Вызов внешних систем осуществляется из сервисного компонента BPEL. При этом для реализации VETRO-паттерна можно использовать как сервисный компонент Mediator (внутри композита), так и Oracle Service Bus (между композитами).

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

С точки зрения построения многоуровневой сервисно-ориентированной архитектуры на предприятии, Oracle Service Bus должна отвечать за уровень виртуальных сервисов.

Заключение

Выбор технологии для решения интеграционной задачи является творческой работой, выполняемой архитектором. Описанные в данной заметке критерии являются лишь основой для принятия решения, но не готовым ответом. Всегда из правил существуют исключения. Например, на одном из проектов, мы реализовывали синхронные сервисы на сервисном компоненте Mediator, а не на Oracle Service Bus просто потому-что из 150 информационных потоков синхронных было всего два. Устанавливать и самое главное - поддерживать - Oracle Service Bus только для двух потоков мне показалось непозволительной роскошью.

P.S. Это - юбилейное, 150-е сообщение в моем блоге.

Понравилось сообщение - подпишитесь на блог и Twitter