Работа в Oracle ESB

Немного истории

           В Oracle ESB имеются ключевые возможности, которые делают эту архитектуру подходящей для подобной задачи. Во-первых, в ней можно получать сообщения (уведомления о событиях) различными способами: через JMS, через вызовы Web-сервисов, из файловой системы или из таблицы базы данных, и так далее. Она может также извлекать сообщение, содержащее связанные с событием данные, и преобразовать его, обычно превращая его в более общую, каноническую модель для предприятия.

          ESB может также превратить крупномасштабное сообщение о событии в несколько более детализированных сообщений. Например, она может создать событие New Customer (новый заказчик) или событие New Order (новый заказ) из сообщения, полученного из основанной на Web-технологиях системы обработки заказов потребителей, когда новый заказчик регистрируется и размещает свой первый заказ. В процессе преобразования первоначального сообщения в одно или несколько канонических (возможно, более специализированных) сообщений, ESB может также обогатить содержимое сообщения, например, добавляя к нему информацию о текущей дате и отметке времени, или добавляя информацию, полученную из эталонных источников справочной информации, которая, вероятно, будет востребована многими потребителями события.

         И, наконец, на основании характеристик события (содержимое сообщения), ESB может предоставить преобразованные обогащенные сообщения различным каналам вывода, типа Web-сервисов, JMS, процедур или таблиц базы данных, файлов и электронной почты.

(Примечание: превосходным  примером генератора отчетов  о событии является процесс  BPEL. Когда процесс BPEL выполняется, может иметься несколько стадий и ситуаций, на которых события могут быть опубликованы, обычно, в форме вызова в ESB Web-сервиса.)

         Есть несколько подходов, призванных помочь заинтересованным в событиях сторонам потреблять сообщения от ESB:

• ESB может поставлять все сообщения в темы JMS, и каждая заинтересованная сторона будет должна разбираться для себя, как добираться до сообщений и как преобразовать их в соответствующие собственным требованиям форматы.
• Каждая система, желающая узнать о сообщении, может быть вызвана непосредственно из ESB, из того же самого сервиса, который получил событие от его создателя и, возможно, преобразовал сообщение о нем в канонический формат. Это, конечно, означает, что сервис ESB должен быть расширен при каждом очередном добавлении заинтересованной стороны и, возможно, для каждой дополнительной стороны он должен содержать дополнительные преобразования и правила фильтрования.
• Для получения события, его преобразования и обогащения, а также для публикации этого события в JMS, в ESB имеется единый сервис, а также по одному выделенному сервису для каждой заинтересованной стороны. Этот выделенный сервис получит сообщение о событии непосредственно из сервиса получения (соединенное) или прочтет сообщение (несвязанное) из JMS; выполнит дополнительное, специализированное преобразование для стороны, которую он обслуживает; и доставит это сообщение любыми средствами - используя JMS, вызов WebService, манипулирование базами данных - которые подходят получателю сообщения. В этом сценарии, при добавлении новой стороны, заинтересованной в событии (сообщении), в ESB создается новый, независимый и слабосвязанный сервис. Однако, это приводит к появлению некоторых накладных расходов - более конкретно, много дополнительных определений сервисов, а также экземпляров сервисов - и они будут копировать через внешнюю тему JMS то, что ESB в большей или меньшей степени делает внутренним образом.

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

Разработка сервиса ESB с помощью Oracle ESB

Простая демонстрация этого  подхода может быть следующим  образом создана в Oracle ESB - компоненте ESB инфраструктуры Web-сервисов в Oracle Fusion Middleware.

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

• Новый служащий должен быть зарегистрирован в отделе безопасности, который должен создать для него учетные записи, выпустить идентификационную карту (бейжд) для прохода в здание, и так далее.
• Отдел финансов должен сделать различные приготовления для включения нового служащего в платежную ведомость и отчетность о расходах.
• Клуб младших менеджеров должен пригласить любого сотрудника в возрасте моложе 40 лет, занимающего управленческую должность, вступить в их клуб. С этой целью они хотят быть проинформированы о любых новых нанимаемых, соответствующих двум этим условиям

Реализация сервиса  для этого простого бизнес-события, использующая Oracle ESB, могла бы выглядеть примерно следующим образом:

