Координация родительских и дочерних BPEL-процессов. Сигналы

Продолжаем серию уроков по BPEL. Сегодня мы рассмотрим специфическое для Oracle SOA Suite средство организации взаимодействия между экземплярами BPEL-процессов - сигналы.

Постановка задачи координации родительских и дочерних процессов

При моделировании бизнес-процессов иногда требуется вынести некоторую логику в отдельные подпроцессы. Данная необходимость может объясняться желанием повторно использовать данную логику или распараллелить выполнение подпроцессов с целью увеличения производительности. Основной процесс в терминологии Oracle называется "мастером" или "родительским", а подпроцесс - "детальным" или "дочерним" процессом.

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

1. Родительскому процессу интересен только факт запуска экземпляров дочерних процессов. Данный паттерн так же называется "Вызови и забудь" (fire and forget). Родительский процесс создает один или несколько экземпляров дочернего процесса, при этом его не интересует их последующее исполнение.
2. Родительскому процессу интересна информация, возвращаемая дочерними. В таком случае родительскому процессу необходимо ожидать ответ от каждого из них. В случае синхронного взаимодействия ответ и так подразумевается, а в случае асинхронного - родительский процесс продолжает работу после получения ответа от дочернего, а для связывания запроса и ответа используется механизм корреляции или WS-Addressing.
3. Родительскому процессу интересен факт завершения выполнения некоторых действий дочерним процессом, но не результаты этого выполнения. Т.е. родительский процесс нуждается не в сообщении от дочернего, а в некотором сигнале.

Действия Signal и Receive Signal - Oracle'овое расширение языка BPEL - позволяют реализовать третий паттерн взаимодействия процессов.

Длительно выполняющиеся транзакции в BPEL. Механизм компенсаций

Язык Business Process Modeling and Execution Language (BPEL, читается «БИПЛЬ») предназначен для моделирования бизнес-процессов предприятия посредством оркестровки сервисов. При этом, как исполнение самих операции сервисов, так и принятие решения о том, какой именно сервис вызвать, могут занимать довольно длительное время: часы, дни, недели. Особо характерна большая длительность операций в том случае, если они выполняются пользователями.

Ситуация осложняется тем, что зачастую длительно выполняющиеся операции не являются независимыми друг от друга, а представляют собой бизнес-транзакцию. Т.е. в случае возникновения ошибки при выполнении операции необходимо откатить результаты успешно выполненных ранее операций. При этом, из-за высокой длительности операций системные транзакции использовать нельзя. К счастью, язык BPEL предлагает решение проблемы организации бизнес-транзакций - механизм компенсаций.

Уровни сложности сервисов

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

Мониторинг производительности Oracle SOA Suite

Основным инструментом для мониторинга производительности Oracle SOA Suite является Oracle Enterprise Manager Fusion Middleware Control Console (в дальнейшем - EM). Предлагаю рассмотреть основные возможности данного инструмента.

Обеспечение гарантированного порядка обработки сообщений в кластерном окружении с помощью JCA-адаптеров Oracle SOA Suite

В данной заметке описано как настроить JCA-адаптеры Oracle SOA Suite для обеспечения гарантированного порядка обработки сообщений в кластерном окружении.

При интеграции информационных систем, особенно унаследованных, часто приходится обеспечивать взаимодействие с ними через базу данных. В состав Oracle SOA Suite входят адаптеры, реализованные с помощью технологии JCA, позволяющие считывать события из базы данных. Примерами таких адаптеров являются DB- и AQ-адаптеры.

При этом считывать и обрабатывать события иногда важно в том же порядке, в котором они были сгенерированы в системе и, соответственно, записаны в базу данных. Рассмотрим пример: в информационной системе создается объект, например некое начисление на абонента. Затем данный объект модифицируется, а после этого удаляется (начисление было сделано по ошибке). Очевидно, что сообщение об удалении объекта ни в коем случае не должно быть передано в систему-приемник раньше, чем сообщение о его создании, т.к. в данном случае будет нарушена целостность данных.

