Пример BPEL-документа.

Рис. 6.3. Пример структуры бизнес процесса

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

Структура данного бизнес процесса показана на рис. 6.3. Бизнес-процесс представляет собой сервис, реализующий асинхронный режим функционирования. Менеджер представлен синхронным сервисом, работающим по принципу запрос-ответ. Компания А и Компания В представлены асинхронными сервисами.

Функционирование сервиса выглядит следующим образом. Когда сотруднику потребуется заказать оборудование, он запускает клиентское приложение, которое может быть, например, портлетом и вводит информацию о необходимом оборудовании и отсылает запрос. Клиентское приложение формирует асинхронный запрос к основному сервису, который назовем Сервисом Закупки (PurchaseService). После этого формируется синхронный запрос к сервису Менеджер (ManagerService), который возвращает послание, в котором содержится разрешение на покупку оборудования. В качестве Менеджера может выступать либо приложение, которое может, например, обратиться к базе данных с проверкой наличия средств на счете подразделения, либо Менеджером может быть реальный человек. В последнем случае на портале менеджера появляется информация о том, что на его имя пришел запрос. В последнем случае Менеджер открывает соответствующий портлет и заполняет требуемые поля. Если Менеджер не дает разрешения, то вызывается активность типа terminate.

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

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

Разработка BPEL-процесса обычно включает в себя следующие этапы:

· определение веб-сервисов, участвующих в разрабатываемом BPEL-процессе;

· разработка WSDL-описания BPEL-процесса;

· определение партнерских связей;

· декларирование переменных;

· разработки логики процесса.

Определение партнерских связей (partner Web services). В рассматриваемом примере бизнес-процесс работает с тремя сервисами:

- Менеджер (ManagerService);

- Компания А (CompanyAService);

- Компания В (CompanyBService).

Веб-сервис Менеджер (ManagerService) имеет порт типа EquipmentPurchcePT, через который при помощи операции GetPermission может быть получено разрешение на покупку. Операция возвращает разрешение или отказ в виде строки символов. Данный сервис является синхронным. Запрос помещается в сообщение PermissionRequestMessege, а ответ в сообщение типа PermissionResponseMessege.

Веб-сервис Компания А (CompanyAService)является асинхронным; поэтому он определяет два типа портов: первый – это PriceListАPT, который использует операцию GetPrice для проверки наличия оборудования и цены. Для возврата результата веб-сервис определяет отдельный порт типа - CompanyACallbackPT. Этот тип порта определяет операцию CompanyACallback. Для пересылки результата используется сообщение типа PriceResponseMessage.

Веб-сервис Компания B (CompanyBService)такжеявляется асинхронным; поэтому он определяет два типа портов: первый – это PriceListВPT, который использует операцию GetPrice для проверки наличия оборудования и цены. Для возврата результата веб-сервис определяет отдельный порт типа - CompanyBCallbackPT. Этот тип порта определяет операцию CompanyBCallback. Для пересылки результата используется сообщение типа PriceResponseMessage.

Хотя веб-сервисы Компания А и Компания В определяет по два типа портов, они реализует только по одному порту (PriceListАPT и PriceListВPT), а порты CompanyACallbackPT и CompanyВCallbackPT реализуется BPEL-процессом, который является клиентом этого веб-сервиса.

Затем необходимо представить сам процесс приобретения оборудования как веб-сервис, что можно сделать посредством составления его WSDL-описания.

Процесс имеет порт типа PurchaseEquipmentPT. Для обращения к порту используется операция BuyEquipment исообщение формата BuyEquipmentRequestMessage.

Кроме того, на стороне клиента должен иметься порт ClientCallbackPT, в который отправляется клиенту ответ, содержащий результаты обработки запроса. Для этого используется операция SendPurchaseInfo и сообщение типа BuyEquipmentResponseMessage.

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

- purchaseLT - используется для описания асинхронного взаимодействия между клиентом и собственно BPEL-процессом и определяется WSDL-описанием BPEL-процесса;

