Оркестровка и хореография Web-сервисов

Для объединения Web-сервисов при создании высокоуровневых бизнес-процессов, в которые вовлечены несколько предприятий, необходима стандартизация моделей их взаимодействия. Сразу несколько отраслевых стандартов близки к реализации в конкретных программных продуктах.

В недавнем обзоре компании CSC ведущие специалисты расценивают организацию управления электронными коммуникациями между клиентами, поставщиками и партнерами как важнейшую отраслевую задачу [1]. Web-сервисы обеспечивают стандартизованные механизмы ее решения. Однако их недостаточная гибкость не позволяет справиться с техническими вопросами, связанными с интерфейсами Web-сервисов.

Термины оркестровка и хореография описывают два аспекта разработки бизнес-процессов на основе объединения Web-сервисов. На рис. 1 в общем виде показана взаимосвязь этих аспектов, которые в какой-то мере дополняют друг друга.

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

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

Требования к разработке процессов

Стандарты оркестровки и хореографии должны удовлетворять ряду технических требований, обеспечивающих разработку бизнес-процессов с привлечением Web-сервисов. Эти требования касаются как языка, служащего для описания последовательности действий в бизнес-процессе, так и инфраструктуры для его выполнения.

Во-первых, для обеспечения надежности и универсальности, необходимых современным вычислительным средам, жизненно важна возможность асинхронного обращения к сервису. Повысить производительность процесса позволяет возможность одновременного обращения к нескольким сервисам. Для реализации асинхронных Web-сервисов требуется механизм корреляции запросов, в качестве которого архитекторы программных систем обычно используют идентификаторы корреляции.

Во-вторых, необходимо, чтобы архитектура бизнес-процесса обеспечивала управление исключительными ситуациями и целостностью транзакций. Кроме обработки ошибок и тайм-аутов оркестрованные Web-сервисы должны гарантировать доступность ресурсов при выполнении длительных распределенных транзакций. Традиционные транзакции обычно не вполне пригодны для реализации длительных распределенных бизнес-операций, поскольку не позволяют достаточно долго блокировать необходимые ресурсы. При использовании компенсирующих транзакций каждый метод включает в себя операцию отмены, которую координатор транзакций может вызвать в случае необходимости (под компенсирующей транзакцией понимают возможность отката операции при ее отмене процессом или потребителем).

В-третьих, оркестровка Web-сервисов должна быть динамичной, гибкой и адаптивной, чтобы отвечать изменяющимся потребностям бизнеса. Достижению гибкости способствует четкое разделение логики процесса и используемых Web-сервисов, обычно обеспечиваемое механизмом оркестровки. Он обрабатывает поток работ бизнес-процесса, вызывая соответствующие Web-сервисы и определяя, какие шаги следует выполнить. Этот подход позволяет организации заменять сервисы в потоке работ.

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

Новые стандарты

Ранние работы

Разработанный Microsoft язык XLANG первоначально предназначался для описания последовательных, параллельных и многовариантных потоков работ для BizTalk Server. При описании интерфейсов Web-сервиса XLANG использует язык Web Services Description Language (WSDL), предложенный консорциумом World Wide Web Consortium (W3C). Основное назначение XLANG состоит в определении бизнес-процессов и организации обмена сообщениями между Web-сервисами. Кроме того, он имеет надежные средства обработки исключительных ситуаций с поддержкой длительных транзакций.

WSFL (Web Services Flow Language корпорации Microsoft) позволяет описывать как публичные, так и частные процессы. Он определяет обмен данными, последовательность выполнения (модель потока) и выражение каждого шага потока в виде конкретных операций (глобальная модель). WSFL поддерживает интерфейс WSDL, что позволяет решать задачи рекурсивной композиции, располагает средствами обработки исключительных ситуаций, но не поддерживает транзакции.

Центр ООН по содействию торговле и электронному бизнесу (UN/CEFACT) на основе XML разработал язык Electronic Business Extensible Markup Language. Стандарт ebXML обеспечивает набор программных компонентов промежуточного слоя, облегчающих сотрудничество деловых партнеров. В него входит схема спецификаций бизнес-процессов Business Process Specification Schema. Протокол BPSS позволяет определять как хореографию, так и коммуникационные протоколы между Web-сервисами.

