Архітектури та засоби інтеграції додатків

  1. Наявність великого асортименту абревіатур (ESB, WSM і т.п.), поєднуваних в різних контекстах з SOA,...
  2. Російська дійсність
  3. Інтеграція як послуга
  4. компонентна SOA
  5. Додатки та інфраструктури

Наявність великого асортименту абревіатур (ESB, WSM і т.п.), поєднуваних в різних контекстах з SOA, свідчить про різноманітність рішень, а отже, і думок. Це не дивно: SOA не нав'язує методів інтеграції, а лише декларує уявлення компонентів систем у вигляді сервісів, якi характеризуються строго визначеною кордоном, публічно відомим інтерфейсом і автономним поведінкою.

Модель SOA залишає відкритим питання про те, як повідомлення потрапляють до сервісу від споживача. Таку гнучкість деякі вважають недоліком, стверджуючи, що SOA не є цілісною, готової до застосування архітектурою. Не вдаючись в деталі, зазначимо, що для розгляду самого процесу доставки повідомлень можна застосовувати іншу модель - архітектуру, керовану подіями (event-driven architecture, EDA).

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

Предмет розгляду EDA - механіка доставки повідомлень (тобто подій, одягнених в конкретну форму). Маршрути прямування повідомлень можуть бути жорстко визначено каналами взаємодії в клієнт-серверному стилі, але частіше зустрічаються випадки гнучко настроюється під зміни середовища логіки маршрутизації. Так, вона може бути заснована на сучасному механізмі оркестровки або маршрутизації на базі контенту (content-based routing, CBR) кожного з повідомлень. Головне, що SOA не обмежує рамок пов'язаності систем. Саме тому часто говорять, що модель SOA - «слабо пов'язана». Завдяки цьому взаємодія з сервісами може бути як прямим, так і опосередкованим, виконуваних за допомогою всіляких програмних засобів проміжного шару. До них традиційно відносяться інтеграційні брокери (enterprise application integration, EAI) і черги повідомлень (message-oriented middleware, MOM)

Подібне розділення інтеграційного програмного забезпечення і відповідних підходів добре ілюструє різницю в акцентах SOA і EDA. Виробники брокерів схильні бачити в своїх продуктах платформи для агрегації сервісів різних систем, призначені для побудови композитних додатків. Однією з характеристик SOA є можливість агрегації сервісів для створення нових, і в цьому відношенні брокери можуть бути придатною платформою. Модель роботи черг базується на зворотному принципі: системи-адресати підписуються на отримання повідомлень, в той час як їх публікатор не знає не тільки фактичних одержувачів свого повідомлення, але навіть їх числа. Якщо з брокерів інформацію «витягують» клієнти (стиль взаємодії pull), то з чергами повідомлень ситуація інша - в них публікують (push).

Семантика звернення до сервісу инкапсулирует одну з безлічі операцій, передбачених інтерфейсом сервісу, в той час як обробник одержуваного чергою повідомлення не має явного формализуемость інтерфейсу. Оброблювач отримує від диспетчера черги ту ж семантику події, яку передав черзі публікатор. Як правило, це різні варіації операції «доставити». Тим самим черги відносяться до однорідних інтерфейсів, таким як HTTP (операції GET, POST, PUT, DELETE) і SQL (операції SELECT, UPDATE, INSERT, DELETE), в яких розробник програми не має можливості варіювати операції.

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

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

Нові технології інтеграції

Корпоративна архітектура визначає стилі взаємодії в корпоративній мережі, але лише ними різниця в підходах не обмежується. Навпаки, подієва основа MOM і брокерная архітектура EAI за роки їх спільного існування стали зустрічатися в одних і тих же продуктах. Але навіть це не допомагало ІТ-департаментам встигати за бурхливо розвиваються бізнесом, що вимагає все більшої швидкості безперервної обробки очікуваних потоків подій і адаптації до змін структури бізнес-процесів. Це і дало поштовх розвитку нового покоління технологій, які уніфікують архітектурні стилі EDA і SOA в рамках загального простору рішень, що включають в себе різні стилі інфраструктурного (сервери додатків, брокери, черги) і прикладного (ERP, CRM і т.п.) програмного забезпечення .

