Язык BPEL предназначен для интеграции систем автоматизации в рамках общих бизнес процессов. Он используется при создании новых масштабных систем автоматизации, охватывающих несколько предприятий или подразделений холдинга. При этом необязательно, чтобы все участники использовали общую платформу интеграции, поскольку BPEL ориентирован на взаимодействие разнородных платформ и приложений.
Бизнес-процесс, выраженный средствами языка BPEL, называют BPEL-процессом.
BPEL-процесс задает порядок исполнения задействованных Web-сервисов (возможны последовательное или параллельное выполнение). Собственно BPEL-процесс инициируется получением запроса на выполнение некоторых действий.
Разработка BPEL-процесса начинается с ознакомления с Web-сервисами, участвующими в описываемом бизнес-процессе. Эти сервисы называются partner Web services (партнерские Web-сервисы).
Затем создается WSDL-описание BPEL-процесса. При этом указываются требуемые пространства имен (namespaces). Типы партнерских связей определены в WSDL-описании в пространстве имен http://schemas.xmlsoap.org/ws/2003/05/partner-link/.
Далее в создаваемом BPEL-процессе нужно указать типы партнерских связей, т.е. описать взаимодействие между BPEL-процессом, клиентом, который вызывает BPEL-процесс, и вовлеченными Web-сервисами. При этом определяются роли связей: для синхронных связей роль одна, для асинхронных роли две. В асинхронных операциях первая роль описывает вызов операции клиентом, вторая роль — вызов возвращения.
BPEL-процесс имеет следующую структуру::
Другими словами, структура имеет вид:
<process name=". . ." ... >
   <partnerLinks>
      <! -- Определение партнерских связей -->
   </partnerLinks>
   <variables>
      <!-- Определение переменных -->
   </variables>
   <sequence>
      <!-- Определение основной части BPEL бизнес-процесса -->
   </sequence>
</process>
В элементе <partnerLinks> каждая партнерская связь соотносится с определенным типом partnerLinkType, который характеризует ее. Каждая партнерская связь также специфицирует один или два атрибута.
Переменные (Variables) в BPEL-процессах используются, чтобы хранить, повторно форматировать и преобразовывать сообщения.
Основная часть BPEL-процесса определяет порядок, в котором вызываются партнерские Web-сервисы. Обычно старт начинается с тега <sequence>, который определяет несколько действий, которые будут выполнены последовательно. В этой последовательности надо сначала определить входное сообщение, которое запускает бизнес-процесс. Это делается с помощью тега <receive>, который ждет соответствующего сообщения. После получения сообщения BPEL-процесс выполняет остальные действия.
Перед описанием процесса на BPEL полезно предварительно отобразить его в виде диаграмм активности UML. Пример такой диаграммы для процесса покупки книги взят из [1] и представлен на рис. 1. Этот процесс является асинхронным и включает в себя обращения к трем Web-сервисам. Сначала используется Web-сервис оценки полезности книги. Этот Web-сервис вызывается синхронно и возвращает значение рейтинга книги. Затем процесс запрашивает цену книги в двух книжных магазинах. Для этого асинхронно вызываются два идентичных Web-сервиса этих книжных магазинов. Затем процесс выбирает более дешевую книгу и асинхронно производит закупку.
Примечание 1
Под синхронизмом связи подразумевается приостановка процесса до получения ответа (как в RPC).
Для асинхронных связей клиенту требуются два потока для вызова службы: один — для передачи запроса, второй – для приема ответа (и соответственно в BPEL-процессе два типа портов: один для клиентских запросов, другой – для исполнения BPEL-процессом возврата к клиенту). Брокер, предоставляющий возможность потребителю вызывать Web-службу асинхронно, реализуется при помощи системы обмена сообщениями, которая использует очереди сообщений для передачи запроса и получения ответа.
Рис. 1.  UML-диаграмма для BPEL-процесса
Рассмотрим примеры моделей бизнес-процессов на языке BPEL.
Пример 1
Определение одного из двух возможных банков для получения займа [2].
Первое действие <receive>- запрос Web-сервиса для оценки заявки на заем. Следующее действие <assign> — приведение данных о клиенте к формату, совместимому с сервисом каждого банка. Сервисы обоих банков вызываются параллельно (действие <flow>, содержащее действия <invoke>). Оценки от каждого банка возвращаются (<receive>) бизнес-процессу получения займа, где сравниваются для выбора наилучшей ставки (действия <case> и <switch>, аналогичные конструкции if-then-else в языках программирования). Значение наилучшей ставки присваивается переменной для возврата (действие <assign>). Результат посылается источнику вызова (действие <invoke>).
Пример 2
Пример описания партнерской связи, ее ролей и портов [1]:
<plnk:partnerLinkType name="travelLT">
  <plnk:role name="travelService">
    <plnk:portType name="tns:TravelApprovalPT" />
  </plnk:role>
  <plnk:role name="travelServiceCustomer">
    <plnk:portType name="tns:ClientCallbackPT" />