Компания Hewlett-Packard разработала достаточно простой стандарт моделирования последовательности взаимодействий Web-сервисов - язык Web Services Conversation Language. В марте 2002 года WSCL был опубликован как Примечание W3C (W3C Note), а сейчас его рассматривает недавно созданная рабочая группа W3C по хореографии Web-сервисов.

Язык BPEL

В мае 2003 года Microsoft, IBM, Siebel, BEA Systems и SAP совместно разработали версию 1.1 спецификации языка BPEL4WS. Эта спецификация, для краткости иногда именуемая BPEL, позволяет моделировать поведение Web-сервисов при взаимодействии бизнес-процессов [2]. Ее составной частью является грамматика на основе XML, которая предназначена для описания логики управления при координации Web-сервисов, участвующих в потоке работ бизнес-процесса. Механизм оркестровки в соответствии с этой грамматикой может координировать действия и компенсировать процесс в целом при возникновении ошибок.

BPEL является расширением WSDL. Интерфейс WSDL определяет список возможных операций, а BPEL задает порядок их выполнения. WSDL описывает публичные точки входа и выхода для каждого процесса BPEL, а типы данных WSDL определяют информацию, которой обмениваются отдельные запросы бизнес-процесса. Кроме того, WSDL позволяет ссылаться на внешние сервисы, необходимые процессу BPEL.

BPEL поддерживает как исполняемые, так и аб?страктные бизнес-процессы. Исполняемый процесс моделирует поведение участников определенного бизнес-взаимодействия, в сущности, моделируя частный поток работ. Абстрактный процесс, или бизнес-протокол, определяет обмен публичными сообщениями между участниками. Бизнес-протоколы не являются исполняемыми и не отражают внутренних подробностей потока работ бизнес-процесса. Другими словами, исполняемые процессы моделируют оркестровку, а абстрактные процессы - хореографию Web-сервисов.

Спецификация BPEL4WS поддерживает как базовые, так и структурные действия. Базовое действие - это инструкция по взаимодействию с чем-то внеш?ним по отношению к процессу. Например, базовые действия обслуживают получение запроса, ответ и вызов Web-сервиса. В типичном сценарии исполняемый процесс BPEL получает сообщение. Затем он может активизировать ряд сервисов для сбора дополнительных данных, на основании которых будет сформирован ответ. На рис. 2 получение запроса, вызов и ответ являются базовыми действиями процесса.

Рис. 2. Поток работ биз­нес-про­цес­са в BPEL4WS. Спе­ци­фи­ка­ция под­дер­жи­ва­ет как струк­тур­ные дей­ствия для управ­ле­ния по­то­ком работ биз­нес-про­цес­са в целом, так и ба­зо­вые дей­ствия, ко­то­рые вклю­ча­ют вза­и­мо­дей­ствия с внеш­ни­ми Web-сервисами

Структурные действия управляют потоком работ бизнес-процесса в целом, определяя последовательность вызова Web-сервисов. Эти действия также поддерживают выполнение циклов и динамическое ветвление. По существу, они составляют основную логику программирования в BPEL.

Два других важных элемента BPEL - партнерские связи и переменные.

Переменная идентифицирует определенные данные в потоке сообщений. Когда процесс BPEL получает сообщение, он присваивает значение соответствующей переменной, чтобы последующие запросы могли обратиться к этим данным. Переменные используются для управления долговременным хранением данных в ходе обработки запросов Web-сервисов.

Партнерская связь может обозначать любой сервис, с которым взаимодействует данный процесс. Каждой партнерской связи приписана определенная роль в бизнес-процессе.

Язык WSCI