· managerLT - используется для описания синхронного взаимодействия между BPEL-процессом и веб-сервисом «ManagerService»;

· companyALT - описывает асинхронное взаимодействие между BPEL-процессом и веб-сервисом «Компания А». Этот тип партнерской связи определен в WSDL веб-сервиса «CompanyAService»;

· companyBLT - описывает асинхронное взаимодействие между BPEL-процессом и веб-сервисом «Компания B». Этот тип партнерской связи определен в WSDL веб-сервиса «CompanyBService».

За партнерской связью закрепляется одна или две роли. Для синхронных операций определяется одна роль, а для асинхронной – две роли.

Для асинхронных операций первая роль описывает вызов операции клиентом, а вторая роль описывает процесс возвращения ответа на запрос, который обычно называют обратным вызовом (callback).

Типы партнерских связей определяются в WSDL-описании в специальном пространстве имен (namespace).

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

<plnk:partnerLinkType name="purchaseLT">

<plnk:role name="purchaseService">

<plnk:portType name="tns: PurchaseEquipmentPT" />

</plnk:role>

<plnk:role name="purchaseServiceCustomer">

<plnk:portType name="tns:ClientCallbackPT" />

</plnk:role>

</plnk:partnerLinkType>

Второй тип связи – managerLT используется для описания синхронной связи между BPEL-процессом и веб-сервисом «Менеджер» и определяется в WSDL-описании веб-сервиса менеджера. Поскольку взаимодействие синхронно, то только одна роль:

<plnk:partnerLinkType name="managerLT">

<plnk:role name="purchasePermissionService">

<plnk:portType name="tns:EquipmentPurchacePT" />

</plnk:role>

</plnk:partnerLinkType>

Оставшиеся типы партнерских связей, companyALT и companyBLT, используются для описания асинхронных связей между BPEL-процессом и веб-сервисами «Компания А» и «Компания В». Для Компании А описание имеет вид:

<plnk:partnerLinkType name="companyALT">

<plnk:role name="purchaseAService">

<plnk:portType name="tns:PriceListАPT" />

</plnk:role>

<plnk:role name="equipmentCustomer">

<plnk:portType name="tns:CompanyACallbackPT" />

</plnk:role>

</plnk:partnerLinkType>

Для Компании В описание аналогично.

Создание бизнес-процесса. BPEL-процесс работает следующим образом. BPEL-процесс запускается при поступлении входного сообщения от клиента. После этого происходит вызов сервиса Менеджер. Это синхронный вызов, поэтому выполнение процесса приостанавливается до получения ответа. После того как ответ получен, посылаются запросы к Веб-сервисам Компании А и Компании В. Это асинхронные вызовы, которые выполняются параллельно. После того как ответы, содержащие информацию о стоимости требуемого оборудования, полученные предложения сравниваются по цене в рамках бизнес процесса и выбирается лучшее предложение. Затем информация о выборе передается служащему.

Рассмотренный выше алгоритм описывается в блоке, заключенном в теги <sequence> </sequence>, в котором содержится описание последовательности действий.

Однако перед тем как описывать последовательность действий требуется определить переменные.

Переменные (Variables). Переменные в BPEL-процессах используются для хранения и повторного использования значений, полученных в от сервисов.

Для работы с сообщениями используется XPath.

В рассматриваемом примере используются следующие переменные:

· EquipmentRequest;

· PermissionRequest;

· PermissionResponse;

· EquipmentDetails;

· АResponse;

· ВResponse;

· Response2employer.

Для каждой переменной требуется определить ее тип. При определении переменных можно использовать типы, используемые в WSDL описаниях, а также простые типы XML Schema. В рассматриваемом примере использованы для всех переменных типы WSDL-сообщений:

<variables>

<!—входные данные для бизнес процесса -->

<variable name="EquipmentRequest"

