ОБЗОРЫ

Управление 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.

(Продолжение следует)