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

В данной статье описаны подходы к реализации асинхронного взаимодействия между информационными системами с помощью веб-сервисов. Подробно рассмотрен применяющийся в 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

Выпущен Oracle Fusion Middleware 11.1.1.6

Корпорация Oracle выпустила очередную версию платформы Oracle Fusion Middleware - 11.1.1.6 (коммерческий номер - 11gR1 PS5). Забавно то, что ссылки на скачивание в OTN пока размещены не на всех страницах компонентов платформы. Т.е. скачать Oracle SOA Suite 11.1.1.6 со страницы SOA Suite нельзя, а со страницы BPM Suite - можно. К сожалению, Oracle Service Bus пока недоступна на OTN, но доступна на Edelivery.

Будьте внимательны!

UPD 26.02.2011:

• Oracle Service Bus 11.1.1.6 ChangeLog


• Known Issues for Oracle SOA Products and Oracle AIA Foundation Pack for 11g Release 1 (11.1.1.6.x)

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

Разработка системы мониторинга на базе Oracle BAM

В заметке введение в Oracle Business Activity Monitoring (BAM) Суровый обещал привести пример использования данного инструмента. Пришло время исполнить данное обещание.

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

Два подхода к построению интеграционной шины предприятия

На мой взгляд можно выделить два подхода к построению интеграционной шины предприятия:

• "от интегрируемых систем";


• "от реализуемых процессов".

Давайте рассмотрим данные подходы подробнее.

Введение в Oracle Business Activity Monitoring (BAM)

Одной из важнейших задач при внедрении на предприятии сервисно-ориентированной архитектуры (SOA), архитектуры, управляемой событиями, (EDA) и сквозных бизнес-процессов (BPM) является задача мониторинга - наблюдение в реальном времени за изменением ключевых показателей (KPI), обеспечением SLA и принятие мер в случае их нарушения. В линейке продуктов Oracle Fusion Middleware присутствует компонент, предназначенный для решения данной задачи, - Oracle Business Activity Monitoring (BAM).

О построении сервисно-ориентированной архитектуры на предприятии

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

Для решения данной задачи нужно обеспечить исполнение следующих условий:

1. Переход от интеграции по принципу точка-точка к интеграции через сервисную шину предприятия (ESB).

2. Обеспечение независимости интеграции от форматов передаваемых сообщений.

3. Документирование в достаточном объеме и качестве.

4. Наличие мониторинга процесса передачи и обработки сообщений.