messageType="prch: BuyEquipmentRequestMessage"/>

<!—входные данные для запроса о разрешении приобретения оборудования -->

<variable name="PermissionRequest"

messageType="prch:PermissionRequestMessage"/>

<!—выходные данные от менеджера -->

<variable name="PermissionResponse"

messageType="prch: PermissionResponseMessage"/>

 

<!—входные данные для компании А -->

<variable name=" EquipmentDetails"

messageType="cmp: PriceRequestMessage"/>

<!—выходные данные от компании А -->

<variable name=" АResponse"

messageType=" cmp: PriceResponseMessege"/>

 

<!—входные данные для компании В -->

<variable name=" EquipmentDetails"

messageType="cmp: PriceRequestMessage"/>

<!—выходные данные от компании В -->

<variable name=" BResponse"

messageType=" cmp: PriceResponseMessege"/>

<!-- выходные данные от BPEL процесса -->

<variable name="Response2employer"

messageType="cmp: BuyEquipmentResponseMessage"/>

</variables>

Основная часть BPEL-процесса. Основная часть BPEL-процесса заключена в теги<sequence> и описывает порядок, в котором вызываются партнерские веб-сервисы. Запуск BPEL-процесса происходит при поступлении в порт PurchaseEquipmentPT сообщения типа BuyEquipmentRequestMessage. Параметры запроса сохраняются в переменной EquipmentRequest:

<sequence>

 

<!—Получение от клиента запроса на приобретение оборудования -->

<receive partnerLink="purchaseLT"

portType="prch:PurchaseEquipmentPT"

operation="BuyEquipment"

variable="EquipmentRequest"

createInstance="yes" />

...

<receive> ожидает когда клиент вызовет операцию BuyEquipment и сохраняет параметры запроса в переменной EquipmentRequest. Строка createInstance="yes" указывает на то, что треуется создать новый экземпляр бизнес процесса.

Далее требуется вызвать сервис Менеджер. Для этого требуется сформировать для него входное сообщение посредством копирования части сведений о требуемом оборудовании:

...

<!—Подготовка входного сообщения для менеджера -->

<assign>

<copy>

<from variable="EquipmentRequest" part="EquipmentType"/>

<to variable="PermissionRequest" part=" EquipmentType"/>

</copy>

</assign>

...

Теперь может быть вызван сервис ManagerService. Для этого используется <invoke>. Применяется партнерская связь managerLT и вызывается операция GetPermission и осуществляется обращение к порту типу EquipmentPerchasePermissionPT. Поскольку это синхронное обращение, то запрос ждет ответа, который сохраняется в переменной PermissionResponse:

...

<!— синхронное обращение к менеджеру для получения разрешения -->

<invoke partnerLink="managerLT"

portType="prch:EquipmentPurchasePermissionPT"

operation="GetPermission"

inputVariable="PermissionRequest"

outputVariable="PermissionResponse" />

...

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

...

<!—Подготовка запроса к сервисам компаний -->

<assign>

<copy>

<from variable="PermissionResponse" part="EquipmentType"/>

<to variable=" EquipmentDetails" part="EquipmentType"/>

</copy>

</assign>

...

Входные данные включают сведения, которые требуются веб-сервисам компаний. Поскольку они заданы в одном и том же формате, их можно передать непосредственно (используя простую копию). В реальной же ситуации обычно необходимо выполнить преобразование. Это можно было бы сделать, использовав либо XPath с выражением <assign>, либо сервис преобразования (типа механизма XSLT), либо возможность преобразования, обеспеченную определенными BPEL-серверами.

Теперь можно вызывать веб-сервисы компаний поставщиков. Для параллельного вызова сервисов применяется активность <flow>. Оба сервиса асинхронные и поэтому реализуются активность <invoke> и активность <receive>.

Результаты, полученные от компаний, сохраняются в переменных

AResponse и BResponse соответственно:

...

<!—Параллельное обращения к сервисам компаний -->

<flow>

 