До першого покоління Web-сервісів відносять багато в чому успішні ініціативи, що переслідували метою відкриття існуючих систем для зовнішньої взаємодії. Нове покоління Web-сервісів засноване на обміні документами, осмислено спроектованих інтерфейси взаємодії і численних розширеннях базового протоколу SOAP. У цій «інкарнації» Web-сервіси обіцяють стати найпоширенішою технологією реалізації як сервіс-орієнтованих, так і керованих повідомленнями систем, хоча ні ті ні інші не прив'язані саме до неї. Шаблони обміну повідомленнями (message exchange pattern, MEP) протоколу SOAP передбачають передачу повідомлень як в односторонньому порядку, так і в режимі «запит-відповідь», що є хорошим початком, але не дає достатньо семантики для управління взаємодіями на рівні інфраструктури.

Такі організації, як OASIS, W3C і WS-I, роблять активні дії для вдосконалення підтримки керованих подіями додатків. Цьому сприяє розширюваність SOAP, яка забезпечується композиційними властивостями протоколу. Подібно додатковим маркуванням на зразок «не кантувати», на SOAP-конверти можна «наклеювати» своєрідні електронні інструкції, що керують доставкою та обробкою повідомлень. Наприклад, так можна запросити певні канали та необхідний рівень надійності доставки.

Завдяки цьому механізму специфікації WS * (зокрема, WS-Addressing, WS-Eventing, WS-Notification, WS-ReliableMessaging і WS-Security) в сукупності c WSDL 2.0 дозволяють повністю реалізувати функціональність сучасних засобів проміжного шару, орієнтованих на повідомлення, без використання нестандартних протоколів. Це було помічено розробниками інтеграційних коштів, і в традиційних МОМ-рішеннях був реалізований як мінімум базовий варіант SOAP 1.1; багато хто пішов і далі.

Набуття альтернативного транспорту дозволило виробникам заявити про транспортну незалежності їх продуктів. Вони, як правило, представлені на ринку в новому сегменті корпоративних сервісних шин (enterprise service bus, ESB). Неважко зв'язати поява ESB з розгорілася незабаром після цього дискусією про повноцінність SOA і переваги EDA. Дихотомія заснована на переважаючій серед розробників ESB точці зору про домінуючу роль EDA в корпоративних архітектур, що неважко обюясніть їх комерційними інтересами. Знявши «сервісну» оболонку, під нею можна знайти давно відомі шини повідомлень від тих же виробників. Не випадково розробники ESB останнім часом займаються додаванням брокерних елементів в свої платформи.