</plnk:role>
</plnk:partnerLinkType>
Пример структуры описания переменных:
   <variables>
      <!-- input for BPEL process  -->
      <variable name=". . ."
                messageType=". . ."/>
      <!-- input for  service S1-->
      <variable name=". . ."
                messageType=". . ."/>
      <!-- output from service S1-->
      <variable name=". . ."
                messageType=". . ."/>
      <!-- input service S2 -->
      <variable name=". . ."
                messageType=". . ."/>
      <!-- output from service S2 -->
      <variable name=". . ."
                messageType=". . ."/>
      <!-- output from BPEL process -->
      <variable name=". . ."
                messageType="..."/>
   </variables>
Пример структуры начала основной части:
<sequence>
      <receive partnerLink="client"
               portType=". . ."
               operation=". . ."
               variable=". . ."
               createInstance="yes" />
...
Приводимые далее примеры [3] относятся к фрагментам процессов Workflow.
Пример 3
. Два узла “A” и “B” соединены последовательно. После выполнения действия узла “A” управление переходит узлу “B”.
BPEL модель без использования конструкции “Link”:
<process name=”PatternSequence”…>
<sequence>
<receive … operation=”operation A” …>
</receive >
< receive … operation=”operation B” …>
</receive >
</sequence>
</process>
BPEL-модель с использованием конструкции “Link”:
<process name=”PatternSequence”…>
<flow>
<links>
<link name=”FromAtoB”>
</links>
<receive … operation=”operation A” …>
<source linkName=”FromAtoB/>
</receive >
< receive … operation=”operation B” …>
<target linkName=”FromAtoB/>
</receive >
</flow>
</process>
Пример 4
Связка паттернов “исключающий выбор” и “простое соединение”. Управление находится в узле “A”, далее управление переходит либо в узел “B”, либо в узел “C”, в зависимости от выполнения некоторого условия, далее из любого из этих узлов управление переходит в узел “D”:
<process name=”PatternsExclusiveChoiceSimpleMerge”…>
<sequence>
<receive … operation=”operation A” …>
</receive >
<switch…>
<case condition=…>
<receive … operation=”operation B” …>
</receive >
</case>
<case condition= …>
<receive … operation=”operation C” …>
</receive >
</case>
</switch…>
< receive … operation=”operation D” …>
</receive >
</sequence>
</process>
С использованием конструкции link:
<process name=” PatternsExclusiveChoiceSimpleMergeWithLink”…>
<flow>
<links>
<link name=”FromAtoB”>
<link name=”FromAtoC”>
<link name=”FromBtoD”>
<link name=”FromCtoD”>
</links>
<receive … operation=”operation A” …>
<source linkName=”FromAtoB transitionCondition=”…”/>
<source linkName=”FromAtoC transitionCondition=”…”/>
</receive >
<receive … operation=”operation B” …>
<target linkName=”FromAtoB/>
<source linkName=”FromBtoD/>
</receive >
<receive … operation=”operation C” …>
<target linkName=”FromAtoC/>
<source linkName=”FromCtoD/>
</receive >
< receive … operation=”operation D” …>
<target linkName=”FromBtoD/>
<target linkName=”FromCtoD/>
</receive >
</flow>
</process>
Пример 5
Управление находится в узле “A”, после того, как выполнено действие узла A, поток управления распадается на два параллельных потока управления. Первый поток управления переходит в узел “B”, одновременно второй поток управления переходит в узел “C”. После выполнения Действий узлов “B” и “C” потоки управления сливаются в один, и этот поток управления переходит в узел “D”:
<process name=”PatternsParallelSplitSynchronization”…>
<sequence>
<receive … operation=”operation A” …>
</receive >
<flow>
<receive … operation=”operation B” …>
</receive >
<receive … operation=”operation C” …>
</receive >
</flow>
< receive … operation=”operation D” …>
</receive >
</sequence>
</process>
Пример 6
Управление находится в узле “A”. После того, как выполнено Действие узла “A”, происходит итеративный процесс. Проверяется условие. Если оно истинно, то управление переходит в узел “B”, а после выполнения действия узла “B” — в узел “C”. Далее итерации повторяются до тех пор, пока условие не станет ложным. После этого поток управления переходит в узел “D”.
<process name=” RegularCycle”…>
<sequence>
<receive … operation=”operation A” …>
</receive >
<while condition= … >
<receive … operation=”operation B” …>
</receive >
<receive … operation=”operation C” …>
</receive >
</while>
< receive … operation=”operation D” …>
</receive >
</sequence>
</process>
Список литературы
1. http://www.citforum.ru/internet/webservice/weav_web/
2. Matjaz Juric. A Hands-on Introduction to BPEL. — http://www.oracle.com/technology/pub/articles/matjaz_bpel1.html
3. А.Михеев, М.Орлов. Обзор – Перспективы WorkFlow-систем. Применение WF- паттернов для сравнения WF-языков. — http://wf.runa.ru/images/9/93/Article04_examples.pdf