Компании Sun Microsystems, SAP, BEA и Intalio разработали спецификацию языка описания интерфейсов Web Services Choreography Interface (WSCI), которая определяет расширение языка WSDL, направленное на организацию совместной работы [3]. В августе 2002 года эта спецификация была опубликована в качестве Примечания W3C (W3C Note). В общем виде WSCI определяет хореографию, или обмен сообщениями между Web-сервисами. Спецификация обеспечивает корреляцию сообщений, правила упорядочения, обработку исключительных ситуаций, транзакции и динамическое взаимодействие.

Рис. 3. Совместная работа в WSCI. Спецификация интерфейса относится только к наблюдаемому поведению взаимодействующих Web-сервисов и не затрагивает определений исполняемого бизнес-процесса

Как видно из рис. 3, WSCI описывает лишь наблюдаемое поведение взаимодействующих Web-сервисов. В отличие от BPEL, при этом не затрагиваются определения исполняемых бизнес-процессов. Кроме того, интерфейс WSCI описывает участие в обмене сообщениями с позиции лишь одного из партнеров. Хореография WSCI должна включать в себя набор интерфейсов WSCI - по одному для каждого партнера, участвующего во взаимодействии. В WSCI отдельный процесс не может управлять взаимодействием.

Каждое элементарное действие WSCI представляет собой единицу работы, которая связана с определенной операцией WSDL. Спецификация WSCI расширяет возможности WSDL, позволяя упорядочить выполнение доступных операций WSDL. Другими словами, WSDL для каждого доступного сервиса описывает точки входа, а WSCI определяет взаимодействия операций WSDL.

WSCI поддерживает как базовые, так и структурные действия. Тег action определяет базовое сообщение для запроса или ответа. Каждое действие определяет соответствующую операцию WSDL и конкретного участника, который ее выполняет. К внешним сервисам можно обратиться с помощью тега call. WSCI поддерживает разнообразные структурные действия, включая выполнение циклов, последовательную и параллельную обработку.

Следующий интерфейс WSCI определяет процесс закупки, в который входят два последовательных действия - Receive Order («получить заказ») и Confirm («подтвердить»). Каждое действие отображается в набор абстрактных операций WSDL, а WSCI устанавливает между ними корреляцию. WSCI поддерживает бизнес-транзакции и обработку исключительных ситуаций. Разработчик бизнес-процесса может установить определенный контекст транзакции в рамках интерфейса WSCI, подобный контексту действия в BPEL4WS. Этот контекст определяет группу действий, неудачное завершение любого из которых «откатит» назад всю группу.

Язык BPML

BPML - язык описания бизнес-процессов на основе XML. Его спецификацию разработала некоммерческая организация Business Process Management Initiative по заказу Intalio, Sterling Commerce, Sun и CSC. Первоначально BPML создавался для описания процессов, выполняемых системой управления бизнес-процессами. Однако последний проект стандарта BPML, выпущенный в ноябре 2002 года, включает в себя также поддержку WSCI.

BPML содержит конструкции для описания действий и потока работ бизнес-процесса, подобные имеющимся в BPEL [4]. Наряду со структурными действиями для организации ветвления, последовательной и параллельной обработки, циклов и синхронизации процессов обеспечиваются базовые действия для отправки и получения сообщений, вызова сервисов. Кроме того, BPML позволяет разработчику бизнес-процесса планировать выполнение задач в соответ?ствии с расписанием.

Язык был разработан для управления длительными процессами и включает в себя функции долговременного хранения данных. Обмен данными между участниками ведется в формате XML, с использованием ролей и определений партнеров, подобных конструкциям BPEL. Также BPML поддерживает рекурсивную композицию, предназначенную для формирования из подпроцессов агрегированных бизнес-процессов.

BPML поддерживает как длительные, так и кратковременные транзакции, используя для управления правилами компенсации понятие контекста, которое аналогично применяемому в BPEL. Разработчики бизнес-процессов могут задействовать вложенные процессы и транзакции. Наконец, обеспечивается надежный механизм обработки исключительных ситуаций.

Оркестровка и хореография совместной работы

BPEL и BPML позволяют определить исполняемый бизнес-процесс, тогда как WSCI ориентирован скорее на взаимодействие и требует, чтобы каждый из его участников определил свой интерфейс WSCI.

