Цією статтею хочеться відкрити цикл, присвячений IBM WebSphere ESB(далі - ESB) у розрізі розробки під цей продукт. І насамперед доведеться познайомитися ближче з технологіями такого роду.
Enterprise service bus (сервісна шина підприємства) - сполучне програмне забезпечення, що забезпечує централізований та уніфікований подієво-орієнтований обмін повідомленнями між різними інформаційними системами на принципах сервіс-орієнтованої архітектури.
Звичайно ж, можна і без спеціального ПЗ (можливо, щось спільне таки доведеться розробити) будувати корпоративну систему, ґрунтуючись на такому підході, і те, що в результаті вийде, називати сервісною шиною. Але в продукті від IBM є не тільки вже готовий апарат для централізованого обміну повідомленнями та контролю цього процесу, а й повний набір можливостей для розробки гнучких сервіс-орієнтованих програм спеціально під ESB. У результаті, можна виділити такі можливості та переваги IBM WebSphere ESB:

• Порядок та однаковість архітектурних зв'язків
• Централізоване управління
• Конфігурація програм на стороні сервера
• Реалізація технології Service Component Architecture (SCA) на кшталт принципів сервіс-орієнтованої архітектури
• Протоколо-незалежність програмного коду, що розробляється
• Широкі можливості конфігурування шини та додатків

ESB забезпечує транзакційний контроль, перетворення даних, збереження та гарантовану доставку повідомлень. Доступ до всіх сервісним службамчерез єдину точку дозволяє здійснювати конфігурацію комунікації сервісів централізовано. Також централізовано можна керувати збійними подіями для масової обробки помилок.
Класична топологія складання ESB – кластер, що забезпечує горизонтальну масштабованість та відмовостійкість. За офіційними рекомендаціями, збільшення кількості членів кластера збільшує продуктивність ефективніше, ніж нарощування потужності сервера при stand-alone топології. Крім цього, кластер можна перезавантажити (або його частина може відмовити) без припинення обслуговування.
Зазвичай ESB використовується як сервісний прошарок IBM BPM, але цілком може відігравати провідну роль у побудові моделі взаємодії корпоративних систем як потужний інтеграційний апарат (мається на увазі ESB як надбудова над IBM WebSphere Application Server).
Це, по суті, вимагається від ESB, тому що це «точка збору сервісів» - якщо вам потрібен сервіс, який працюватиме з іншими сервісами (можливо, зовнішніми), то інтеграцію між цими сервісами найлогічніше зробити саме на ESB. Для зовнішніх або гетерогенних сервісів можна зробити обгортку ESB-сервісом. Трохи проілюструємо зручність використання «єдиного житла» для сервісів:

Порядок
Чим більшого розміру система, тим важливіший у ній порядок і однаковість. Якщо йдеться про комплекс систем великого підприємства, То його точно вже можна назвати системою великого розміру. Звичайно, завжди можна знайти адміністратора, що тримає в голові схему взаємодії сотні серверів, або купу томів незв'язаної документації щодо кожного програмного модуля, де описано, з чим і як він взаємодіє.


Але набагато простіше мати сервіс (ESB), який дозволяє проводити всю взаємодію через себе. При такому підході частина архітектури взаємодії в будь-якій підсистемі вже зрозуміла – немає бардаку у зв'язках між системами, серверами та додатками: все пов'язане з ESB та ESB пов'язане з усім.

Централізоване управління
Завжди зручніше проводити налаштування систем централізовано - чи то конфігурування, адаптація до переїзду серверів, забезпечення стійкості до відмови, розподіл навантаження, обробка помилок або моніторинг і аналітика.


Наприклад, при переїзді сервера БД не потрібно залазити в конфігурацію всіх існуючих серверів додатків, і в налаштування конкретних додатків зокрема – достатньо мати одне змінне середовище в ESB, в якому вказується адреса БД, і тоді зміни потрібно буде виконати лише в одній точці.
Або ж якщо одна з зовнішніх систембула недоступна тривалий час, а жоден запит до неї не повинен загубитися – можна скористатися сервісом обробки збійних подій для «вкидання» повідомлень, що не дійшли тоді, коли це буде зручно.
Якщо вам потрібно регулювати кількість одночасних запитів до будь-якої системи, або моніторити ці запити, аналізувати навантаження, шукати вузькі місця, вам потрібно в центр управління обміну повідомленнями в консоль ESB-сервера.

Конфігурація на стороні сервера
«Єдине житло» для сервісів, з погляду конфігурування, дозволяє досягти кількох корисних цілей. По-перше, це повторне використання конфігурації (за аналогією з повторним використанням коду та модулів, яке так корисно в SOA), оскільки різні модуліі програми можуть використовувати одні й самі параметри з'єднання з БД, ресурси, параметри аутентифікації, змінні середовищата інше.


По-друге, при конфігуруванні на стороні сервера саме середовище роботи програми багато в чому може на нього впливати, що дозволяє переносити програми між різними контурами (тестовим та продуктивним), тюнінгувати і навіть виправляти баги без внесення змін до програми.

Якщо використовувати всі ці переваги, програми отримують здібності справжнього хамелеона – вони настільки гнучкі, що стають частиною середовища, в якому працюють, і при цьому привносять свій важливий функціонал.

Але гнучкість програм під IBM WebSphere ESB не обмежується середовищем їхньої роботи. Величезний вклад у це роблять можливості розробки. Оскільки системи не тільки потрібно мати, де запускати, але ще потрібно розробляти та доопрацьовувати, ці цікаві пункти не можна упускати:

SCA
Ця архітектура полягає в принципі надання компонентом своєї функціональності як сервісу, доступного іншим компонентам. В рамках одного модуля компонентами виступають програмні блоки (java код), що повністю реалізують певний функціонал, описаний відповідним інтерфейсом. Логіка виконання компонентів реалізується зв'язуванням їх у структуру за інтерфейсами та reference'ами ​​(Partner Reference).

