Автоматизация бизнес-процессов с помощью BPEL

--> Дата: Фев 18, 2008 287

Андрей Колесов

Одно из главных направлений развития современных информационных систем масштаба предприятия связано с концепцией сервис-ориентированной архитектуры (services-oriented architecture, SOA). Отметим, что сама по себе идея компонентного построения распределенных компьютерных систем, в которых можно было бы использовать те или иные вычислительные и информационные ресурсы по мере их реальной необходимости, совсем не нова. По большому счету, таков изначально был один из основополагающих принципов применения ИТ с момента создания первых ЭВМ, еще 50 лет назад.

Если вспомнить о диалектическом развитии истории по спирали, то качественно новым элементом идеи SOA стала ориентация на применение появившихся относительно недавно технологий, позволяющих создавать распределенные системы на базе Web-сервисов. В несколько упрощенном виде новизна Web Services заключается в использовании Интернет-технологий на базе открытых отраслевых стандартов, что, в свою очередь, позволяет создавать гетерогенные (платформно независимые), масштабируемые (от локальных до глобальных) решения.

Набор технологий Web Services

Web Services вполне допустимо назвать технологиями XXI века – за точку отсчета их истории, хотя и с некоторой долей условности, можно принять 2000 г. Именно тогда в специализированной прессе стали появляться названия первых WS-стандартов: SOAP (Simple Object Access Protocol) для обмена данными между приложениями, WSDL (Web Services Description Language) для описания программных интерфейсов сервисов и UDDI (Universal Description Discovery & Integration) для хранения и получения WSDL-описаний. Этих стандартов вполне хватает для создания несложных распределенных решений, но явно недостаточно для построения корпоративных систем. Именно потому наряду с модернизацией базовых стандартов стали появляться специализированные технологии для решения таких задач, как гарантированная доставка сообщений, шифрование и обеспечение безопасности, управление транзакциями и т. п. Все они реализованы на основе XML.

В результате к сегодняшнему моменту сложилась целая система WS-стандартов (один из вариантов ее структуры представлен на рис. 1). Анализ этих стандартов, которых уже сейчас насчитывается несколько десятков, не входит в задачу настоящей статьи*. Отметим только, что подавляющее большинство этих стандартов существуют лишь на бумаге и пока не поддерживаются в программных продуктах. Более того, здесь наблюдается неприятная тенденция – создание конкурирующих между собой спецификаций, подготовкой которых занимаются две группировки ИТ-компаний: одна во главе с IBM и Microsoft и другая, возглавляемая Sun Microsystems и Oracle.

