ОГЛЯД

Управління WS-сценаріями - є лідер і конкуренти

_____

Продовження. Початок див. PC Week / RE, N 27/2004, с. 20, N 28/2004, с. 19.

Специфікації управління потоками виконання

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

До теперішнього моменту запропоновано кілька технологій для побудови композитних сервісів: XLANG (фірми Microsoft), BPFL (IBM), BPML (консорціуму BPML.org), WSCI (Sun, SAP, BEA, консорціум W3C), BPSS (консорціум ebXML / OASIS), WSCL (Hewlett-Packard). У цій запеклій боротьбі де-факто перемога дісталася новому гравцеві BPEL4WS, яку підтримала критична маса фірм-розробників ПЗ і яка успадкувала багато з позитивних властивостей попередників. Навіть вендори, які пропонували власні специфікації, тепер підтримують її в своїх продуктах. Тим часом зберігається актуальність специфікацій BPMI (вона не обмежена авторськими правами) і BPSS (ebXML як і раніше актуальний).

BPEL4WS (Business Process Execution Language for Web Services)

Призначення: побудова складових сервісів.

Дата 5 травня 2003 р

Автори: IBM, Microsoft, BEA, Siebel Systems, SAP.

Статус: де-факто стандарт, поданий для затвердження в OASIS.

BPEL4WS - де-факто XML-стандарт для опису складних бізнес-процесів і складових сервісів, є мовою для, спадкоємцем IBM WSFL і XLANG з Microsoft BizTalk Server.

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

Нагадаємо, що WSDL здатний здійснювати інтеграцію в рамках лише двох моделей - синхронного взаємодії без збереження стану обміну і асинхронних взаємодій з обміном некоррелірованнимі повідомленнями. BPEL4WS ж дає можливість використовувати WS в більш типових для бізнес-взаємодій обставин: послідовностей тимчасових (peer-to-peer) обмінів повідомленнями, як синхронних, так і асинхронних, причому зі збереженням стану процесу, який до того ж може мати велику тривалість за часом і торкатися більш ніж двох учасників. BPEL4WS дозволяє задавати змінні процесу, організовувати послідовні потоки операцій, потоки паралельних обчислень, умовні розгалуження, описувати правила з'єднання потоків, передавати змінні з одних потоків в інші, викликати сторонні Web-сервіси, створювати правила обробки виняткових ситуацій, задавати процедури компенсації збоїв. (Довгоживучий процес може складатися з атомарних транзакцій, які не можуть бути "відкинуті" і повинні бути компенсовані новими транзакціями.)

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

Взаємодія з партнерами завжди відбувається через Web-сервіси (т. Е. Обмін повідомленнями задається типу), а команди і дані для цього взаємодії инкапсулируются в структурі під назвою "партнерська зв'язок" (partnerLink). Партнерські зв'язки спираються на WSDL-сумісні опису операцій і сервісів. BPEL4WS використовує змінні (variables) для зберігання даних, пов'язаних зі станом процесу; як правило, вони містять повідомлення, отримані від партнерів або їх частини. Глобальні змінні для всього процесу називаються властивостями (Properties) - вони застосовуються як механізм передачі даних між потоками процесу і як засобу збереження його стану в цілому.

Взаємодія процесу BPEL4WS із зовнішнім світом

BPEL4WS ділить всі процеси на два типи: абстрактні (т. Е. Бізнес-протоколи) і розгорнуті (instantiated). Різниця між ними проходить в точках дотику з зовнішнім світом: в абстрактних процесах звернення до конкретних інформаційних систем не відбувається. Кодуються лише абстрактні точки прив'язки, які визначаються типами портів введення / виводу і типами повідомлень (т. Е. Застосовується модель WSDL). А в розгорнутих процесах використовуються вже конкретні дані про реально існуючих портах. Прив'язка абстрактних портів до конкретних проводиться за допомогою WS Addressing. Очевидно, що опис абстрактного процесу накладає на етапі розгортання обмеження на можливі характеристики підключається зовнішньої системи - вона повинна вміти передавати всередину процесу і назовні дані певного процесом виду, що в загальному випадку може виявитися нездійсненним. На щастя, це обмеження в значній мірі можна обійти за рахунок створення інтерфейсів-посередників.

BPEL4WS-процес являє всі зв'язки з партнерами як взаємодія через абстрактний WSDL-інтерфейс (portTypes і операції), на реальні сервіси посилань не робиться.

Приклад внутрішнього устрою процесу BPEL4WS

Примітка. BPEL4WS заснований на декількох XML-специфікаціях: WSDL 1.1, XML Schema 1.0, XPath1.0. В описі процесів використовуються WSDL-повідомлення і типи та модель даних XML Schema. Механізм маніпуляції даними забезпечує XPath. Всі зовнішні ресурси і партнери представляються як WSDL-сервіси.

BPML (Business Process Modeling Language)

Автор: консорціум виробників засобів BPM BPNI.org, 2002 г.

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