Рис. 4. Взаимосвязь стандартов оркестровки и хореографии: языки BPEL4WS, WSCI и BPML

На рис. 4 показан один из вариантов классификации этих спецификаций и стандартов. Протокол совместной работы относится к организации обмена сообщениями между несколькими участниками бизнес-процесса, в то время как исполняемый процесс - это частный поток работ, подконтрольный отдельному участнику.

Язык BPEL поддерживает как исполняемые процессы, так и организацию взаимодействия между ними. BPML и WSCI могут работать вместе так, чтобы BPML моделировал выполнение бизнес-процесса, а WSCI - хореографию Web-сервисов.

Пример

Изготовитель хочет заказать компоненты для производства своего продукта, используя список доступных поставщиков. Для приобретения этих компонентов представитель изготовителя обращается к агенту по закупкам. Тот связывается с поставщиками. После выбора поставщика каждого компонента агент по закупкам посылает покупателю коммерческое предложение. Получив его, последний либо делает заказ, либо отменяет запрос (рис. 5).

Рис. 5. По­сле­до­ва­тель­ность дей­ствий в рас­смат­ри­ва­е­мом сце­на­рии. По­ку­па­тель от­сы­ла­ет аген­ту по снаб­же­нию за­прос на ком­мер­че­ское пред­ло­же­ние. Агент на­прав­ля­ет под­за­про­сы от­дель­ным по­став­щи­кам и со­став­ля­ет ком­мер­че­ское пред­ло­же­ние из их ответов

Каждый из участников процесса имеет описание интерфейсов ввода и вывода на языке WSDL, предоставляемых другим участникам. Кроме приема запроса от покупателя и направления запросов поставщикам агент по закупкам должен обеспечить транзакционную целостность процесса в целом. Скажем, если поставщик не может выполнить запрос из-за отсутствия товара на складе или сбоя в сети поставок, то агент должен отреагировать соответствующим образом, отменив запрос либо обеспечив механизм размещения заказа не в полном объеме.

Для описания оркестрованных процессов в данном примере был выбран язык BPEL, поскольку для него имеются недорогие инструментальные средства и технические руководства, вполне соответствующие потребностям разработчиков.

Первый шаг в описании процесса на BPEL состоит в его определении. Оно начинается с корневого тега process, который именует процесс и перечисляет его ссылки на пространства имен XML. Затем определяются партнеры, участвующие в процессе, и их роли. Три базовые роли - покупатель, агент по закупкам и поставщик - в BPEL можно реализовать с помощью тегов partnerLinks и partnerLink. Агенту по закупкам нужно определить партнерские связи только с покупателем и с поставщиками. Когда покупатель взаимодействует с агентом по закупкам, первый играет роль инициатора запроса, а второй - его получателя. Роли изменяются на противоположные, когда агент взаимодействует с одним из поставщиков.

Процесс также должен управлять информационным потоком между партнерами. Для хранения информации о процессе в BPEL используются переменные. В этом сценарии покупатель делает начальный запрос о закупке. На его основании агент формирует для каждого поставщика запросы о ценах с указанием количества компонентов и их номеров по каталогу. Поставщики присылают информацию о ценах, и агент составляет коммерческое предложение для покупателя. Такое взаимодействие моделируется с помощью четырех переменных. Процесс должен поддерживать корреляцию запросов. Скажем, каждому из ценовых предложений, а также заключительному коммерческому предложению, мы можем назначить уникальные идентификаторы. BPEL описывает их с помощью тега correlationSet. Ключевая часть документа BPEL определяет шаги обработки запроса. Теги sequence и flow определяют, соответственно, последовательное и параллельное выполнение действий, а теги receive, reply и invoke - базовые действия, необходимые для взаимодействия с Web-сервисами при помощи WSDL. Последовательность действий начинается с получения запроса от покупателя. Тег flow выполняет набор параллельных действий, чтобы войти в контакт с каждым поставщиком для получения ценовых предложений по компонентам. Каждое действие ссылается на определенную операцию WSDL и использует указанные переменные для ввода и вывода. После получения ответов от поставщиков агент по закупкам создает сообщение для ответа покупателю. Чтобы извлечь контейнеры поставщиков и сформировать итоговое коммерческое предложение для покупателя, агент может использовать тег assign и язык WSC XPath для ссылок на отдельные части XML-документа.

