zabika.ru 1

Для объединения 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 получение запроса, вызов и ответ являются базовыми действиями процесса.

Структурные действия управляют потоком работ бизнес-процесса в целом, определяя последовательность вызова 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 (www.BPMI.org) по заказу 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).

Каждый из участников процесса имеет описание интерфейсов ввода и вывода на языке 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 устанавливает контекст транзакции, группируя взаимосвязанные действия. В данном сценарии в таком контексте могли бы рассматриваться три параллельных обращения к поставщикам.

Для развертывания разработанного процесса нужен механизм оркестровки. На сайтах IBM alphaWorks (www.alphaworks.ibm.com) и Collaxa (www.collaxa.com) предлагаются прекрасные инструментальные средства для разработки, развертывания и выполнения бизнес-процессов, описанных на языках 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). Консультирует клиентов по техническим и архитектурным вопросам платформы J2EE и Web-решений.

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