Асинхронные веб-сервисы

В данной статье описаны подходы к реализации асинхронного взаимодействия между информационными системами с помощью веб-сервисов. Подробно рассмотрен применяющийся в Oracle SOA Suite подход, основанный на использовании сервиса обратного вызова и стандарта WS-Addressing. Приведены примеры создания асинхронного веб-сервиса с помощью Oracle SOA Suite и генерации клиента к такому сервису с помощью интегрированной среды разработки Oracle JDeveloper.

Введение

Зачастую при интеграции информационных систем необходимо обеспечить асинхронное взаимодействие между ними. При данном типе взаимодействия потребитель сервиса не ждет окончания обработки запроса поставщиком сервиса, а сразу после получения уведомления о принятии данного запроса к обработке продолжает свою работу. Существует два подхода к обеспечению асинхронного взаимодействия с помощью механизма веб-сервисов:

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

В Oracle SOA Suite применяется второй подход: потребитель сервиса является одновременно поставщиком сервиса обратного вызова. В свою очередь поставщик сервиса после получения запроса от потребителя возвращает ему HTTP-ответ 202 Accepted, что обозначает успешное принятие запроса на обработку. В Oracle SOA Suite при этом создается новый экземпляр композита. После завершения обработки запроса, которая может занимать достаточно много времени, например недели, что особенно характерно, если в обработке запроса участвуют люди, поставщик сервиса осуществляет вызов сервиса обратного вызова, предоставляемого потребителем.

Три подхода к интеграции информационных систем

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

Итак:

1. Интеграция на уровне данных. Суть данного подхода заключается в следующем: приложения работают независимо друг от друга, каждое использует свой набор данных. В случае необходимости осуществляется обмен данными между приложениями. При этом, если обмен данными осуществляется путем вызова сервисов или отправки/получения сообщений, то в качестве среды для обмена можно использовать сервисную шину предприятия - Enterprise Service Bus (ESB). Если же обмен данными производится в основном между базами данных, используемыми тем или иным приложением, то можно использовать решение класса Extract, Transform, Load (ETL). При этом некоторые реализации ETL, например Oracle Data Integration (ODI), могут использовать в качестве источников и приемников данных веб-сервисы и системы класса Message-oriented Middleware (MOM).


2. Интеграция на уровне бизнес-процессов. Суть данного подхода заключается в следующем: приложения выставляют сервисы, являющиеся интерфейсами к бизнес-логике данных приложений. Взаимодействие между приложениями реализовано в рамках бизнес-процесса, на отдельных шагах которого осуществляется вызов того или иного сервиса. Реализуется данный подход с помощью сервисной шины предприятия (ESB), которая занимается виртуализацией сервисов, предоставляемых приложениями, и решений класса Business Process Management System (BPMS), как правило основанных на языках BPEL или BPMN, которые реализуют логику процесса.


3. Интеграция на уровне композитных приложений. Бизнес-логика отдельного приложения строится путем вызова сервисов, предоставляемых как данным приложением, так и другими системами. Таким образом на одном шаге бизнес-процесса могут взаимодействовать несколько сервисов, в то время как при интеграции на уровне бизнес-процессов на одном шаге процесса вызывается один сервис. Реализация композитных приложений осуществляется с помощью использования технологий Java Business Integration (JBI, JSR 208) или Service Component Architecture (SCA). В качестве SCA-контейнеров можно использовать Oracle WebLogic, Oracle SOA Suite или Apache Tuscany.
   

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

P.S. Вне рассмотрения осталась интеграция на уровне пользовательских интерфейсов. Например параметризованный вызов приложений: средство отобразить в интерфейсе одного приложения элементы интерфейса другого приложения. Данный способ серьезно отличается тем, что результат интеграции предназначен не для приложений, а исключительно для пользователя.

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