В заключение рассмотрим обработку исключительных ситуаций в этом сценарии. Например, если при контакте с поставщиком происходит ошибка, агент может послать сообщение покупателю. В BPEL4WS имеются обработчики ошибок для подобных ситуаций. Процесс может нуждаться в обработчиках компенсационных транзакций. Например, если агент не в состоянии связаться с поставщиком, процесс должен предложить способ отмены заказа. Тег scope устанавливает контекст транзакции, группируя взаимосвязанные действия. В данном сценарии в таком контексте могли бы рассматриваться три параллельных обращения к поставщикам.

Для развертывания разработанного процесса нужен механизм оркестровки. На сайтах alphaWorks  и Collaxa предлагаются прекрасные инструментальные средства для разработки, развертывания и выполнения бизнес-процессов, описанных на языках BPEL и WSDL.

Перспективы

В IBM предложили одноранговую модель взаимодействия для электронного бизнеса [5]. Современные Web-сервисы они сравнивают с торговым автоматом - фиксированным набором кнопок, которые нужно нажимать в определенном порядке. Они предлагают диалоговую модель, больше похожую на телефонный разговор, во время которого происходит гибкий обмен информацией между участниками. В настоящее время только технология IBM Conversation Support for Web Services претендует на поддержку этой модели [6].

Еще одна область, которой уделяется большое внимание, - это управление Web-сервисами. Организации нуждаются в сквозной инфраструктуре управления приложениями, системами и сетями, которая придаст гибкость управлению бизнес-процессами с привлечением Web-сервисов, в том числе, управлению отдельными шагами процесса. Устойчивая инфраструктура управления должна обеспечивать контроль за информационной средой, возможности ее адаптации и оптимизации в оперативном режиме.

Потребность в таком управлении растет по мере агрегирования и связывания Web-сервисов, образующих все более сложные бизнес-процессы. Компания Hewlett-Packard представила на рассмотрение консорциуму OASIS свою открытую многофункциональную платформу управления Web-сервисами Web Services Management Framework.

Отрасль положительно воспринимает инициативу BPEL, но пока неясно, какую роль сыграют язык WSCI и группа WS-Choreography. Поддержка производителей программных продуктов и появление соответствующих инструментальных средств существенным образом повлияют на темпы внедрения WSCI.

Литература

1. Computer Sciences Corp. 13th Ann. Critical Issues of IS Management Survey, 2000; www.csc.com/survey.

2. S. Weerawarana, C. Francisco. Business Process with BPEL4WS: Understanding BPEL4WS, Part 1/ research report, IBM developerWorks, Aug. 2002; www-106.ibm.com/developerworks/webservices/library/ws-bpelcoll/.

3. A. Arkin et al. Web Service Choreography Interface 1.0, 2002; www.sun.com/software/xml/developers/ wsci/wsci-spec-10.pdf.

4. R. Shapiro. A Comparison of XPDL, BPML and BPEL4WS/ draft document, Cape Visions, May 2002; xml.coverpages.org/Shapiro-XPDL.pdf.

5. J.E. Hanson, P. Nandi, D. Levine. Conversation-Enabled Web Services for Agents and e-Business/ Proc. Intl. Conf. Internet Computing, Computer Science Research, Education and Applications (CSREA) Press, 2002.

6. S. Kumaran, P. Nandi. Conversational Support for Web Services: The Next Stage of Web Services Abstraction/ research report, IBM developerWorks, Sept. 2002; www-106.ibm.developerworks/webservices/library/ws-conver/.

Крис Пелц (chris.peltz@hp.com) - старший консультант по программному обеспечению Hewlett-Packard Developer Resources Organization (devresource.hp.com).

Chris Peltz, Web Services Orchestration and Choreography, IEEE COMPUTER, October 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.