* Подробный обзор WS-стандартов можно найти в PC Week/RE NN 27-35/2004 (http://www.pcweek.ru).

Рис. 1. Структура стандартов и спецификаций Web Services.

Как видно из рис. 1, основу структуры WS-технологий составляет все та же базовая тройка – SOAP, WSDL, UDDI, которой пока, к счастью, не коснулась конкурентная борьба ИТ-вендоров. Над ними располагаются слои "Безопасность", "Обмен сообщениями", "Управление контекстом", "Координация", "Управление транзакциями". Выше находятся еще два слоя – "Оркестровка" (Orchestration) и "Хореография" (Choreography). Первый из них стали использовать в лексиконе WS-технологий еще 4-5 лет назад для обозначения задач управления бизнес-процессами. Второй появился относительно недавно и также относится к проблематике автоматизации процессов, но акцент при этом делается на интеграцию разнородных приложений.

Для решения задач "оркестровки" и "хореографии" также разработан целый набор стандартов. На лидирующие позиции в этой сфере сейчас претендует в первую очередь Business Process Execution Language for Web Services (язык исполнения бизнес-процессов для Web-сервисов), обозначаемый как BPEL4WS, или просто BPEL. Разработкой этого стандарта занимались специалисты группы ИТ-компаний, ведущую роль в которой играли IBM и Microsoft. Более того, BPEL фактически стал прямым наследником ранее созданных спецификаций IBM WSFL и Microsoft XLANG. В нем используются сразу несколько XML-спецификаций – WSDL 1.1, XML Schema 1.0, XPath 1.0.

Первый вариант BPEL был представлен два года назад и в марте 2003 г. был утвержден OASIS (Organization for the Advancement of Structured Information Standards, организация по продвижению стандартов в области структурированной информации). Весной 2004 г. появилась версия BPEL 1.1. Эта спецификация была впервые реализована в продуктах IBM WebSphere Business Integration Server Foundation 5.1 и Microsoft BizTalk Server 2004. Кроме того, поддержка BPEL обеспечивается в ряде ведущих платформ исполнения приложений и сервисов (например, SAP NetWeaver и BEA WebLogic).

Говоря о BPEL, нужно упомянуть и о еще двух стандартах, также разработанных совместными усилиями IBM и Microsoft, – WS-Coordination и WS-Transaction. Данные спецификации дополняют возможности BPEL при автоматизации сложных и длительных по времени бизнес-транзакций.

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

На самом же деле BPEL – это достаточно простой в изучении, но вполне мощный язык, реализованный на базе XML, позволяющий определить последовательность выполнения функционала Web-сервисов в ходе различных потоков операций (транзакций). И здесь наиболее важен тот факт, что BPEL поддерживают ведущие поставщики ПО, предлагающие BPEL-совместимые продукты. И пусть число пользователей этих продуктов пока не слишком велико, но можно ожидать, что оно будет очень быстро расти.

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

Примеры применения BPEL

Для иллюстрации возможностей BPEL рассмотрим пару простых примеров.

Предположим, что есть некоторый онлайновый продавец антиквариата. Когда он через свой Web-сайт получает запрос на покупку, ему необходимо запустить процессы для автоматического определения кредитоспособности клиента и поиска у оптовых торговцев нужного товара по наименьшей цене. Для этого программа должна отправить запрос в соответствующую учетную систему и в целый ряд профильных электронных магазинов, например, в Amazon и eBay, у которых есть общедоступные интерфейсы Web-сервисов. После получения ответной информации выбирается вариант с наименьшей ценой. Диаграмма этого бизнес-процесса определения стоимости товара приведена на рис. 2. Разумеется, за ним может следовать автоматическое продолжение – заказ товара, отправка его покупателю и т. д.

Рис. 2. Простой пример процесса показывает возможности внутреннего и внешнего использования Web-сервисов.

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

Каждая операция (invoke), представленная на диаграмме прямоугольным блоком, описывается простой BPEL-структурой, которая включает элементы, соответствующие таким действиям, как отправка запроса, ожидание, получение ответа и т. д. Например, операция запроса о кредитоспособности (которая может выполняться в синхронном или асинхронном режимах – переход к последующим действиям с ожиданием или без ожидания ответа) может описываться примерно следующим образом:

<!-пример генерации кода BPEL-->
<invoke name="invoke-1" 
    partnerLink="AccountingDept"
  portType="services:CreditRatingService"
  operation="process" inputVariable="crIn"
  outputVariable="crOut">
</invoke>

Как видно, этот код реализован на базе синтаксиса XML. Более того, BPEL может работать с различными другими XML-средствами, такими, как XSLT, XQuery and XPath. Полный вариант BPEL-файла для процесса определения цены должен, конечно, содержать также соответствующие блоки взаимодействия с Web-сервисами торговых партнеров и код логики выполнения переходов и простейших вычислительных операций (например, выбора наименьшей цены). Дополненный WSDL-файлами (для описания внешних Web-сервисов), он будет представлять собой законченную программу "оркестровки" Web-сервисами.

Рассмотрим еще один пример использования BPEL при решении довольно обычной задачи: транспортное агентство получает от клиента запрос на приобретение билетов по некоторому маршруту, заказывает билеты в авиакомпании и получает их от нее (для упрощения примера мы не рассматриваем последующие действия – оплату билетов, доставку их клиенту и т. д.). Потоковая диаграмма действий такого бизнес-процесса представлена на рис. 3, а в листинге содержится соответствующий программный код, демонстрирующий основные элементы BPEL.

Рис. 3. Бизнес-процесс заказа авиабилетов.

Программа начинается с описания бизнес-процесса, названного ticketOrder (тег ). Далее идет блок описания партнеров, участвующих в этом процессе (ограниченный тегом ). В данном случае их два – клиент (customer) и авиакомпания (airline). Для подключения партнеров к процессу служит двусторонний указатель, называемый service link type и содержащий две коллекции Web-сервисов, ссылки на которые выполняются с помощью ролей. В частности, указатель buyerLink включает две роли, в каждой из которых имеется описание соответствующего порта:

<serviceLinkType name="buyerLink">
  <role name="ticketRequester">
    <portType name="itineraryPT"/>
  </role>
  <role name="ticketService">
    <portType name="ticketOrderPT"/>
  </role>
</serviceLinkType>

Соответственно партнер airline, который использует описание buyerLink, указывает две роли: для владельца процесса (myRole) и внешнего партнера (partnerRole).

Описание WSDL-сообщений, отправляемых между Web-сервисами, приведено в блоке, ограниченном тегами

<containers>.

Эта информация будет использоваться в последующем коде.

Логика самого бизнес-процесса, который состоит из операций, называемых действиями (activity), заключена внутри тегов

<flow>.

В начале этого блока находятся конструкции, называемые links, которые указывают направления связей при выполнении последующих операций.

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

<receive> и <invoke>.

Первая, receive – это просто ожидание получения сообщения от партнера. Как видно из листинга, выполнение процесса начинается с ожидания получения запроса от клиента, при этом используется сообщение типа itineraryMessage, приведенное в контейнере itinerary. Более мощный вариант такого действия может быть представлен тегом

<pick>,

который позволяет принимать целый набор сообщений от нескольких партнеров.

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

BPEL-описание бизнес-процесса приобретения авиабилета

<process name="ticketOrder">
  <partners>
    <partner name="customer" 
       serviceLinkType="agentLink"
       myRole="agentService"/>
    <partner name="airline" 
       serviceLinkType="buyerLink"
       myRole="ticketRequester"
       partnerRole="ticketService"/>
  </partners>
  <containers>
     <container name="itinerary" 
      messageType="itineraryMessage"/>
     <container name="tickets" 
      messageType="ticketsMessage"/>
  </containers>
  <flow>
    <links>
      <link name="order-to-airline"/>
      <link name="airline-to-agent"/>
    </links>
    <receive partner="customer" 
      portType="itineraryPT" 
      operation="sendItinerary" 
      container="itinerary" 
      <source 
        linkName"order-to-airline"/>
    </receive>
    <invoke partner="airline" 
      portType="ticketOrderPT" 
      operation="requestTickets"
      inputContainer="itinerary" 
      <target 
       linkName"order-to-airline"/>
      <source 
       linkName"airline-to-agent"/>
    </invoke>
    <receive  partner="airline" 
      portType="itineraryPT" 
      operation="sendTickets"
      container="tickets" 
      <target 
       linkName"airline-to-agent"/>
    </receive>
  </flow>
</process>

Создание BPEL-решений

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

Создаваемые с помощью BPEL приложения относятся к категории "процессно-ориентированных" (process-based applications). Фактически они состоят из двух отдельных слоев исполнения. Верхний слой описывает бизнес-логику процесса, представленную на языке BPEL, нижний слой выполняет собственно все функциональные операции с помощью различных Web-сервисов. BPEL-приложение может выполняться на любом сервере приложений, имеющем механизм исполнения BPEL.

Развитые инструменты позволяют визуально проектировать полнофункциональные BPEL-приложения, не требуя написания кода вручную. Эти средства, кроме того, включают функции автономного тестирования программы. Однако для работы в реальных условиях под управлением BPEL-сервера требуются правильные установки для всех используемых Web-сервисов в WSDL-файлах, а также конфигурирование необходимых коммуникационных протоколов (например, Java Message Service или HTTP).

Отдельно стоит упомянуть о возможности преобразования моделей UML (Unified Modeling Language) в наборы BPEL и WSDL-файлов. Такие инструменты уже появились на рынке; в качестве примера можно привести средство Emerging Technologies Toolkit 1.1 корпорации IBM.