Используя простой пример, узнайте, как сконфигурировать ESB, чтобы "публиковать" события уровня предприятия.
Одной из наиболее важных концепций в области корпоративной сетевой архитектуры на базе сервисов (Service-Oriented Architecture - SOA) является концепция управляемой событиями архитектуры (Event-Driven Architecture - EDA). Подобно механизму событий, скажем, в средах JavaScript или 4GL, где триггеры - части исполняемого программного кода - могут быть сцеплены с событиями, например, с нажатой кнопкой, изменением значения поля или представлением запроса, EDA определяет то, как "сервисы" связаны с "бизнес-событиями".
Большинство бизнес-событий - в диапазоне от получения заказа или запроса на использование ресурсов и найма нового служащего или поставки некоторой части оборудования - вызывает в организации срабатывание нескольких ответных реакций. На несколько более детализированном уровне, в пределах шагов процесса имеются события - например, неудачный вызов сервиса, превышение предварительно определенного порога или достижение определенной цели - которые могут интересовать стороны, являющиеся внешними по отношению к самому процессу.
EDA позволяет вам публиковать все эти события из процесса, который создает их или сталкивается с ними, в центральную магистраль обработки событий, таким образом, делая их доступными для всех заинтересованных сторон. Процесс или сервис, в котором происходит событие, не должны заниматься этими внешними сторонами; иначе, в дополнение к искажению выполнения этого конкретного процесса, вы пришли бы к сильно связанным системам (что является просто кошмаром в плане обслуживания).
В этой статье вы будете учиться - на базе простого примера, основанного на Oracle ESB - как можно сконфигурировать эту центральная магистраль, чтобы донести опубликованные события, как сообщения, до внешних сторон. (Для тех из вас, кто слишком ленив, чтобы довести до завершения эту обучающую программу, в разделе "Заключение" дается ссылка на архивный файл, содержащий законченное приложение JDeveloper.)
Немного истории
В 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, могла бы выглядеть примерно следующим образом:
Бизнес-событие NewEmployee переходит в число опубликованных ("опубликовали и забыли") отделом кадров (который с этой целью вызывает Web-сервис ESB). Сервис ESB потребляет событие и выполняет три правила маршрутизации, которые также выполняют некоторое преобразование:
- Вызывается целевой сервис SendNewEmployeeFileToJuniorManagerClub и записывает файл CSV в целевой каталог
- Вызывается целевой сервис InformFinanceDepartmentOfNewEmployee и записывает новую запись Employee (служащий) в базу данных Finance (финансы)
- Вызывается сервис NotifySecurityWebService, чтобы передать сообщение, содержащее данные для нового служащего (New Employee). Это, в свою очередь, запускает процесс BPEL Workflow, который требует ручной деятельности по созданию идентификационной карты безопасности для нового служащего.
Когда развертывается этот сервис, любой вызов Web-сервиса ESB NewEmployee для публикации события New Employee приводит к срабатыванию двух или трех (для новых руководящих служащих в возрасте до 40 лет) целевых сервисов. Ключевым моментом этой архитектуры является полное разъединение публикатора события (отдел кадров) и потребителей события - новые потребители могут быть добавлены без оказания какого бы то ни было воздействия на этот отдел. С изменениями в событии 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.
Ниже приводятся шаги настройки:
- Разархивируйте во временный каталог загрузку демонстрационного кода .
- Используйте сценарий employees_table.sql для создания таблицы EMPLOYEES в схеме базы данных по вашему выбору. Эта таблица будет позже использована для вставки новых записей.
- Скопируйте файл NewEmployeeEvent_Template.csv в каталог, который доступен из JDeveloper. Этот файл будет использован в мастере File Adapter Wizard для моделирования файла, который должен быть записан сервисом ESB, разработать который мы попытаемся в этой обучающей программе.
- Разархивируйте в рабочий каталог файл SecurityProcessingNewEmployee.zip. Он содержит маленький проект JDeveloper версии 10.1.3.1 с процессом BPEL: SecurityProcessingNewEmployee. Это простой процесс, вызывающий сервис BPEL Workflow, который делает так, чтобы отдел безопасности наследовал задачу создания новой идентификационной карты для каждого нового служащего.
- Загрузите проект SecurityProcessingNewEmployee в JDeveloper версии 10.1.3.1. В вашем экземпляре SOA Suite разверните проект в BPEL PM. В то время, когда вы разрабатываете в ESB сервис EDA, этот процесс BPEL должен быть доступен.
Разверните процесс BPEL: для этого следует щелкнуть правой кнопкой мыши по SecurityProcessingNewEmployee и выбрать опцию Deploy, а затем выбрать опцию BPEL Process Deployer:
Полученное в результате всплывающее окно позволяет вам выбрать 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. Здесь вы указываете, что хотите, чтобы сервис записывал файлы.
На шаге 3 вам будет предложено указать каталог вывода и соглашение об именовании для файлов, которые будут записаны сервисом. Пока остановитесь на простейшем подходе и укажите жестко запрограммированный каталог - правда, это не лучший способ обеспечить переносимость вашего сервиса. При определении имени файла может быть использовано несколько динамических элементов, типа даты или даты и времени создания сообщения или последовательности, но только по одному за раз.
На шаге 4 укажите выходной формат для файла: как должна быть структурирована информация? Так как вы желаете записать файл CSV, кликните по кнопке Define Schema for native format.
В результате вы попадете в Native Format Builder (блок построения "родного" формата), где вы сможете создать XSD, который File Adapter сможет, в свою очередь, использовать для создания файла CSV по введенным в него данным XML. Используйте демонстрационный файл CSV, любезно переданный вам клубом младших менеджеров.
Примите значения по умолчанию и кликните по кнопке Next.
На следующей странице введите имя и местоположение демонстрационного файла или определите их с помощью кнопки Browse. Затем кликните по Next.
Примите значения по умолчанию со страницы 3. Кликните по Next.
Введите имена элементов, содержащих несколько записей и представляющих единственную запись. Например, используйте NewJuniorManagers и NewJuniorManager. Заметьте: они будут представлены при создании отображения для этого файлового сервиса; они не будут присутствовать в файлах, которые записаны.
На странице 5 примите значения по умолчанию. Кликните по Next.
На странице 6 проверьте флажок "Use the first record as the field names". К тому же, это сделает XSD более удобочитаемым - так как не затрагиваются файлы, записанные этим сервисом.
На следующей странице дается краткий обзор файла XSD, созданного мастером для использования с File Adapter. Вы можете ознакомиться с ним. После знакомства примите файл, кликнув по Next.
Вы попали на последнюю страницу мастера Native Format Builder. Кликните по кнопке Finish.
Мы возвращаемся в мастер File Adapter Configuration Wizard. Кликните по кнопке Next.
После этого кликните по кнопке Finish. Вы возвратитесь во всплывающее окно сервиса создания адаптеров файла (Create File Adapter Service). Еще раз кликните по кнопке Finish.
Диаграмма ESB для сервиса NewEmployeeEventService расширяется за счет добавления сервиса SendNewEmployeeFileToJuniorManagersClub.
Дважды кликните по иконке NewEmployeesRS, чтобы определить правило маршрутизации, которое передаст сообщение NewEmployeeEvent в этот целевой сервис.
Чтобы создать новое правило маршрутизации, нажмите на зеленый знак "плюс". Будет открыт диалог Browse Target Service. Здесь вы можете выбрать сервис, в который правило маршрутизации передаст сообщение.
Выберите в элементе SendNewEmployeeFileToJuniorManagersClub операцию записи (Write) и кликните по OK.
Добавьте состоящее из двух частей выражение фильтра. В одной части должно быть сказано, что возраст нового нанимаемого не должен превышать 40 лет, а в другой - что его роль относится к числу руководящих. Так выглядит полное выражение, которое вы должны ввести:
/inp1:newEmployeeEvent/inp1:age < 40 and contains('MANAGER,PRESIDENT,
VICE PRESIDENT,TECHNOLOGY MANAGER,CFO,CHIEF,SUPERVISOR',/inp1:newEmployeeEvent/inp1:role)
Теперь вы должны указать, как преобразовать полученное из отдела кадров сообщение, чтобы передать его в целевой сервис.
Кликните по иконке отображения. Выберите опцию Create New Mapper File в диалоге.
Кликните по OK. Вы попадаете в инструментальное средство Mapper (картопостроитель). Здесь требуется подключить два документа XSD, которые определяют XSLT для преобразования из исходного XSD в целевой объект.
Сначала перетащим элемент newEmployeeEvent на вершину NewJuniorManager, чтобы создать простые, очевидные отображения.
Снимите флажок Match Elements Considering their Ancestor Names.
Итак, теперь у вас имеется первая сборка отображения:
Элемент роли еще не отображен в область Position, и вы знаете, что имеются специальные требования к формату даты для поля FirstDay.
Перетащите role в position. Затем перетащите format-dateTime Date Function из палитры компонентов на вершине подключения из firstDayAtWorkDate в firstDay.
Теперь дважды кликните по функциональному элементу, чтобы точно указать, как именно должно быть сделано преобразование:
Затем, давайте попытаемся разрешить конкретные потребности доставки сообщения для финансового отдела.
Финансовый отдел.
SQL> desc employees Name Null? Type ---------------------------- --------------- ---------------------- NAME NOT NULL VARCHAR2(50) GENDER VARCHAR2(1) JOB_TITLE VARCHAR2(50) START_DATE DATE
Для этого целевого объекта необходимо создать новый сервис адаптера. Используя Database Adapter, установите Target Adapter (целевой сервис) для NewEmployeeEventRS. Из раздела Adapter Service в палитре компонентов перетащим Database Adapter в документ esb. На экране появится следующее окно.
Введите имя сервиса адаптера (Adapter Service) и кликните по первой иконке после поля WSDL File, чтобы сконфигурировать адаптер базы данных.
Создайте New Database Connection для подключения к схеме FINANCE в корпоративной базе данных. (Примечание: Создайте подключение к схеме базы данных, в которой во время "Исходной настройки" была создана таблица EMPLOYEES.):
Определите имя подключения:
Затем введите имя пользователя и пароль для схемы FINANCE:
Кликните по кнопке Next, чтобы ввести дополнительные детали подключения:
На этом шаге вы должны указать детали URL JDBC, например, имена хоста, порта и SID базы данных. Когда это будет сделано, кликните покнопке Next, чтобы проверить подключение.
Если проверка прошла успешно, кликните по Finish. В противном случае, исправьте ошибочные детали.
Вы возвратитесь в мастер Database Adapter Configuration Wizard. Кликните по Next.
Выберите операцию, которую хотели бы поручить этому сервису: вставка новых записей.
Кликните по Next. Вы перейдете на страницу выбора таблицы (Select Table). Кликните по Import Tables (импорт таблиц), чтобы выбрать в базе данных Finance таблицу EMPLOYEES.
Кликните по Import Tables. Нажмите кнопку Query. Будет показан список всех таблиц в схеме FINANCE. Выберите таблицу EMPLOYEES и кликните по OK.
Когда страница мастера Select Table будет показана еще раз, кликните по Finish.
Вы возвратитесь в сервис Create Database Adapter; кликните по OK.
Теперь вернемся назад в диаграмму esb:
Подключите этот целевой сервис к NewEmployeeEventRS. Дважды кликните по иконке для Router Service.
Чтобы добавить правило маршрутизации, нажмите на зеленый знак "плюс":
В сервисе InformFinanceDepartmentOfNewEmployeeEvent выберите операцию Event и кликните по OK.
Кликните по иконке Mapping, чтобы определить отображение из входящего события NewEmployeeEvent в целевой сервис.
Выберите Create New Mapper File и кликните по OK.
Перетащите элемент события newEmployeeEvent в элемент top:Employees.
Снимите флажок Match Elements considering their ancestors.
Автоотображение дает вам первый шаг преобразования:
Вы должны вручную отобразить role на jobTitle и firstDayAtWorkDate на startDate. Для этого потребуется только перетащить элементы Source в элементы Target.
Заключительное отображение выглядит примерно следующим образом:
Кликните по иконке Save All. Вы близки к завершению: две из трех заинтересованных сторон уже связаны с событием NewEmployeeEvent.
Отдел безопасности.
В сервисе ESB вы должны создать другой сервис адаптера, который вызывает этот процесс BPEL, а затем связать его с Router Service.
Из палитры компонентов сервиса ESB перетащите элемент SOAP Service и опустите его в диаграмму ESB.
Появится всплывающее окно диалога Create Soap Invocation Service. Введите имя этого сервиса, например, NotifySecurityWebService. Затем кликните по иконке Service Explorer.
Выберите сервис SecurityProcessingNewEmployee (который к этому времени уже развернут на экземпляре BPEL PM).
Кликните по OK.
И еще раз на OK.
Дважды кликните на Router Service. Подключив сервис Soap Invocation Service к Router Service, вы собираетесь добавить новое правило маршрутизации.
Кликните по зеленому знаку "плюс", чтобы добавить новое правило маршрутизации.
Выберите операцию инициализации в целевом сервисе NotifySecurityWebService.
Кликните по OK.
Кликните по иконке Mapping.
Выберите Create New Mapper File и кликните по OK.
Отобразите событие newEmployeeEvent сервиса RouterService на сообщение SecurityProcessingNewEmployeeEventRequest.
Сохраните все.
Сервис ESB выглядит следующим образом:
Регистрация Router Service в ESB 
Пришло время зарегистрировать ваш сервис в ESB. Если у вас нет подключения к выполняющейся ESB, сначала выполните шаги, описанные ниже в конце раздела "Создайте подключение к ESB".
Кликните по проекту правой кнопкой мыши и выберите Register with ESB, а затем выберите подключение LocalESB_soasuite_10_1_3_1.
После успешной регистрации будет показан следующий отчет:
Если теперь перейти в консоль ESB, можно будет увидеть развернутые ранее сервисы.
Сервис NewEmployeeEventRS может быть вызван как обычный Web-сервис. Вы можете узнать его местоположение в WSDL, если перейдете на вкладку Definition Tab (вкладка определения) для этого сервиса:
Срабатывание события NewEmployeeEvent сервиса маршрутизации EDA 
Вы можете также войти в Enterprise Manager для вашего сервера приложений, чтобы увидеть, какие Web-сервисы имеются в экземпляре OC4J, а также проверить их.
Кликните по кнопке Test Service.
Перейдите к этой странице (кликнув по Test Web Service):
Введите значения для пяти входных полей и кликните по кнопке Invoke. Результат на консоли Enterprise Manager должен быть разочаровывающим, поскольку сервис ESB был асинхронным и не возвратил никакого ответа:
На консоли ESB вы можете увидеть новый экземпляр сервиса, запущенный только что сделанным нами обращением к Web-сервису:
Также вы можете видеть, что все три целевых сервиса были вызваны сервисом ESB, когда он получил известие о возникновении события New Employee.
Это должно означать, что:
- Отдел безопасности имеет ожидание нового технологического процесса.
- Клуб младших менеджеров имеет новый файл CSV.
- Финансовый отдел имеет новую запись в своей таблице EMPLOYEES.
Если войти в Worklist Application, зарегистрировавшись как JSTEIN - сотрудник отдела безопасности, который в настоящее время отвечает за все задачи, связанные с созданием идентификационных карт для новых служащих:
вы найдете, что в состоянии ожидания находится следующая задача:
Если посмотреть на каталог файловой системы, указанный клубом младших менеджеров, то вы увидите:
Если открыть этот файл, то вы найдете:
Что касается финансового отдела, то если через SQL*Plus подключиться к схеме FINANCE в этой корпоративной базе данных и выбрать всех служащих из таблицы EMPLOYEES, то вы увидите:
SQL> show user USER is "FINANCE" SQL> select * 2 from employees 3 / NAME G --------------------------------------------------------- - JOB_TITLE START_DAT --------------------------------------------------------- ---------- Lex Jellema M MANAGER 16-AUG-20
Создание подключения к ESB
Прежде, чем вы сможете подключиться к ESB, чтобы зарегистрировать в ней новые сервисы, необходимо создать соединение с сервером приложений.
В SOA Suite 10.1.3.1 для создания соединения Application Server Connection необходимо выполнить следующие шаги:
Перейдите к New Gallery и выберите опцию Application Server Connection.
Выберите в качестве типа подключения (Connection Type) Oracle Application Server 10g 10.1.3. Также предложите имя подключения. Кликните по Next.
Введите имя и пароль пользователя, которые используются для соединения с сервером приложений. Для локальной среды разработки, это, вероятно, будет пара administrator и oc4jadmin. Кликните по Next.
Следующий экран - это то место, где вы можете точно указать тот экземпляр сервера приложений, с которым вы хотите соединиться. Чтобы подтвердить, что вы используете правильное значение, проверьте файл opmn.xml в каталоге <soasuite_10_1_3_1_HOME>\opmn\conf. В этом файле ищите значение для атрибута запроса элемента порта.
Введите правильные значения и кликните по Next.
Кликните по Test Connection и ждите,что появитсясостояние Success!.
Кликните по кнопке Finish. Cнова перейдите к New Gallery. На сей раз выберите Integration Server Connection. Кликните по OK.
Наберите имя для подключения и кликните по Next.
Выберите правильное подключение Application Server Connection - то, которое вы только что создали. Также укажите правильный номер порта. (Правильную информацию о порте можно получить из файла SOA_SUITE_HOME\install\esbsetupinfo.txt.)
В идеальном случае, когда вы кликнете по кнопке Test Connection, вы получите выходные данные типа следующих:
Заключение 
Обязательства, взятые на себя EDA, состоят в том, что бизнес-события, служащие промежуточным звеном в инфраструктуре коммуникаций интеллектуальных событий, должны запускать слабо связанные бизнес-сервисы, которые могут вынести решение о принятии мер, как дополнительного результата события.
В этом обучающем материале вы видели, как бизнес-событие "вновь нанятый служащий" было обработано Oracle ESB, чтобы вызвать три несвязанных и разрозненных бизнес-сервиса, каждый со своим собственным механизмом доставки и форматом сообщения. Всю маршрутизацию, фильтрацию и преобразования делает для вас ESB. Здесь можно найти архивный файл, содержащий законченное приложение JDeveloper.
Как вы видели, реализация этой элементарной EDA с использованием Oracle JDeveloper и Oracle ESB оказывается довольно простым и прямым процессом, для которого не требуется никакого программирования и который в значительной степени управляется мастером. Развертывание и управление EDA - быстрое и простое дело.
Об авторе: Лукас Джеллема (Lucas Jellema) является менеджером по технологиям компании AMIS в г. Нойвегейн, Нидерланды, а также Oracle ACE и региональным директором Oracle Fusion Middleware. Лукас является регулярным блогером, автором и презентатором на международных конференциях и симпозиумах, а также разработчиком программного обеспечения многократного использования, типа JHeadstart Designer Generator, CDM RuleFrame и Oracle Designer Repository Object Browser.