Побудова керованої подіями архітектури за допомогою корпоративної сервісної шини

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

Розробка сервісу ESB за допомогою Oracle ESB

Проста демонстрація цього підходу може бути наступним чином створена в Oracle ESB – компоненті ESB інфраструктури Web-сервісів в Oracle Fusion Middleware.

У цьому випадку бізнес-подією є наймання нового службовця. Коли новий службовець підписує контракт, це подія публікується в ESB. Повідомлення про подію містить ім'я і прізвище, вік, стать, роль і дату виходу на роботу. Є кілька сторін, які цікавляться цією подією:


Реалізація сервісу для цього простого бізнес-події, що використовує Oracle ESB, могла б виглядати приблизно так:


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


Коли розгортається цей сервіс, будь-який виклик Web-сервісу ESB NewEmployee для публікації події New Employee призводить до спрацьовування двох чи трьох (для нових керівних службовців у віці до 40 років) цільових сервісів. Ключовим моментом цієї архітектури є повне роз'єднання публікатора події (відділ кадрів) і споживачів події – нові споживачі можуть бути додані без надання будь б то не було впливу на цей відділ. Із змінами в події New Employee можна, взагалі кажучи, розібратися в сервісі Router Service, і вони не повинні впливати на споживачів події.

Для того щоб розробити сервіс ESB для цієї події, ви повинні виконати наступні кроки:


Вихідна налаштування

Перш, ніж ви зможете почати реалізацію 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:


Отримане в результаті спливаюче вікно дозволяє вам вибрати 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 (помилка).


Висновок

Зобов'язання, взяті на себе 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.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*