Таку структуру модуля дуже зручно розробляти, перевіряти, розвивати, змінювати та підтримувати. Атомарність функціоналу, реалізованого в компонентах, дозволяє оперувати компонентами загалом, не опускаючись рівня коду. З іншого боку, вона логічно необхідна зважаючи на виконання імплементацій компонент у транзакційному контексті.
Кожна компонента має інтерфейс(и), імплементацію якого вона надає. Таким чином, пов'язуючи між собою компоненти, немає потреби знати їхні внутрішні особливості – достатньо того, що вони реалізують необхідні інтерфейси.
За допомогою цієї архітектури також можна вирішити всі завдання, які потребують паралельної роботи, без «ручного» керування потоками (наприклад, можна здійснювати асинхронні виклики кількох компонент із відстроченою відповіддю).
Не java-компоненти, наприклад, типів Export та Import, дозволяють надавати послуги для зовнішнього використання або використовувати зовнішні послуги відповідно; компонента Mediation Flow забезпечує низькорівневий доступ до повідомлень, якими обмінюються інші компоненти та дозволяє проводити різні перетворення під час роботи з гетерогенними інтерфейсами.
Крім інтерфейсів, дуже корисні можливості надає IBM Business Object Framework. Бізнес-об'єкти (БО), представлені xsd-схемами, використовуються як об'єкти передачі даних в інтерфейсах, як між компонентами, так комунікації між модулями. Вони безпосередньо інтегруються, наприклад, в wsdl-схему для опису веб-сервісів. Тобто, наприклад, якщо модуль «А» надає свій функціонал у вигляді веб-сервісу, модулю «Б» для його використання достатньо підключити інтерфейс і готові БО, і він зможе повною мірою працювати з таким сервісом без створення будь-яких додаткових java -об'єктів передачі даних. БО також зручно використовувати при обміні даними з БД, якщо ці дані використовуються іншими компонентами (це, звичайно, йде в розріз з патерном «DAO», але позбавляє зайвих java-об'єктів та операцій переписування даних «туди-сюди»).

Протоколо-незалежність програмного коду
Як можна було помітити, протоколо-незалежність коду досягається шляхом використання компонентів Export та Import. Оскільки зв'язок з цими компонентами йде за інтерфейсами та reference'ами, програмний код повністю незалежний від протоколу, що використовується для взаємодії. Один і той же функціонал можна легким рухом зробити доступним за будь-якою кількістю протоколів, що підтримуються, і за будь-якими потрібними інтерфейсами. На наступному малюнку показано додавання експорту з SCA прив'язкою до компоненту, що вже надає свій інтерфейс як HTTP, JMS та Web-сервіс.


Зручності очевидні – гнучкість, універсальність, повторне використання коду, швидкість розробки та модифікації.
До речі, прив'язка SCA використовує особливий протокол і призначена для повідомлення між модулями в рамках одного сервера/кластера. Взаємодія через цю прив'язку менш ресурсомістка і швидше в порівнянні з іншими протоколами.

Конфігурування
Конфігурація сервера та програм здійснюється через IBM console сервера.
В ESB, як і IBM WebSphere загалом, досить багато специфічних можливостей і артефактів. Наприклад, при використанні тих самих імпортів та експортів, можна «на льоту» конфігурувати end-point'и відповідних сервісів. Для викликів сервісів можна налаштовувати policy set'и з різноманітними правилами (наприклад, можна встановити підтримку механізму WS-AT, який дозволяє викликати веб-сервіс у тій транзакції, в якій працює клієнт; але транзакційність – це вже тема для повної статті), встановлювати параметри автентифікації, підключати сертифікати та інше.
Через конфігурування можна настроїти деякі механізми автоматичної реакції на виняткові ситуації (наприклад, автоматичне повторення виконання компонентів при помилках). Можна «на льоту» налаштувати трасування компонентів або змінити рівні логування. Також доступний сервіс керування збійними подіями, який можна свідомо використовувати для масової обробки помилок.
Ну і, звичайно ж, можна налаштувати багато іншого згідно специфікації Java2EE, яка іноді досить суворо реалізована в IBM Application Server.

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

У статті використано такі зображення:

При інтеграції корпоративних систем постає завдання управління довідковими даними. Для вирішення цього завдання часто використовується Master Data Management (MDM). MDM - це сховище, що містить “еталонні” довідкові дані, звані “золоті записи”. Довідники MDM містять очищені повні і несуперечливі дані.

Часто MDM використовується як платформа централізованого ведення довідників. Введення та валідація довідкових даних проводиться в MDM, а звідти вони реплікуються в ІТ-системи. Такий підхід має кілька проблем

• Створити еталонну модель даних, яка підійде всім системам не так просто.
• Довідкові дані стають відірваними від програм.
• Реплікація даних з MDM часто потребує серйозного доопрацювання систем. Для систем "з коробки" така доробка може бути дуже дорогою.

Інший підхід полягає в тому, що кожна бізнес-система зберігає довідники локально і організовує введення даних. При обміні повідомленнями між системами інтеграційна шина здійснює трансформацію з формату однієї системи до іншої. При цьому відбувається трансформація довідкових даних.

Трансформація на інтеграційну шину.

Ми використовуємо другий підхід. Усі взаємодії бізнес-систем відбуваються через інтеграційну шину. Шина (у нашому випадку Oracle Service Bus) трансформує повідомлення, яке надсилає система Постачальник, на повідомлення, зрозуміле системі Споживачу. Така трансформація включає мапірування значень довідників.

Дані про те, як довідники мапіруються між системами, зберігаються в реляційній базі даних, у нашому випадку - Oracle. У таблицях буде записано, як із значення довідника в одній системі отримати значення в іншій системі. Тобто якась така структура:

(source_system, source_value, valid_from, valid_to, target_system, target_value)

Дані у довідниках змінюються дуже рідко, а використовуються дуже часто. Щоб не звертатись щоразу до бази даних, довідники кешуються на шині, причому у форматі, який шина може відразу використовувати.

Для кешування ми використовуємо. Це дуже платний продукт. Однак, у даному випадкувсі його мега-функції не використовуються, тому цілком можна замінити на безкоштовне рішення (наприклад, hazelcast). Докладніше про coherence можна прочитати. Також ліцензія на coherence входить до різних Oracle Suite.

Використання кешу має очевидні переваги:

• дані зберігаються у пам'яті
• дані зберігаються у серіалізованому вигляді
• дані можуть бути проіндексовані
• синхронізація з базою даних може бути проведена асинхронно

Кеш є розподіленим і синхронізація між вузлами виробляється самим Coherence. При додаванні або видаленні сервера кластер здійснює ребалансування даних між вузлами.

Для довідкових даних використовується схема Distributed Cache Map. Під час старту Oracle Service Bus створюється кеш усередині JVM, який містить дані в пам'яті. На кожному фізичному серверіє сервер coherence, який зберігає довідники (в пам'яті і на диску) і синхронізується з базою даних.

При трансформації osb workflow звертається до coherence через Java callout. Можна також звертатися за допомогою Enterprise Java Bean.

Функції Enterprise Service Bus

Сучасна інтеграція інформаційних систем є реалізацією сервіс-орієнтованої архітектури (Service-Oriented Architectures, SOA) з використанням технологій Web-сервісів; існує багато чудових описів переваг та методів такої реалізації (див. розділ). Останнім часом ключовим компонентом інфраструктури SOA вважається корпоративна сервісна шина Enterprise Service Bus(ESB) (див. розділ ). Однак важливо точно знати, що таке ESB – продукт, технологія, стандарт чи щось інше. Зокрема, чи можна побудувати ESB сьогодні і якщо так, то як саме?