Рисунок 3. Реализация сервиса для простого бизнес-события

Бизнес-событие NewEmployee переходит в число опубликованных ("опубликовали и забыли") отделом кадров (который с этой целью вызывает Web-сервис ESB). Сервис ESB потребляет событие и выполняет три правила маршрутизации, которые также выполняют некоторое преобразование:

• Вызывается целевой сервис SendNewEmployeeFileToJuniorManagerClub и записывает файл CSV в целевой каталог
• Вызывается целевой сервис InformFinanceDepartmentOfNewEmployee и записывает новую запись Employee (служащий) в базу данных Finance (финансы)
• Вызывается сервис NotifySecurityWebService, чтобы передать сообщение, содержащее данные для нового служащего (New Employee). Это, в свою очередь, запускает процесс BPEL Workflow, который требует ручной деятельности по созданию идентификационной карты безопасности для нового служащего.

Когда развертывается этот сервис, любой вызов Web-сервиса ESB NewEmployee для публикации события New Employee приводит к срабатыванию двух или трех целевых сервисов. Ключевым моментом этой архитектуры является полное разъединение публикатора события (отдел кадров) и потребителей события - новые потребители могут быть добавлены без оказания какого бы то ни было воздействия на этот отдел. С изменениями в событии New Employee можно, вообще говоря, разобраться в сервисе Router Service, и они не должны воздействовать на потребителей события.

Для того чтобы разработать сервис ESB для этого события, мы должны выполнить следующие шаги:

• Загрузить и установить Oracle SOA Suite версии 10.1.3.1 или более поздней.
• Загрузить и установить Oracle JDeveloper версии 10.1.3.1 или более поздней.
• Запустить комплект SOA.
• выполнить JDeveloper.
• выполнить исходную настройку.

Исходная настройка

Прежде, чем мы сможем начать реализацию EDA, мы должны выполнить некоторые подготовительные действия. Более конкретно, мы должны создать таблицу в схеме базы данных, используя сценарий DDL, скопировать являющийся доступным для JDeveloper файл в каталог нашей файловой системы, , и развернуть очень маленький и простой проект BPEL в нашем экземпляре SOA Suite.

Ниже приводятся шаги настройки:

1. Разархивируйте во временный каталог загрузку демонстрационного кода .
2. Используйте сценарий employees_table.sql для создания таблицы EMPLOYEES в схеме базы данных по вашему выбору. Эта таблица будет позже использована для вставки новых записей.
3. Скопируйте файл NewEmployeeEvent_Template.csv в каталог, который доступен из JDeveloper. Этот файл будет использован в мастере File Adapter Wizard для моделирования файла, который должен быть записан сервисом ESB, разработать который мы попытаемся в этой обучающей программе.
4. Разархивируйте в рабочий каталог файл SecurityProcessingNewEmployee.zip. Он содержит маленький проект JDeveloper версии 10.1.3.1 с процессом BPEL: SecurityProcessingNewEmployee. Это простой процесс, вызывающий сервис BPEL Workflow, который делает так, чтобы отдел безопасности наследовал задачу создания новой идентификационной карты для каждого нового служащего.
5. Загрузите проект SecurityProcessingNewEmployee в JDeveloper версии 10.1.3.1. В вашем экземпляре SOA Suite разверните проект в BPEL PM. В то время, когда вы разрабатываете в ESB сервис EDA, этот процесс BPEL должен быть доступен.

Разверните процесс BPEL: для этого следует щелкнуть правой кнопкой мыши по SecurityProcessingNewEmployee и выбрать опцию Deploy, а затем выбрать опцию BPEL Process Deployer:

Рисунок 4. Процесс BPEL

Полученное  в результате всплывающее окно позволяет  нам выбрать Connection (подключение) к экземпляру PM BPEL.

Нужно выбрать правильное подключение и кликните по OK, чтобы запустить развертывание.

Создание приложения JDeveloper

Находясь в среде JDeveloper, нужно создайть New Application (новое приложение), которому следует присвоить имя EventDrivenArchitecture. Когда JDeveloper предложит создать для нас проект по умолчанию, кликним по Cancel.

Перейдем к New Gallery (новая галерея) и на сей раз выберем пункт Projects, ESB Project (проекты, проект ESB):