<sequence>

<! --Асинхронный вызов Web-сервиса Компании А и ожидание ответа -->

 

<invoke partnerLink="CompanyALT"

portType="spl:PriceListAPT"

operation="GetPrice"

inputVariable="EquipmentDetails" />

 

<receive partnerLink="CompanyALT"

portType="spl:FlightCallbackPT"

operation="CompanyACallback"

variable="AResponse" />

 

</sequence>

 

<sequence>

<!-- Асинхронный вызов Web-сервиса Компании B и ожидание ответа -->

<invoke partnerLink=" CompanyBLT"

portType="spl:PriceListAPT"

operation="GetPrice"

inputVariable="EquipmentDetails" />

 

<receive partnerLink=" CompanyBLT"

portType="spl:FlightCallbackPT"

operation=" CompanyBCallback"

variable="BResponse" />

 

</sequence>

 

</flow>

...

На следующем шаге осуществляется выбор лучшего по стоимости предложения посредством использования активности <switch>.

...

<!-- Выбор лучшего варианта и формирование ответа клиенту -->

<switch>

 

<case condition="bpws:getVariableData('AResponse',

'confirmationData','/confirmationData/Price')

<= bpws:getVariableData(' BResponse',

'confirmationData','/confirmationData/Price')">

 

<!-- Вариант от компании А -->

<assign>

<copy>

 

<from variable="AResponse" />

<to variable="Response2employer" />

</copy>

</assign>

</case>

 

<otherwise>

<!-- Вариант от компании B -->

<assign>

<copy>

<from variable="BResponse" />

<to variable="Response2employer" />

</copy>

</assign>

</otherwise>

</switch>

...

В элементе <case> для сравнения предложений используется BPEL-функция getVariableData и определяется имя переменной. Цена находится в разделе confirmationData сообщения, который является единственной частью сообщения, но это все же требуется определить. Также нужно определить выражение вопроса, чтобы задать местонахождение элемента цены. Здесь это делается простым выражением XPath 1.0.

Если предложение от A лучше, чем от B, копия переменной AResponse помещается в переменную Response2employer. В противном случаекопируется переменная BResponse.

Затем посредством использования активности <invoke> результаты работы бизнес процесса возвращаются клиенту. Для этого используется партнерская связь purchaseLT и вызывается операция SendPurchaseInfo по типу порта ClientCallbackPT:

...

<!—Формирование ответа клиенту -->

<invoke partnerLink="purchaseLT"

portType="emp:ClientCallbackPT"

operation="SendPurchaseInfo"

inputVariable="Response2 employer" />

</sequence>

</process>

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

Корректная и полная реализация стандарта BPEL должна поддерживать следующий набор стандартов веб-сервисов: WSDL 1.1, XML Schema 1.0, XPath 1.0, WS-Addressing, UDDI v2.0, WS-Security (необязательно).

Среди свободно распространяемых программных продуктов, предоставляющих возможности генерации скриптов BPEL, можно выделить Netbeans BPEL Designer - компонент Netbeans Enterpise Pack, представляющий собой бесплатное дополнение к NetBeans и добавляющий к его функциональным возможностям средства визуального проектирования приложений с сервис-ориентированной архитектурой. NetBeans Enterprise Pack содержит средства для проектирования BPEL, схем XML, WSDL файлов, а так же средства обеспечения безопасности веб-сервисов. BPEL Designer позволяет оркестрировать веб-сервисы, а именно: создавать, разрабатывать, запускать и тестировать бизнес-процессы BPEL, соответствующие спецификации WS-BPEL 2.0. Кроме того, данный продукт предоставляет визуальные средства, позволяющие быстро и эффективно оркестрировать веб-сервисы в рамках бизнес-взаимодействия.

Среди платных программных продуктов известен Oracle BPEL Process Manager (BPM) - инфраструктурное решение для проектирования, размещения и управления бизнес-процессами по стандарту BPEL.