Журнал об электронном контенте, документах и бизнес-процессах
Учебники Просто о СЭД ЭП/ЭЦП Внешний документооборот Цифровая трансформация Эксперты
Workflow и управление бизнес-процессами

Автоматизация бизнес-процессов с помощью BPEL (Business Process Execution Language)

  2 комментариев Добавить в закладки

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

Одно из главных направлений развития современных информационных систем масштаба предприятия связано с концепцией сервис-ориентированной архитектуры (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.

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

Рис. 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-сервисов.

Рис. 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. Бизнес-процесс заказа авиабилетов.

Рис. 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.

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

Источник: BYTE/Россия

Ещё материалы автора
Похожие записи
Комментарии (2)
Александр Саблин 24 января 2008 г. 07:05  

Для ECM очень важно иметь возможность импортировать БП в любом формате BPM из описания UML (ISO 19501). Как правило БП сперва оптимизируются, а зетем переносятся в среду BPM. Очень важно при этом использовать стандарты XMI (ISO 19503). В серьезных ECM созданы интерфейсы к продуктам управления данными по стандарту UML. БП, описанный в UML преобразуется в тот же BPEL и загружается в ECM. Чтобы блоки БП были синхронизированы с сервисами SOA, необходимо разработать схему соответствия тегов и их преобразований в структуры SOA средствамb XSLT.

Михаил Романов 24 января 2008 г. 09:26  

Для ECM очень важно иметь возможность импортировать БП в любом формате BPM из описания UML

А для чего это нужно. Что дает UML в части описания БП, по сравнению с тем же BPML(BPNL)? Если честно, UML даже по основному назначению - для описания программных систем применяют не слишком часто (точнее применяют, но только отдельные виды диаграмм - чаще всего классов и взаимодействия), и все из-за довольно большой сложности полного описания UML. А BPML, специально проектировался так, чтобы быть максимально простым.

... В серьезных ECM созданы интерфейсы к продуктам управления данными по стандарту UML

Это как? Какие такие продукты управления данными и зачем там интерфейсы по стандарту UML (и по какому стандарту)?

... Чтобы блоки БП были синхронизированы с сервисами SOA, необходимо разработать схему соответствия тегов и их преобразований в структуры SOA средствамb XSLT

Как показывает практика, необходимость в такого рода низкоуровневых вещах возникает крайне редко. Большинство сервисных платформ, с которыми мне приходилось сталкиваться, оперируют структурами данных платформы (или, если угодно используемого языка разработки). Так что спускаться до XML (транспорта) практически никогда не приходится.

Когда XSLT может реально пригодится, так это при передаче больших пакетов данных между принципиально разными ситемами. Но опять-таки, есть множество визуальных средств описания шаблонов преобразования. Например, вполне пристойный редактор преобразований есть в BizTalk, для большинства задач его возможностей хватает с лихвой.

А что значит "блоки синхронизированы с сервисами"? В каком смысле синхронизированы?
 

Сейчас обсуждают
Больше комментариев