У цій статті ESB описується як набір функцій інфраструктури, що реалізується за допомогою технологій сполучного програмного забезпечення, що забезпечують підтримку SOA. ESB підтримує взаємодії з використанням сервісів, повідомлень та подій у неоднорідному середовищі, з належним рівнем сервісу та керованістю. У статті ми зібрали та класифікували самі різні функції. Однак не у всіх ситуаціях роботи з ESB обов'язково використовувати всі ці функції.

У статті визначається мінімальний набір функцій, що забезпечують виконання більшої частини вимог до ESB відповідно до принципів SOA. Визначивши мінімальний набір функцій, ми зможемо зрозуміти, які з наявних технологій можна використовуватиме ESB, що підтримує SOA. Зрозумівши, які додаткові функції диктуються вимогами конкретної ситуації, ви зможете вибрати технологію реалізації, яка найбільше підходить в цій ситуації.

У наступних статтях буде описано набір ESB-сценаріїв у звичайних вихідних точках SOA для реалізації ESB або SOA. У свою чергу, шаблони рішень допомагають вибрати потрібні технології для реалізації.

Оскільки розвиваються ситуації, у яких використовується рішення ESB, відповідним чином розвиваються та необхідні для ESB функції. Аналогічно розвиватимуться функції та засоби явно використовують ESB продуктів. Тому в заключній статті цієї серії ми розглянемо схему впровадження SOA та ESB, щоб дати рекомендації на першому етапі використання функцій та технологій ESB та продемонструвати можливості поступового впровадження.

Роль ESB у структурі SOA

Хоча ми і не будемо розглядати в деталях визначення SOA (див. розділ ), все ж таки тут корисно буде зібрати всі принципи, з якими погоджується більшість авторів визначень SOA:

• використання явно незалежних від реалізації інтерфейсів для визначення сервісів;
• Використання протоколів зв'язку, що підсилюють прозорість розташування та функціональну сумісність;
• Визначення сервісів, що інкапсулюють багаторазово використовувані бізнес-функції.

Звичайно, різні технології матимуть різні обмеження щодо фізичного розгортання підтримуваних ними шаблонів - одні з них можуть виявитися придатними для дуже масштабного розподілу та підтримки інтеграції у великих географічних областях, тоді як інші більше підходять для розгортання в локалізованих кластерах та забезпечують підтримку рішень з високою доступністю та масштабованістю. Порівняння вимог до фізичної розподіленості функцій технологій, які передбачається використовувати, є важливим аспектом розробки ESB. Крім того, дуже важливо забезпечити можливість збільшення розширення початкової розгорнутої системи для відображення еволюціонуючих вимог, інтеграції додаткових системчи розширення географічної доступності інфраструктури.

Малюнок 2. Централізоване управління розподіленою інфраструктурою ESB

Крім того, слід позначити позицію ESB щодо інших компонентів інфраструктури SOA, зокрема компонентів служби каталогів Service Directory, Business Service Choreography та Business-to-Business (B2B) Gateway. Оскільки перелічені вище принципи SOA не вимагають обов'язкової наявності цих компонентів, вважати їх необов'язковими компонентами. На показано інфраструктуру SOA, що демонструє відношення цих компонентів до ESB.

Малюнок 3: Роль ESB у структурі SOA

Для здійснення маршрутизації запитів сервісу ESB потрібний особливий каталог маршрутизації сервісу. Однак у SOA може також бути окремий каталог бізнес-сервісу, який, у найпростішій формі, може бути тимчасовий (використовується під час розробки проекту) каталог, що використовується забезпечення багаторазового використання сервісів розробниками організації. У поданні про Web-сервіси роль каталогу бізнес-сервісу та каталогу маршрутизації сервісу відводиться каталогу UDDI, тим самим забезпечується динамічне виявлення та виклик сервісів. Такий каталог може розглядатися як частина ESB, однак, доки такі рішення не отримають достатнього поширення, краще, щоб каталог бізнес-сервісу існував окремо від ESB.

Функцією компонента Business Service Choreographer є компонування бізнес-процесівз кількох бізнес-сервісів; тому цей компонент викликає послуги через ESB, а потім пропонує бізнес-процеси клієнтам як інші послуги, а також через ESB. Однак роль компонента Business Service Choreographer, технології організації виробничого процесу, у координації роботи бізнес-процесів та сервісів ідентифікує цей компонент як технологію інфраструктури, що не входить до ESB.

І нарешті, функцією компонента B2B Gateway є забезпечення доступності сервісів кожної з двох або більше організацій всім іншим організаціям керованим та безпечним способом. Корисно розглядати такі компоненти, як підключені до ESB, але не входять до її складу. Хоча існують шлюзові технології,що надають функції, необхідні для реалізації компонентів B2B Gateway, так і ESB, саме призначеннякомпонент B2B Gateway відокремлює його від ESB. Дійсно, для виконання своїх функцій цьому компоненту можуть знадобитися додаткові засоби, наприклад, інструменти керування партнерськими взаєминами, які не є частиною ESB та не обов'язково підтримуються технологіями ESB.

Модель продуктивності ESB

Узагальнює та класифікує деякі функції ESB, описані в літературі (див. розділ ). Одні з цих функцій є простими, інші, наприклад, функції автономності та інтелектуальні функції, є значним кроком до операційного середовища на вимогу (On Demand). Важливо розуміти, що для більшості існуючих сценаріїв використання ESB необхідні лише деякі з цих функцій з деяких категорій. Про мінімальномунаборі функцій, необхідних для реалізації ESB, ми поговоримо у розділі Мінімальний набір функцій ESB для SOA.

Таблиця 1. Функції ESB, описані у спеціальній літературі