Специфікацію умовно можна вважати об'єднанням XLANG і WSFL. Ці дві мови побудовані на різних принципах - XLANG на моделі Pi-Calculus, а WSFL (IBM) - на мережах Петрі, але примиряються в рамках BPML 1.0. Після виходу BPEL4WS ці протиріччя ослабли, так як прийнята в ньому модель аналогічна моделі BPML 1.0. Ці дві технології спираються і на ідентичні стеки інших специфікацій - SOAP, WSDL, UDDI, XPath, XSDL і сумісні з WS-Security і WS-Transactions. Але багатша семантика BPML (допускає більш складні транзакції і сценарії компенсації) дозволяє моделювати з його допомогою складні бізнес-процеси реального світу, то, що в світі IBM + можливо тільки за допомогою WS Coordination / WS Transactions.

Ось основні подібності та відмінності, як їх сформулював сам консорціум в своїх документах:

- BPML безкоштовний на відміну від BPEL4WS;

- BPML включає BPEL4WS як підмножина;

- BPML і BPEL4WS мають ідентичний набір ідіом і синтаксис;

- BPML має багатий і насичений мову для опису як простих, так і дуже складних бізнес-процесів;

- BPML і BPEL4WS - обидва структуровані блоковим чином мови, але в BPML допускаються вкладені процеси;

- BPML заснований на моделі логічних процесів, що дозволяє створювати паралельні, що повторюються і динамічні задачі;

- BPML базується на WSCI для опису загальнодоступних інтерфейсів і діаграм процесів.

У 2004 р ця мова розвивався в суміжному напрямку - консорціум випустив специфікацію на графічну нотацію для графічного опису бізнес-процесів Business Process Modeling Notation (BPMN). Як ясно вже з назви, вона спрямована на представлення процесів в доступному людині вигляді, а не на описі їх у вигляді, зручному для виконання процесором.

Web Services Choreography Description Language (WS-CDL)

Статус: W3C Working Draft 27 April 2004.

Автори: Oracle, CommerceOne, Novell.

Специфікація призначена для створення сценаріїв взаємодії Web-сервісів в рамках загального бізнес-протоколу. Вона сповідує підхід "від загального у приватному". Спочатку пишеться сценарій обміну і вже потім формуються потрібні для нього Web-сервіси. Цим він кардинально відрізняється від BPEL4WS. Друга принципова відмінність - в цій специфікації не передбачено єдиного центру, з якого відбувається управління, і учасники (їх може бути багато) працюють з одним набором описів WS-CDL, адаптуючи до нього розгорнуті у себе системи. Це вирішує проблему довіри, що існує в реальному світі, - часто фірми не готові делегувати нікому управління своїми системами.

Діаграма паралельних потоків в BPEL4WS-сценарії

(Штрихові лінії - послідовні операції,

суцільні - синхронізації паралельних потоків обчислень)

Також WS-CDL не позиціонує як мову для опису виконання бізнес-процесу. Ця роль відводиться іншими технологіями (BPEL4WS і Java), але WS-CDL визначає порядок виконання операцій (умовне, послідовне, паралельне і виняткові ситуації) і правила для узгодженого управління прихованими від партнера бізнес-даними. Інтерфейсами для взаємодії систем в різних організаціях є WSDL-описані сервіси.

В рамках моделі WS-CDL інформація завжди обмінюється між учасниками певних бізнес-ролей (постачальник, покупець і ін.) І на основі відносин. Точками взаємодії між учасниками є канали, які описують, де і як повинен відбуватися обмін інформацією.

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

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

Схема застосування WS-CDL-хореографії

Хореографії будуються з взаємодій (Interactions), робочих блоків (WorkUnits), дій (activity) і структур упорядкування. Дії - компоненти нижнього рівня в хореографії, вони відповідають за реальну роботу. Наприклад, це - елементарні взаємодії, привласнення, якісь найпростіші операції. Структури упорядкування забезпечують порядок виконання операцій - паралельний, послідовний або вибір.

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

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

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

WS-CDL володіє багатьма позитивними якостями: вона виявляється транзакционной, створені хореографії можна багаторазово використовувати, процес диригування сервісами спирається і управляється потоками даних, є модульність (можна імпортувати компоненти з інших хореографії), є засоби контролю за винятковими ситуаціями та ін. Специфікація також сумісна з WS-Reliability, WS-CAF, WS-Security, BPEL4WS тощо.

Прімечаніе.В групу специфікацій W3C, присвячених диригування сервісами, входять ще два документи:

Web Services Choreography Requirements (статус - W3C Working Draft, 11 березня 2004 р .; автори - Sun, Nortel Networks, WebMethods, Enigmatec). Це набір вимог, яким повинна задовольняти модель диригування сервісами. Фактично - технічне обгрунтування WS-CDL, що розглядає низку сценаріїв використання моделі;

WS Choreography Model Overview (статус - W3C Working Draft, 11 березня 2004 р .; автори - Oracle, CommerceOne). Набір UML-діаграм, що описують елементи моделі WS-CDL.

(Далі буде)

Версія для друку

Тільки зареєстровані користувачі можуть залишати коментарі.