В якості природного способу набуття сервіс-орієнтованих можливостей в стилі брокера багато розробників використовують мову виконання бізнес-процесів BPEL (Business Process Execution Language). Захоплення BPEL вже призвело до проникнення цієї технології в ESB, EAI і навіть в портальні рішення. BPEL описує XML-нотацію, що дозволяє уявити абстрактну модель бізнес-процесу (явні інформаційні потоки, що зв'язують системи) і відповідний цій моделі алгоритм. Останній може бути представлений у вигляді виконуваного Web-сервісу, що має опис інтерфейсу на мові WSDL, який тісно пов'язаний з BPEL.

Виклик операцій сервісу, реалізованого за допомогою BPEL, пускає в хід послідовність кроків, які виконуються контейнером BPEL відповідно до формальним описом логіки процесу. Серед таких кроків найцікавіші синхронні і асинхронні звернення до інших сервісів. Використовуючи їх, екземпляр процесу взаємодіє із зовнішніми системами. Він обюедіняет їх в єдиний потік, керований відповідними правилами маршрутизації і перетворення повідомлень. Таким чином, BPEL - «мова програмування SOA» - пропонує стандартну альтернативу власним мов інтеграції застарілих брокерів EAI.

Класична демонстрація можливостей BPEL заснована на процесі замовлення туристичної путівки, що включає в себе бронювання авіаквитків, номери в готелі і оплату. Складність полягає в оптимізують обмеженнях, що визначають необхідність мінімізації сумарної вартості поїздки. Ці обмеження поширюються на вартість квитків і місць в готелях, яка може варіюватися, а самі квитки (місця) на певні дні - навіть виявитися повністю розпроданими. Тільки після визначення оптимальних дат подорожі і успішного бронювання процес виробляє оплату за допомогою кредитної картки, а якщо це неможливо, відміняє броню і сповіщає про помилку. Локальна пам'ять, розгалуження, цикли і обробка виключень дозволяють повністю автоматизувати процес за допомогою BPEL.

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

Для підтримки самообслуговування партнерів добре підходить реєстр сервісів на базі стандарту Universal Description, Discovery and Integration (UDDI). Використовуючи цей підхід, авіалінії і готелі, з якими у власника процесу бронювання встановлені ділові відносини, отримують від нього дозвіл на автономну публікацію своїх сервісів і управління ними в партнерському реєстрі сервісів турагента. Клієнт цих сервісів, процес бронювання, при обробці запитів звертається до реєстру для виявлення доступних сервісів, після чого оперує ними відповідно до бізнес-логікою.

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

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

Російська дійсність

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

Рішення booklogic засноване на продуктах UnitSpace, призначених для експлуатації в віддаленому режимі. «Гостьова» модель дозволяє користувачам розміщувати сервіси в спеціальному навчальному центрі даних, оснащеному каналами зв'язку, апаратними засобами і має достатній обслуговуючий персонал, які було б недоцільно відтворювати кожному з клієнтів. Розміщення на майданчику booklogic типові сервіси забезпечують надання бібліографічної та цінової інформації, прийом комерційних документів і т.д. На стороні інтегрованих організацій залишається тільки клієнтська функціональність, яка синхронізує стан їх внутрішніх інформаційних систем зі станом сервісів booklogic.

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

Сервіси асоціюються в реєстрі з відповідними їм провайдерами - незважаючи на їх фізичне надання з одного центру даних.

Бізнес-сервіси booklogic оформлені у вигляді BPEL-процесів, виконуваних на майданчику. Оскільки власного механізму забезпечення можливості постійного зберігання обюектов даних в BPEL не передбачено, інфраструктура booklogic доповнена платформою створення «гостьових» сервісів даних для їх перетворення і довгострокового зберігання. Коли мова йде про критичних для бізнесу процесах, провайдер сервісів інтеграції не може сліпо сподіватися на успішне виконання віддаленого виклику - тим більше в Росії, де якість каналів зв'язку сильно варіюється.

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

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

Інтеграція як послуга

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

У цій сфері, крім вже обговорювалися програмних рішень, все більшої популярності набувають провайдери інтеграційних сервісів (integration service provider). Вони розміщують логіку диспетчеризації подій у власній інфраструктурі, доступною по Internet. Таким чином, користувачі позбавляються від необхідності керувати однією з найскладніших частин своєї ІТ-інфраструктури.

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

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

Поява першого покоління провайдерів інтеграційних сервісів було пов'язано з технологією EDI (Electronic Document Interchange). Тоді ці провайдери були операторами мереж VAN (Value Added Network), які забезпечували доставку комерційних документів EDI ще без інфраструктури Internet. Ті з них, які успішно пережили появу Internet, конвертуються в повноцінних провайдерів інтеграційних сервісів, додаючи в свої рішення ряд інтелектуальних функцій. Серед найбільш відомих операторів VAN, які працюють сьогодні на ринку інтеграції, можна назвати компанії GXS, Inovis, ClickCommerce і Sterling Commerce. Вони активно поповнюють лінійки своїх пропозицій, які забезпечуються в віддаленому режимі, іншими рішеннями - як прикладними, так і інфраструктурними.

Дуже цікава відносно молода компанія Grand Central Communications, ім'я якої походить від назви великого транспортного вузла Нью-Йорка. У цієї красивої метафори Grand Central відводить собі роль «інтеграційної кухні» для клієнтів, яким для інформаційного повідомлення один з одним потрібен тільки стандартний «глухий кут», а не ціла інфраструктура «семафорів», «рейок», «розв'язок», диспетчерів і адміністраторів. Стандартами, звичайно, не є ширина шпал і відстань між рейками, а XML, SOAP і WSDL. При цьому клієнти можуть самі керувати логікою взаємодії з контрагентами, використовуючи поки не завершену реалізацію BPEL.

Данило Фейгін ( [email protected] ) - віце-президент з технологій компанії UnitSpace (Москва).

компонентна SOA

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

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

Найбільш чітко сформульованої стратегією перекладу своєї ERP-системи в сервіс-орієнтовану архітектуру на сьогоднішній день володіє компанія SAP. Але і ряд менш великих постачальників рішень цього класу озвучили власні ініціативи в області SOA, наприклад шведська компанія IFS.

Основною архітектурною особливістю системи IFS Applications є компонентний підхід до побудови ERP-додатки. Принцип складання з компонентів реалізується на рівні бізнес-рішень і на рівні технологічної інфраструктури. Сама система надається користувачам як сукупність автономних інтегрованих модулів для підтримки певних функціональних напрямків роботи підприємства, а також ключових бізнес-процесів загального значення (управління ефективністю бізнесу, CRM, SCM, управління якістю, управління проектами, документообіг, бізнес-моделювання). Кожен функціональний модуль, в свою чергу, збирається з обюектов різних рівнів технологічної платформи - IFS Foundation1.

IFS Foundation1 забезпечує необхідні засоби для проектування, обюектно-орієнтованої розробки, розгортання і адміністрування модулів IFS Applications на базі стандартів UML, J2EE і .Net. Розробники IFS говорять про архітектуру на базі моделей, маючи на увазі, що при роботі над системою основний акцент робиться на моделювання: моделювання бізнес-процесів за допомогою модуля Business Modeler і UML-моделювання обюектов нижчого рівня, що дозволяє скоротити час на створення власне коду. Процесна модель описує порядок функціонування програми, в той час як модель на рівні обюектов - його побудова. В цілому слідування компонентного принципом на макро- і мікро-рівнях підвищує гнучкість модернізації як бізнес-логіки, так і технологічних основ ERP-рішення.

Новий технологічний фундамент системи IFS Applications 2004 році отримала назву Service Oriented Component Architecture (SOCA). І цей підхід цілком відповідає ідеології SOA, що не нав'язує нової організації розподіленої середовища, а пропонує додатковий рівень абстракції для подання прикладних компонентів системи як взаємодіють один з одним сервісів.

IFS Foundation1 підтримує триланкову архітектуру розподілених систем, без якої неможлива ефективна «компонентізація» бізнес-функцій та інфраструктури. Функціональні бізнес-компоненти системи технологічно розбиваються на програмні обюекти різних рівнів з чітко визначеними інтерфейсами і завданнями. Система IFS Applications складається з понад 5 тис. Обюектов, визначених і документованих за допомогою UML.

Презентаційний рівень і рівень баз даних в цій архітектурі цілком традиційні та використовують технології порталів і різних призначених для користувача інтерфейсів і реляційних СУБД відповідно. Рівень бізнес-логіки реалізує функції ERP-системи і потоки робіт в рамках бізнес-процесів. Для цього вводяться обюекти декількох типів:

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

Об'єкти рівня бізнес-логіки забезпечують інтеграцію високорівневих бізнес-компонентів IFS Applications. Обюекти дій реалізують користувальницький доступ до функціональних модулів системи за допомогою стандартних інтерфейсів різних типів - традиційних робочих місць під керуванням ОС Windows, браузерів і мобільних пристроїв. Сервісні обюекти вводять новий тип комунікацій для бізнес-модулів на базі XML і забезпечують взаємодію цих компонентів з базовими комунікаційними сервісами. У IFS Foundation1 реалізована єдина архітектура інтеграції IFS Applications із зовнішнім світом - IFS Connect, що забезпечує взаємодію бізнес-процесів підприємства з іншими процесами, додатками і технологіями. IFS Connect надає адаптери для різних типів інтеграції, включаючи EDI, середовища проміжного шару, орієнтовані на обмін повідомленнями, простий імпорт / експорт файлів і ін. З переходом до архітектури SOCA система IFS Connect була доповнена можливостями уявлення будь-якого сервісного обюекта в IFS Applications у вигляді Web -cервіса, що взаємодіє з іншими сервісами по протоколу SOAP. Всі комунікації системи IFS Applications із зовнішнім світом за допомогою IFS Connect переводяться на мову XML, при цьому IFS Connect може конвертувати XML-повідомлення таким чином, щоб використовувати різні типи з'єднань, наприклад WebSphere MQ для зв'язку з додатком на мові Кобол, реалізованим на мейнфрейми.

Внутрішні інтеграційні механізми IFS Foundation1 реалізовані з використанням J2EE, а IFS Applications може бути розгорнута на базі серверів додатків від IBM, BEA Systems, Sun Microsystems і Oracle, включаючи і рішення з відкритим кодом Jboss і TomCat. Однак розробники не хотіли обмежувати своїх клієнтів тільки цим типом інфраструктурної платформи, тому в IFS Applications 2004 існують спеціальні модулі для реалізації Web-сервісів для .Net і можливості доступу до компонентів IFS Applications з .Net-додатків.

Переходячи до програмної архітектурі SOCA, в IFS прагнуть підготувати свою ERP-систему до епохи корпоративних композитних додатків, які будуть інтегруватися з існуючих прикладних рішень, перетворених в сервіси, і забезпечувати оптимальну автоматизацію бізнес-процесів. Але для цього знадобиться ще чимало технологічних проривів.

--Наталья Дубова

Додатки та інфраструктури

Компанія SAP пропонує клієнтам корпоративну сервісну архітектуру Enterprise Services Architecture. Як і лінійка програм нового покоління mySAP Business Suite (включаючи mySAP ERP), вона заснована на рішенні SAP NetWeaver, ядром якого є підтримує Web-сервіси сервер додатків J2EE. Він служить основою для брокера інтеграції Exchange Infrastructure (XI), ключова функція якого - оркестровка Web-сервісів на базі BPEL. Спільно з порталом та іншими інфраструктурними елементами NetWeaver, брокер XI використовується для створення композитних додатків SAP xApps, інтегруючих функції різних систем в єдиний бізнес-процес.

Прикладами таких композитних додатків можуть служити продукти сімейства SAP Employee Productivity xApps. Вони містять інтегрований набір засобів самообслуговування співробітників. Композитний проявляється в обюедіненіі додатків управління людськими ресурсами, фінансами і відносинами з клієнтами. Функції додатків забезпечують виконання запитів співробітників, в той час як xApps виводять такі функції на новий канал взаємодії. В даному випадку це просто призначений для користувача портал, що сприяє підвищенню продуктивності роботи співробітників.

Технологією композитних додатків займається корпорація Oracle. В результаті придбання молодої компанії Collaxa вона отримала доступ до однієї з найбільш зрілих реалізацій BPEL. Продукт, відомий тепер як Oracle BPEL Process Manager, займає центральне місце в «сервіс-орієнтованому» позиціонуванні Oracle, а його значення для компанії не можна визначити інакше як стратегічне. У лінійці продуктів проміжного рівня версія 10.1.3 цього продукту буде представлена ​​в складі Oracle Application Server 10g (кошти виконання процесів) і JDeveloper (інструменти проектування процесів). У цьому виді BPEL стане також елементом лінійки прикладних продуктів Oracle Applications.

Намагається не відставати від конкурентів і компанія Siebel - один з лідерів в області CRM-додатків. У 2003 році вона представила рішення Universal Applications Network (UAN), архітектурно близьке до ESB, але має одну цікаву особливість, яка характерна для рішень інтеграції даних. На рівні UAN визначається єдине уявлення обюектов, загальне для всіх інтегрованих додатків, а потім інтеграційний сервер автоматично перетворює дані між різними форматами.

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