Зв'язок	Взаємодія сервісів
Маршрутизація; Адресація; Технології, протоколи та стандарти зв'язку (наприклад, IBM® WebSphere® MQ, HTTP та HTTPS) Публікація/підписка; Відповідь/запит; Запустив-і-забув, події; Синхронний та асинхронний обмін повідомленнями.	визначення інтерфейсу сервісу (наприклад, мова WSDL (Web Services Description Language, мова опису Web-сервісів); Підтримка можливості заміни реалізації сервісу; Модель організації сервісу обміну повідомленнями, необхідна для зв'язку та інтеграції (наприклад, SOAP або модель зв'язуючого програмного забезпечення корпоративної інтеграції додатків (EAI, enterprise application integration); Каталог сервісу та виявлення сервісу.
Інтеграція	Якість сервісу
База даних; Агрегація сервісу; Адаптери для наявних систем та додатків; Забезпечення підключення до сполучного ПЗ EAI; Відображення сервісу; Перетворення протоколів; Середовище сервера додатків (наприклад, J2EE та .NET); Інтерфейс мови прикладного програмування для виклику сервісу (наприклад, Java та C/C++/C#).	Транзакції (Неподільні транзакції, Компенсація, WS-транзакція); Різні парадигми гарантованої доставки (наприклад, WS-ReliableMessaging або підтримка сполучного програмного забезпечення EAI).
Безпека	Рівень сервісу
автентифікація; Авторизація; Неможливість відмовитися від авторства; Конфіденційність; Стандарти безпеки (наприклад, Kerberos та WS-Security).	Продуктивність; Пропускна здатність; Доступність; Інші безперервні заходи, які можуть бути основою контрактів чи угод.
Обробка повідомлень	Управління та автономність
Закодована логіка; Логіка, що ґрунтується на контенті; Перетворення повідомлень та даних; Перевірка коректності; Посередницькі; Тотожне відображення об'єктів; Збагачення даних.	Ініціалізація та реєстрація сервісу; Веде журнали, вимірювання, моніторинг; Виявлення; Інтеграція з інструментами управління та адміністрування системи; Самоспостереження та самоврядування.
Моделювання	Інтелектуальні функції інфраструктури
Моделювання об'єктів; Загальні моделі бізнес-об'єктів; Бібліотека форматів даних; Відкриті або закриті моделі для інтеграції B2B; Інструменти розробки та розгортання.	Бізнес-правила; Керована політиками поведінка, особливо для функцій рівня сервісу, забезпечення безпеки та якості сервісу (наприклад, WS-Policy); Розпізнавання шаблону.

Багато з цих функцій можуть бути реалізовані за допомогою відповідних технологій або з використанням відкритих стандартів. Але технології, які претендують на використання в реалізації ESB, можуть значною мірою відрізнятися за характеристиками продуктивності, масштабованості та доступності, а також щодо того, які функції ESB та відкриті стандарти вони підтримують. З цих причин і внаслідок того, що деякі з значимих стандартівбули розроблені нещодавно або все ще перебувають у стадії розробки, багато хто критично важливі рішенняпо реалізації ESB в даний час пов'язані з пошуком компромісів між підтримкою зрілих технологій і менш зрілих відкритих стандартів.

У цій серії статей я не докладно розповідатиму про кожну з цих категорій функцій. Швидше ми зосередимося на тих, які мають значення для прийняття рішень щодо вибору підходу до впровадження або реалізації ESB. Зокрема, у наступному розділі ми зупинимося на тому, який мінімальний набір функцій необхідний підтримки SOA реалізацією ESB.

Мінімальний набір функцій ESB для SOA

Якщо більшість SOA-сценаріїв має значення лише підмножина перелічених раніше функцій, ми можемо поставити таке питання: які функції входять у мінімальнийнабір функцій, необхідних для реалізації ESB? Щоб відповісти на це питання, ми розглянемо найпоширеніші елементи визначення ESB, щодо яких немає особливих розбіжностей:

• ESB є логічним компонентом архітектури, який надає інфраструктуру інтеграції, що відповідає принципам SOA;
• Відповідно до принципів SOA, необхідне використання незалежних від реалізації інтерфейсів, протоколів зв'язку, що підсилюють прозорість розміщення та функціональну сумісність, а також визначення сервісів, що є відносно малодеталізованими та інкапсулюють функцію, що допускає багаторазове використання;
• ESB може бути реалізована як розподілена неоднорідна інфраструктура;
• ESB надає засоби для управління інфраструктурою сервісів та дає можливість працювати в сучасному розподіленому різнорідному середовищі.

Наведено мінімальний набір функцій ESB, вибраних з урахуванням цих принципів.

Таблиця 2. Мінімальний набір функцій ESB

Зв'язок	Інтеграція
Маршрутизація та адресація сервісів для забезпечення прозорості розміщення; Функція адміністрування для управління адресацією та ім'ям сервісів; Щонайменше одна з форм парадигми обміну повідомленнями (наприклад, запит/відповідь, публікація/підписка тощо); Підтримка щонайменше одного транспортного протоколу, який є чи може стати загальнодоступним.	Підтримка кількох засобів інтеграції з постачальниками сервісу, наприклад конекторів Java 2, Web-сервісів, асинхронного обміну повідомленнями, адаптерів тощо.
Взаємодія сервісів
Відкрита та незалежна від реалізації модель обміну повідомленнями та організації інтерфейсів, яка має ізолювати код програми від специфічних умов маршрутизації сервісів та транспортних протоколів, а також забезпечення можливості заміни реалізації сервісу

Зверніть увагу на те, що мінімальний набір функцій не вимагає використання будь-яких певних технологійнаприклад, сполучного ПЗ EAI, Web-сервісів, J2EE або XML. Цілком можливо, що такі технології будуть використовуватися, оскільки вони відповідають вимогам, але це не є обов'язковим. І навпаки, мінімальний набір функцій майже, якщо не повністю забезпечується простим використанням SOAP/HTTP та WSDL.

• Адресація URL та існуюча інфраструктура HTTP та DNS надають інфраструктуру "шини", що забезпечує маршрутизацію сервісів та прозорість розміщення;
• SOAP/HTTP підтримує парадигму обміну повідомленнями запит-відповідь;
• Транспортний протокол HTTPє широко доступним;
• SOAP і WSDL є відкритою, незалежною від реалізації модель організації інтерфейсу та обміну повідомленнями сервісів.

Тим не менш, використання SOAP/HTTP і WSDL у найпростішій формі насправді забезпечує лише інтеграцію від точки до точки і не надає наступних ключових функцій, необхідних для ESB:

• Відсутнє функція адмініструваннядля керування адресацією та найменуванням сервісів Імена сервісів контролюються в індивідуальному порядку кожним адаптером, тому керування маршрутизацією сервісу розподіляється між адресами, що викликаються клієнтами сервісу, інфраструктурою HTTP та іменами сервісів, що надаються адаптерам;
• Хоча цей підхід залежить від деталей реалізації, не сприяє забезпеченню заміни реалізації сервісу; код запитувача сервісу (можливо, згенерований інструментами розробки), часто буде безпосередньо прив'язаний до специфічної реалізації постачальника сервісів через специфічні протоколи за специфічними адресами. Заміна реалізації сервісу іншою реалізацією вимагатиме змін у коді програми та її повторного розгортання.

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

• Функції забезпечення якості сервісу та рівня сервісу;
• Концепція SOA більше високого рівня- Service choreography, каталог, перетворення і т. д.;
• Вимоги операційного середовища на вимогу (On Demand), такі як функції автономності та управління, а також інтелектуальні функції інфраструктури;
• По-справжньому неоднорідні операції в кількох мережах, з кількома протоколами та кількома доменами з різними моделямиволодіння.

Проблеми безпеки, пов'язані з ESB

У цій статті не передбачалося розглядати самі вимоги до безпеки, однак вони можуть мати значення при виборі технології ESB. Наприклад, якщо немає необхідності в аутентифікації та авторизації запитів до сервера, то вибір технологій може бути дуже широким. Якщо потрібно забезпечити певний рівень безпеки, що більш імовірно, то важливо оцінити, який стиль безпеки буде прийнятним. Наприклад:

1. Чи буде прийнятним рівень безпеки інфраструктури зв'язку при використанні взаємної автентифікації протоколу безпечних з'єднань Secure Socket Layer EAI між серверами ПЗ EAI або при використанні протоколу HTTPS?
2. Чи буде достатньо індивідуальною від точки до точки системи безпеки між системами-учасниками, чи необхідна наскрізна модель забезпечення безпеки? Наприклад, чи є необхідність поширення ідентифікаційної інформації клієнта через проміжні системи, наприклад, брокери, кінцевим постачальникам чи реалізаціям сервісу?
3. Чи буде прийнятною безпека на прикладному рівнінаприклад, чи може клієнтський код виконати базову автентифікацію HTTP за ідентифікатором користувача та паролем, чи зможе він передати цю інформацію сервісу як дані програми?
4. Чи потрібна відповідність механізму безпеки стандартам безпеки, наприклад, Kerberos або WS-Security?

Хоча можливі всі перелічені підходи до безпеки, рекомендується використання відповідних стандартів (наприклад, WS-Security) функцій забезпечення безпеки за підтримки інфраструктури та сполучного ПЗ. Однак ці стандарти з'явилися порівняно недавно, і підтримка їх програмними продуктами поки що знаходиться у фазі розвитку, особливо у випадках, пов'язаних із забезпеченням функціональної сумісності. Таким чином, одним із пріоритетів архітектури ESB має стати затвердження вимог щодо безпеки на ранніх фазах розробки, щоб їх можна було врахувати при виборі технології реалізації.

Висновок

У цій статті розповідалося про найзагальніші принципи SOA та їх зв'язки з технологією Web-сервісів. Виходячи з цих принципів автор стверджує, що компонент інфраструктури, що надає функцію маршрутизації, повинен забезпечити взаємодію сервісів між собою, а також підтримку заміни реалізації сервісу іншою реалізацією. Ці функції, серед багатьох інших, реалізуються за допомогою ESB.

ESB надає розподілену інфраструктуру та функції централізованого управління, для чого необхідний каталог маршрутизації сервісу та, крім того, можливо, каталог бізнес-сервісу. Компонент Business Service Choreographer викликає сервіси з ESB, а потім репрезентує процеси як нові сервіси через ESB.

Серед багатьох функцій, що надаються ESB, є функції:

• Зв'язки;
• взаємодій сервісів;
• Інтеграція;
• Забезпечення якості сервісу;
• Безпеки;
• Забезпечення рівня сервісу;
• Обробка повідомлень;
• Управління та автономії сервісу;
• Моделювання;
• Інтелектуальні функції інфраструктури.

У наступній статті серії ми розглянемо поширені сценарії, відповідні шаблони рішень для сценаріїв та поговоримо про найпоширеніші проблеми, пов'язані з цими сценаріями.

Подяки

Ця стаття навряд чи вийшла у світ, якби автор не обговорював свої ідеї з наступними людьми: Бет Хатчісон (Beth Hutchison), Рейчел Рейніц (Rachel Reinitz), Олаф Циммерман (Olaf Zimmerman), Хелен Уайлі (Helen Wylie), Kyle Brown), Марк Колан (Mark Colan), Джонатан Адамс (Jonathan Adams), Пол Фремантл (Paul Fremantle), Кейт Джонс (Keith Jones), Пол Вершурен (Paul Verschueren), Деніел Стермен (Daniel Sturman), Скотт Косбі (Scott Cosby), Дейв Кларк (Dave Clarke), Бен Манн (Ben Mann), Луїза Гілліс (Louisa Gillies), Ерік Гернес (Eric Herness), Біл Хассел (Bill Hassell), Гуру Васудева (Guru Vasudeva), Карім Юсуф (Kareem ), Кен Вілсон (Ken Wilson), Марк Ендреї (Mark Endrei), Норберт Біберштейн (Norbert Bieberstein), Кріс Нотт (Chris Nott), Алан Хопкінс (Alan Hopkins) та Ярослав Данчич (Yaroslav Dunchych).

Інтеграція додатків - питання, яке рано чи пізно постає перед ІТ-підрозділом будь-якої організації, в якій цих додатків більше одного. Ось далеко не повний перелікзадач, що укладаються в поняття «інтеграція»:

• необхідність ведення спільних довідників (наприклад, довідників клієнтів чи співробітників);
• запуск активностей в одній інформаційній системі при настанні подій в іншій;
• бізнес-процес (організована послідовність дій, що виконуються як людьми, так і інформаційними системами), що протікає в кількох додатках;
• інформаційна взаємодія з бізнес-партнерами (наприклад, автоматичний запитцін на комплектуючі у постачальника);
• уніфікація інформаційних обмінів та бізнес-процесів у філіях компанії.

Якщо виконання подібного роду дій відбувається на підприємстві рідко (наприклад, раз на день), то організувати ці дії можна кустарним шляхом - наприклад, за допомогою ручного вивантаження даних з одного додатка форматі Excelта завантаження їх в іншу програму або взагалі за допомогою дубльованого введення інформації відразу в дві системи. Однак якщо потреба в інформаційної взаємодіїдодатків виникає багато разів на день, то виникає питання про неефективне використання людських ресурсів і, як наслідок, виникає необхідність автоматизації цієї процедури.

Інтеграція на кшталт «точкоточка»

Завдання інтеграції «точка» відносно просте. Потрібно зрозуміти, яким чином кожна з двох взаємодіючих систем готова передавати та отримувати дані, створити відповідні технічні рішення для звернення до цих інтерфейсів, а також реалізувати механізм перетворення даних із формату системи джерела у формат системи приймача. У разі інформаційні системи надають для інтеграції спеціальний програмний інтерфейс (API), а гіршому - читання і запис інформації доводиться проводити у базу даних докладання. В результаті виникає локальне інтеграційне рішення - якийсь відокремлений програмний модуль власної розробки з усіма вимогами до його обслуговування та підтримання актуальності.

Інтеграція «крапка-крапка»

Це не складає велику проблемудо тих пір, поки інтеграцій «точка» мало - одна-дві. Однак практика показує, що кількість інтеграцій «точка» має схильність зростати, а якість управління цими інтеграціями - навпаки, стрімко падати. Причин тому багато: зростає число модулів інтеграції, з організації йдуть розробники, які робили той чи інший модуль, змінюються формати даних в системах, що інтегруються, і т.д. Сумним підсумком еволюційного розвитку інтеграцій «точка» є найскладніший «фарш» інтеграційних взаємодій між додатками підприємства, ставлення до якого співробітників ІТ-підрозділу найпростіше висловити в кількох словах: «Поки працює – краще не чіпати». Однак така ситуація не влаштовує ні сам ІТ-підрозділ, ні бізнес-замовників.

Інтеграційний «фарш»

Єдина сервісна шина

Переживши кілька поколінь різних підходів до інтеграції додатків, світова індустрія програмного забезпечення дійшла концепції єдиної сервісної шини підприємства (Enterprise Service Bus, ESB). З погляду архітектури, ESB - це програмне рішення, що забезпечує взаємодію всіх інтегрованих додатків через єдину точку, однаково, надаючи розробникам та адміністраторам уніфіковані та централізовані засоби розробки, тестування та контролю протікання всіх інтеграційних сценаріїв.

Основними компонентами, що становлять сучасну сервісну шину, є:

• брокер повідомлень - це високопродуктивна магістраль для обміну повідомленнями в уніфікованому форматі між програмами в режимі реального часу;
• адаптери - технологічні адаптери і адаптери до бізнес-систем забезпечують взаємодію Космосу з додатками у тому форматі, який їм прийнятний, представляючи інформацію з цих повідомлень в уніфікованому форматі, сприйманому брокером - що більше різних адаптерів надає та чи інша інтеграційна платформа, тим більше шансів, що для її впровадження у вашій організації не знадобиться додаткових робіт зі створення адаптерів, специфічних для ваших систем;
• середовище розробки інтеграційних сценаріїв - що простіше і швидше відбувається розробка сценаріїв інтеграції, тим менше вкладення коштів у цю розробку, отже, швидше від вкладених коштів. Сучасна інтеграційна шина надає у розпорядження розробника візуальні засоби конструювання інтеграційних сценаріїв, що у більшості випадків дозволяють обходитися без низькорівневого кодування;
• SOA-засоби - дотримання принципів сервіс-орієнтованої архітектури є безумовним стандартом всім інтеграційних рішень типу «єдина сервісна шина» (що зрозуміло за назвою). Інформаційні системи розглядаються тут як постачальники та споживачі сервісів, всі опубліковані в шині сервіси містяться в єдиний реєстрз можливістю повторного використання та управління політиками, пов'язаними з сервісами;
• різні інструментиконтролю та управління (аудити, протоколювання, централізований моніторинг, контроль за дотриманням угоди про рівень послуг тощо).

Перевагами використання єдиної сервісної шини можна назвати:

• масштабування - можливість будувати рішення будь-якого розміру та навантаженості;
• гнучкість - можливість реалізовувати та змінювати інтеграційні сценарії без істотного залучення розробників;
• безпека - вбудовані засоби аутентифікації та авторизації забезпечують контроль доступу до сервісів на рівні самої шини, позбавляючи розробників інтеграційних сценаріїв від завдань реалізації цих механізмів;
• використання відкритих стандартів - дозволяє зменшити залучення дорогих фахівців з пропрієтарних технологій;
• централізація засобів контролю та адміністрування – дозволяє уникнути «розмиття» точки відповідальності за інтеграційні сценарії, забезпечити оперативне спостереження та раннє сповіщення у разі збоїв.

Ще однією важливою вимогою до функціоналу ESB-середовища є можливість реалізації інтеграції з зовнішніми організаціями- бізнес-партнерами, постачальниками, корпоративними клієнтами, віддаленими філіями. Особливістю такої інтеграції є непередбачувана якість каналів, відсутність гарантій доставки інформації та слабка готовність до інтеграції як такої – як правило, організація-партнер надає дуже обмежений спектр форматів обміну даними. На цей випадок у складі інтеграційної шини має бути засіб побудови B2B-взаємодії, що дозволяє здійснювати інформаційний обмін за відкритими, у тому числі галузевими стандартами, забезпечувати гарантовану доставку, мати засоби налаштування інформаційного обміну в розрізі конкретного бізнес-партнера і, звичайно ж, працювати у повній відповідності до принципів самої інтеграційної платформи, ізолюючи розробника інтеграційних сценаріїв від технічних деталей взаємодії з партнером.

Enterprise Service Bus

Управління бізнес-процесами

Істотна частка інтеграційних сценаріїв передбачає, що у інформаційний обмін залучаються як додатки, які у ролі джерел чи приймачів інформації, а й люди - співробітники організації, виконують різні завдання чи приймають рішення. У цьому випадку ми можемо говорити про вихід за рамки «чистої» інтеграції та появу у фокусі нашої уваги нової сутності – бізнес-процесів, а у вимогах до інтеграційної платформи – нової функціональності з управління бізнес-процесами (Business Process Management, BPM). За наявності BPM-вимог інтеграційна платформа повинна надати розпоряднику:

• засіб візуального проектування бізнес-процесів - оптимально, щоб цими засобами могли скористатися люди, далекі від ІТ, наприклад бізнес-аналітики або методологи. Крім того, надзвичайно корисною є можливість перенесення моделей бізнес-процесів із спеціалізованих засобів моделювання в середу розробки. Це ж засіб має давати можливість проектувати форми завдань для учасників процесів, причому максимально убезпечуючи розробників від програмування;
• середовище виконання бізнес-процесів - спеціальний движок, що забезпечує обробку бізнес-правил, передачу завдань між користувачами та інформаційними системами відповідно до розроблених моделей бізнес-процесів, а також обробку виняткових ситуацій(наприклад, перевищення виконавцем часу, відведеного до виконання завдання);
• портал учасників бізнес-процесів - спеціалізований портал, що дозволяє користувачам запускати процеси, брати участь у них, контролювати хід запущених процесівта здійснювати адміністративні впливи відповідно до встановлених для них прав;
• засоби моніторингу та контролінгу. Можливість оперативного та ретроспективного аналізу протікання бізнес-процесів – важлива частина будь-якої платформи BPM.

На даний момент багато виробників ПЗ схильні об'єднувати BPM-середовище та інтеграційну шину в єдину платформу проміжного ПЗ, прибираючи суворе поділ, що існувало кілька років, між BPM-системами і засобами для інтеграції додатків. Такий підхід дуже прогресивний. Деякі вендори йдуть ще далі і приєднують до платформи професійні засоби для моделювання бізнес-процесів. Піонером у цьому є компанія Software AG, що пропонує рішення, що поєднує у собі відомий засіб моделювання ARIS Platform та інтеграційне/BPM середовище webMethods.

Комплексне використання інтеграційної платформи

Пропозиції на ринку

на поточний моментможна виділити три групи пропозицій для побудови ESB. Ці групи відрізняються як за ціною, так і за пропонованою функціональністю.

Перша група - пропозиції від фірм, чиї продукти лідирують у дослідженнях аналітичних агентств з усіх зазначених у статті категорій (ESB, SOA Governance, BPM, B2B). До цієї групи входять:

• IBM із лінійкою продуктів WebSphere;
• Software AG з інтеграційною платформою webMethods;
• Oracle із цілою серією пропозицій;
• Tibco із лінійкою Business Integration.

У принципі, тим, хто не любить компроміси, можна вибирати будь-якого з цих виробників - усі перелічені компанії пропонують повноцінні лінійки продуктів (щоправда, у випадку з Oracle не завжди зрозуміло, про який саме продукт йдеться, оскільки після купівлі ряду компаній Oracleпропонує одразу кілька продуктів, не завжди достатньою мірою інтегрованих між собою). Трохи окремо стоїть Tibco, оскільки розмір цієї компанії набагато менше розміру інших учасників цієї четвірки, що може викликати деякі сумніви щодо її стабільності. Software AG - поки не дуже відомий на російському ринкувиробник, але платформа webMethods, яка є сьогодні ключовою пропозицією цієї компанії, має великий потенціал. IBM і її продукти знають і використовують вже багато підприємств, але в деяких з них виникають претензії щодо вартості самого впровадження та обслуговування системи.

Друга група пропозицій - це компанії, сконцентровані в основному на «чистому» ESB-функціоналі та досягли успіху. До цієї групи потрапляють: Sun (Glassfish), Progress (Sonic) та Fujitsu.

Пропозиції від цих компаній хороші, якщо ви не збираєтеся розширювати сферу застосування своєї платформи у бік BPM та/або B2B. В іншому випадку ви ризикуєте опинитися наодинці з недостатньо опрацьованою функціональністю та суттєво збільшити свої витрати на її доопрацювання до відповідності своїм потребам.

Третя група найбільш численна і включає всі пропозиції, що не увійшли до попередніх двох груп. Перелік усіх пропозицій на тему ESB у цій статті безглуздо, ви можете отримати такий список у будь-якому пошуковику. Якщо ваш бюджет на інтеграцію обмежений, а самі ви схильні до експериментів - ви можете спробувати щастя з будь-яким з них. Однак ризики, що стосуються як недостатньо опрацьованої функціональності, так і можливих проблем з надійністю, технічної підтримкита перспектив розвитку продуктів, ви приймаєте на себе.

Висновок

Насамкінець хотілося б дати читачам кілька простих порадна вибір інтеграційної шини:

• замислюйтесь про побудову інтеграційного рішення, не чекаючи, коли проблеми взаємодії додатків притиснуть вас до стіни. Чим більший завал, тим складніше його розгрібати;
• ретельно підійдіть до вибору платформи. Шукайте вендора, який задовольняє вас за всіма позиціями, благо зараз є з чого вибрати. Вас мають цікавити і технологічні параметри платформи, та методологічні аспекти впровадження;
• думайте про перспективу. Функціональні вимоги, які усвідомлюються вами зараз, можуть суттєво змінитися через рік, і якщо платформа їх не задовольнятиме, то вам доведеться «переїжджати» на іншу. А один переїзд, як відомо, дорівнює двом пожежам.

У стрімкому процесі еволюції комп'ютерних технологій іноді несподівано розкриваються нові можливості старих ідей. Наприклад, такий, як, здавалося б, давно забута пам'ятьна феритових сердечниках. При всіх недоліках її позитивною якістю була здатність запам'ятовувати та зберігати дані нескінченно довго без підживлення – на відміну від сучасних модулів RAM на напівпровідниках. І ось буквально на наших очах вона відроджується у вигляді багатообіцяючої технології MRAM, в якій так само використовується двопозиційність петлі магнітної гістерези. Отже, вона зберігатиме свій стан без харчування. З відродженням магнітної пам'яті відійде у минуле така звична процедура завантаження комп'ютера.

Щось подібне відбувається і з магістралями обміну даними, побудованими за принципом загальної шини». Зараз важко оцінити революційність ідеї загальної шини, адже свого часу це був справжній переворот. Загальна шина Unibus, запропонована три десятки років тому інженерами корпорації Digital Equipment як архітектурна основа для міні-ЕОМ PDP-11, виявилася надзвичайно ефективним (а головне, дешевим) засобом інтеграції різнотипних пристроїв. Надалі на шинному принципі було побудовано безліч комп'ютерів, у тому числі всі сучасні ПК. Власне, із загальної шини і почав формуватися ринок периферійних пристроїв. Однак з часом шини, що використовуються як центральний архітектурний елемент комп'ютера, стали поступатися своїм місцем більш швидкодіючим комутаторам, залишаючись при цьому одним з основних варіантів підключення периферійних пристроїв. Сьогодні шина, яку називають Enterprise Service Bus (ESB), може зіграти приблизно ту ж роль, що й шина Unibus, з усіма перевагами, але на вищому рівні.

Події справді розвиваються стрімко. Лише рік тому один із провідних аналітиків Gartner Group Юхим Натіс висловив таке припущення: «Один із основних підходів до створення корпоративної інфраструктури додатків будується з використанням слабко пов'язаних асинхронних процесів». А вже в жовтні 2002 року в тижневику InfoWorld у статті Джона Уделла можна було прочитати: «Тепер, коли ми всі згодні з тим, що Web-служби повинні взаємодіяти в асинхронній манері, стало зрозумілим, що програмне забезпечення проміжного шару, орієнтоване на обмін повідомленнями (message-oriented middleware, MOM), набуває вирішального значення».

Як бачимо, лише за рік припущення перетворилося на затвердження. У тому, що це сталося, помітну роль відіграла компанія Sonic Software, утворена кількома вихідцями з BEA Systems і сьогодні визнана одним з лідерів у розробці програмного забезпечення проміжного шару. Дуже цікаві роботи зроблені ще в кількох невеликих компаніях(Наприклад, Collaxa), однак Sonic однією з перших запропонувала свою реалізацію слабопов'язаних асинхронних процесів. За всієї новизни, у своєму програмному продукті SonicXQ ESB компанія, по суті, реалізує стару, запозичену у міні-ЕОМ ідею загальної шини, але при цьому втілює її в новому вигляді.

В даному випадку ESB є загальною в тому сенсі, що поєднує всі програми підприємства. ESB, реалізована з використанням архітектури SOA (Service-Oriented Architecture), призначена для інтеграції корпоративних додатківна основі орієнтованих на документи асинхронних Web-служб та J2EE Connector Architecture (JCA). Дві ці технології забезпечують контентну маршрутизацію повідомлень і дозволяють організувати взаємодію між додатками, і так інтегрувати управління бізнес-процесами, що з'являється можливість обійтися без дорогих брокерів.

Оригінальність розробки SonicXQ привертала до себе значну увагу. Історично першими з'явилися інтеграційні брокери (іноді їх називають інтеграційними серверами). Рішення, побудовані з урахуванням інтеграційних брокерів, можна як комутаторів. З їхньою допомогою формується деякий гіпотетичний метакомп'ютер, де все управління будується за централізованим принципом. В результаті виходить щось на кшталт гіпер-мейнфрейму. Sonic зробила приблизно те саме, що DEC, що запропонувала три десятиліття тому шинні мініЕОМ як недорогу альтернативу мейнфремам; Рішення Sonic дозволяє побудувати свого роду метакомп'ютер для всього підприємства, але дешевший. У результаті виходить аналог міні-метакомп'ютера: замість дорогого комутатора пропонується інформаційна магістраль підприємства Enterprise Service Bus.

Технологія SonicXQ з'явилася раптом. У неї два досить добре відомі джерела. Перший – програмне забезпечення проміжного шару на основі повідомлень. Цей тип програмного інструментарію переживає справжню реінкарнацію, особливо через появу Java Message Service від компанії Sun Microsystems. Про те, що відбувається цьому фронті можна прочитати в , а докладніше про SonicMQ, безпосередньому попереднику SonicXQ, - в . Обидві ці публікації зберігають актуальність, але за рік пейзаж корпоративного програмного забезпечення помітно змінився, особливо під впливом Web-служб. Ще рік тому, коли готувалися зазначені публікації, уявлення про те, що таке Web-служби і яке їхнє значення було досить розпливчастим. За минулий час ситуація помітно прояснилася, і Web-служби слід назвати другим джерелом SonicXQ.

Enterprise Service Bus

Серед подій минулого року слід зазначити появу у професійній термінології щось нове і незвичне. Одні, прихильники табору Micrososft/IBM, називають це «оркеструванням» (orchestration) Web-служб, інші з табору Sun/BEA - «хореографією» (choreography). Розпалюється чергова битва у війні стандартів за те, як краще налагодити узгоджену роботу корпоративних додатків з використанням Web-служб. Причина нової активності полягає в тому, що всім, нарешті, стало ясно: в умовах, що склалися, вичерпані можливості жорстко пов'язаних додатків, складність систем стала занадто великою. Однак вихідна схема поширення Web-служб з використанням побудованих за стандартом UDDI репозиторіїв виявилася малозастосовною для корпоративних цілей. У той же час, Web-служби та особливо їх асинхронні орієнтовані на документи версії пропонують реальний вихід із «глухого кута складності». З технічної точки, завдання створення корпоративної інфраструктури додатків з використанням слабозв'язаних асинхронних процесів має кілька альтернативних рішень.

Enterprise Service Bus, побудована на основі SonicXQ, є одним з них. За допомогою формованої SonicXQ корпоративної магістралі реалізується розподілена архітектураорієнтована на служби. ESB дозволяє створювати контейнери для розміщення служб. Служби легко зібрати і узгодити, оскільки упакована в контейнер і є частиною ESB служба представимо іншим частинам ESB. При цьому вся конструкція є віртуальною; реальна фізична мережа, у якій вона «живе», може змінюватися без втрати функціональності.

У процесі функціонування ESB одна або кілька зв'язаних служб знаходяться у спеціальному контейнері (service container). Контейнери є засобом просування служб з розподіленого процесу відповідно до маршрутами повідомлень (message itinerarу). Процедура проходження повідомлення виглядає так. Повідомлення надходить на вхід шини ESB. Тут до нього додається маршрут, який дозволяє організувати контентно-кероване просування розподіленим процесом, цей процес має децентралізоване управління. В рамках цього процесу повідомлення проходить через низку служб, досягаючи кінцевої точки, де виймається з контейнера.

Для визначення кінцевих точок можуть бути використані не фізичні, а логічні імена. Встановлення відповідності між фізичними та логічними іменами (mapping) здійснює спеціальний механізм, що є у складі ESB. Таким чином, в архітектуру спочатку закладено здатність до віртуалізації; система може змінюватися без модифікації коду та руйнування діючих бізнес-процесів. Конфігурація допускає кілька рівнів якості обслуговування (Quality of Service, QoS), що гарантують надійне проходження повідомлень між програмами. У загальному випадку, коли повідомлення проходить весь свій маршрут, воно виходить за кінцеву точку одержувача, а відправнику посилається повідомлення, що підтверджує отримання. Гідність розподіленого процесу передачі повідомлень на основі ESB полягає в тому, що за своєю логікою він дуже близький до взаємодії в реальному світі.

Основи: JCA та Web-служби

Пропонована ESB інтеграція додатків стала можливою завдяки появі архітектури з'єднань JCA від Sun Microsystems і SOAP, стандартного протоколу для Web-служб. JCA, спеціально розроблена для подолання складнощів, пов'язаних з інтеграцією програм, пропонує стандартизовані методи для вирішення цього завдання. Корпоративна інформаційна система, побудована за принципами JCA, використовує доступ до додатків інтерфейс JDBC. Сьогодні цей підхід дуже популярний; більшість сучасних серверів програм, у тому числі, BEA WebLogic та IBM WebSphere підтримують адаптери JCA. Крім того, багато постачальників пакетних рішень мають намір підтримувати JCA у майбутніх версіях своїх продуктів.

Оригінальність використання Web-служб у SonicXQ полягає в тому, як організовано процес «оркестрування» (або «хореографії»). В його основі лежить протокол SOAP, але накладений на простий та масштабований формат повідомлень. SonicXQ Enterprise Service Bus забезпечує сумісність як з асинхронною документальною моделлю SOAP (document asynchronous model), так і з синхронною моделлю SOAP, побудованою за принципом виклику віддалених процедур (RPC). У SonicXQ служби описуються на мовою WSDL, але WSDL безпосередньо інтегрований Distributed Processing Framework. В результаті служба може бути зареєстрована у зовнішньому каталозі UDDI, а може і не бути, якщо в цьому немає потреби.

Технологію SonicXQ можна без жодного перебільшення назвати екстремальною: вона зібрала в собі цілу низку сучасних тенденцій у корпоративних обчисленнях. Але, мабуть, найцікавіше полягає в тому, що вона дозволяє краще зрозуміти, що таке веб-служби. Причому не так на словах, а на ділі.

Література

1. Леонід Черняк. МОМ, друге народження //

2. Валерій Кор жов. Листоноша для додатків //

3. Stuart J. Johnston, Web Services Wars Take Artistic Turn. Choreography або orchestration? XML Magazine, 2002 № 10/11