Назовите этот проект как-то вроде NewEmployeeEventService.

Когда откроется  диаграмма ESB, кликните по небольшой  иконке в левом верхнем углу, чтобы  создать систему (System):

Когда вы зарегистрируете  свой проект на сервере ESB, создаваемая  вами группа систем или сервисов станет доступной в среде консоли ESB. Сервисы являются частью системы  или группой в системе. Системы  и группы обеспечивают средство организации  сервисов, которое мало чем отличается от областей действия в процессах BPEL. Один важный аспект систем состоит  в том, что целевые сервисы  в различных системах будут вызываться из сервиса маршрутизации (Route Service) параллельно, в то время как целевые сервисы в той же самой системе будут вызываться последовательно.

Назовите новую  систему как-то вроде NewEmployeeEventSystem.

Прежде, чем  вы сможете начать работу с сервисом обработки событий (Event Handling Service) ESB, вы должны точно определить, какой именно тип сообщения необходимо получить от отдела кадров в том случае, если произошло событие New Employee. Это можно сделать, создав XML Schema Document (XSD - документ XML Schema), описывающий структуру сообщения XML, получаемого для события.

Перейдите к  New Gallery, выберитеузел General, XML и кликните в списке доступных элементов по XML Schema. Затем введите имя для нового документа XML Schema Document - в этом случае, NewEmployeeEventMessage.xsd.

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

Теперь давайте  возвратимся к вкладке ESB, где  вы можете приступить к созданию сервиса.

Перетащите  и оставьте компонент Routing Service из палитры компонент (Component Palette) в ESB Service. Введите имя для Routing Service и, используя кнопки Browser и Type Chooser, выберите в определении схемы NewEmployeeEventMessage элемент схемы NewEmployeeEvent.

Ниже приводится скриншот Type Chooser, который позволяет выбирать элемент XSD, описывающий ввод в этот Routing Service.

Поскольку вы создаете сервис в стиле "запустил и забыл" (асинхронный без обратного  вызова), вы не должны определять Reply Message (Ответное сообщение) или Fault (ошибка).

Вы должны позволить  внешним процессам непосредственно  обращаться в этот сервис (NewEmployeeEventRS RoutingService) через его интерфейс Web-сервиса. В тех случаях, когда для публикации этого события должны использоваться другие каналы - например, при помещении файла нового служащего на сервер FTP, при вводе нового служащего в таблицу базы данных или через JMS - вы можете добавить к сервису ESB входящие сервисы адаптера (Adapter Services), который переадресует приобретаемые ими сообщения сервису NewEmployeeEventRS. А пока предположите, что отдел кадров будет использовать интерфейс Web-сервисов.

Теперь о  выходных адаптерах. Вспомните, что  в событии заинтересованы три  стороны: отдел безопасности, финансовый отдел и клуб младших менеджеров.

• Отдел безопасности имеет конечную точку Web-сервиса, которая будет вызываться - фактически, которая является просто фронтальной стороной процесса BPEL, выполняющегося в отделе, включая Human Workflow (ручные этапы работ), куда входит физическое создание идентификационной карточки.
• Финансовый отдел хочет, чтобы вы непосредственно вставили новую запись в таблицу базы данных, после чего он сможет взять ее оттуда.
• Клуб младших менеджеров оговаривает как особое условие, что ему требуется получать известия о новых младших менеджерах через файл CSV, записанный в определенном месте в файловой системе. Они предоставляют пример файла, чтобы продемонстрировать точный формат подобного файла.

Так что, давайте  добавим исходящие сервисы к  сервису ESB.

В редакторе  диаграмм ESB (ESB diagrammer) перетащите в диаграмму File Adapter. В результате вы получите всплывающее окно для определения деталей сервиса File Adapter, которые вы будете использовать для записи файла CSV в файловую систему.

Введите имя  сервиса. Затем кликните по иконке Define Adapter Service рядом с полем WSDL File.

После этого  вы попадете в мастер File Adapter Configuration Wizard. На его первой странице укажите имя для сервиса. (Как правило, следует подтвердить то, что было предварительно указано во всплывающем окне Create File Adapter Service.)

После того как  вы кликнете по кнопке Next, вы окажетесь на странице Operation. Здесь вы указываете, что хотите, чтобы сервис записывал файлы.