Business Process Execution Language (язык исполнения бизнес-процессов) упрощает соединение и координацию Web-сервисов.
В предыдущих статьях я рассматривал Web-сервисы, как одиночные Web-сервисы. Я показал, как создать Web-сервисы, используя JAX-RPC - интерфейс прикладного программирования (API) в среде J2EE (J2EE Web services API), и привел примеры того, как некоторое решение из управления Web-сервисов может естественным образом работать с этими Web-сервисами. Понятно, что для бизнеса полезны даже отдельные Web-сервисы, но настоящую ценность для большинства представляет возможность интеграции множества Web-сервисов в более крупные приложения, часто называемые композитными приложениями или бизнес-процессами.
В следующих статьях я рассмотрю соединение нескольких Web-сервисов в бизнес-процесс. Я буду использовать стандарт, называемый Business Process Execution Language (BPEL). BPEL - это стандарт на основе XML, который Oracle, BEA, IBM, Microsoft и другие поставщики интенсивно разрабатывают как механизм для "оркестрирования" "сквозных" (end-to-end) бизнес-процессов, построенных на базе Web-сервисов. Хотя этот стандарт все еще находится в процессе разработки в комитете OASIS, его спецификация уже достаточно продвинута и появились продукты, поддерживающие ее, от ряда поставщиков, включая Oracle.
Почему BPEL?
Часто первая реакция разработчиков, услышавших о BPEL, такова: "Зачем мне нужен этот стандарт для решения задачи, которую можно сделать обычным программированием?" Разумеется, ничто не принуждает разработчика использовать BPEL. Он может создать простенький бизнес-процесс, который сначала вызывает один Web-сервис, затем принимает его результат и вызывает другой Web-сервис. Но проблема становится намного более интригующей, когда вы попытаетесь разобраться с анатомией типичного долгоживущего бизнес-процесса. Сразу встает ряд непростых вопросов:
- Как устроить асинхронные вызовы Web-сервисов, когда вызванный Web-сервис является долгоживущим и должен вернуть управление позднее в Web-сервис, из которого он вызван?
- Как коррелировать, координировать запросы (на вызов Web-сервисов) между многими одновременно выполняющимися бизнес-процессами?
- Как вызывать Web-сервисы параллельно?
- Как сделать откат долгоживущей транзакции, в которой произошел сбой?
- Как составлять большие бизнес-процессы из небольших?
- Как гарантировать надежную доставку сообщений?
Этот список можно продолжить. И, что интересно, не только разработчики (на индивидуальном уровне) много раз пытались решить эти проблемы ранее, для этого предлагалось множество "частных" процессных механизмов, которые в той или иной степени решали эти проблемы. Но неизбежно каждый из них решал их по-своему и каждый из них вынуждал организации привязываться к конкретным поставщикам и нестандартным языкам программирования.
BPEL предназначен для решения и этой проблемы. При его развитии учитывается не только история процессных языков и исследований по механизмам широкого круга компаний, но и происходит разрыв с прошлым, благодаря применению фундамента из стандартов Web-сервисов. C этим фундаментом на основе переносимости, прагматизма предыдущих попыток и академического происхождения многие, включая Oracle, полагают, что BPEL будет основой реализаций сервисно-ориентированной архитектуры.
Пример "Заем [денег]"
Давайте разберем детали на примере. Я постараюсь на простеньком бизнес-процессе показать, как определяется процентная ставка (interest rate) возможного заемщика (loan customer), когда услуги по заемам нескольких банков запрашиваются в соответствии с требованиями его заема.
На рисунке 1 представлены первые шаги, необходимые для составления процесса получения заема (loan process). Я сначала проведу вас по схеме процесса (process flow), особо обращая внимание на некоторые ключевые конструкции языка BPEL, а затем рассмотрим фрагменты кода реального процессного языка. (Рассматриваемый пример скачан с OTN.) При изучении течения процесса акцент будет сделан на синтаксисе процессного языка, взаимодействию процесса с конечным пользователем будет уделено меньше внимания.
Рисунок 1: Начальные шаги для получения заема
Первое, запрос для оценки заявки на заем (loan assessment) - это вызов Web-сервиса, полученый через действие <receive>. Далее, данные о клиенте выбираются и приводятся к формату, совместимому с сервисом каждого банка, через действие.<assign> Сервисы The United Loan Service и the American Loan Service вызываются параллельно из действия <flow>, содержащего два действия <invoke>. По завершению оценки, сервис каждого банка возвращает управление бизнес-процессу получения заема со своей оценкой. Этот входящий (inbound) запрос представлен действием <receive>.
Далее, эти результаты сравниваются друг с другом, чтобы определить наилучшую ставку, благодаря использованию действий <case> и <switch>, аналогичных конструкции if-then-else в языках программирования. В рамках действия <case> выбирается наилучшая ставка и ее значение присваивается переменной для возврата <variable>, благодаря использованию действия <assign>. Наконец, результат обоих этих вызовов посылается обратно источнику вызова, благодаря другому действию <invoke>.
Рассмотрим детали реализации
Процесс, определенный в BPEL, как правило, состоит из двух больших секций: секции деклараций и секции процессных действий, окруженных внешним элементом, который называется <process> и идентифицирует имя/название процесса.
Глобальные декларации. Как правило, первая секция процесса содержит глобальные декларации, в том числе те, которые определяют используемые Web-сервисы и называются <partnerLinks>, а также те, которые определяют используемые переменные и называются <variables>
На листинге 1 приведены листинги деклараций <partnerLinks> United Loan и American Loan, а также декларации <variables>, ожидаемые этими Web-сервисами. Эти конструкции создаются в Oracle BPEL Designer в начале этапа проектирования до того, как сам процесс написан.
Листинг 1: BPEL partnerLinks и переменные для процесса осуществления заема
<process name = "LoanFlow" targetNamespace = http://samples.cxdn.com ...> <partnerLinks> <partnerLink name = "UnitedLoanService" partnerLinkType = "services:LoanService" myRole = "LoanServiceRequester" partnerRole = "LoanServiceProvider"/> <partnerLink name = "AmericanLoanService" partnerLinkType = "services:LoanService" myRole = "LoanServiceRequester" partnerRole = "LoanServiceProvider"/> </partnerLinks> <variables> <variable name = "loanApplication" messageType = "services:LoanServiceRequestMessage"/> <variable name = "loanOffer1" messageType = "services:LoanServiceResultMessage"/> <variable name = "loanOffer2" messageType = "services:LoanServiceResultMessage"/> </variables> <!-Process definition follows --> ... </process>
Другие высокоуровневые конструкции, такие, как обработчики глобальных ошибок (global error handlers), называемые <faultHandlers>, обработчики ошибок глобальных транзакций (global transaction failure handlers), называемые <compensationHandlers>, также декларируются в этой первой секции.
Определение процесса. Вторая часть BPEL-процесса содержит логику процесса - шаги, которые будут предприняты, и Web-сервисы, которые будут использованы для выполнения полезной работы. Попросту говоря, есть два типа действий:
- Действия-примитивы процессов и данных (Primitive process and data activities) для вызовов и получения вызовов от Web-сервисов, такие как <invoke> (вызвать), <receive> (получить) и <reply> (ответить); действия для управления процессом, такие как <wait> (ждать) и <terminate> (завершить); и, наконец, действия для манипулирования данными, такие как <assign> (назначить).
- Структурированные действия для простого программного контроля над тем, какие шаги будут выполняться в бизнес-процессе, включая <case> предложения, <while> циклы, конструкции параллельного исполнения, такие как <flow> (течение) и конструкции последовательного исполнения, такие как <sequence>.
На листинге 2 приведен код, обеспечивающий вызов the United Loan Service и American Loan Service. Для вызова каждого банка <invoke> и <receive> включены в некоторую последовательность (sequence), тем самым вынуждая их исполняться один за другим. Но оба действия <sequence> сами включены в действие <flow>, тем самым вынуждая обе подпоследовательности для каждого сервиса (бизнес-процесса получения заема) исполняться параллельно.
Листинг 2: BPEL поток, последовательность, вызов и получение в процессе осуществления заема
<flow> <!-- Invoke 1st loan provider in parallel to the second --> <sequence> <invoke name="invokeUnitedLoan" partnerLink="UnitedLoanService" portType="services:LoanService" operation="initiate" inputVariable="loanApplication"/> <receive name="receive_invokeUnitedLoan" partnerLink="UnitedLoanService" portType="services:LoanServiceCallback" operation="onResult" variable="loanOffer1"/> </sequence> <sequence> <!-- Invoke the 2nd loan provider in parallel to the first --> <invoke name="invokeAmericanLoan" partnerLink="AmericanLoanService" portType="services:LoanService" operation="initiate" inputVariable="loanApplication"/> <receive name="receive_invokeAmericanLoan" partnerLink="AmericanLoanService" portType="services:LoanServiceCallback" operation="onResult" variable="loanOffer2"/> </sequence> </flow>
Заключение
Не нужно много времени для уяснения эффективности стандартизованного способа создания бизнес-процессов на базе Web-сервисов. И не только потому, что основную процессную функциональность можно немедленно использовать в любой сервисно-ориентированной архитектуре, но и потому, что она построена на базе стандартов, которые получили беспрецедентное признание в отрасли.
Эта ситуация аналогична ситуациям с SQL и J2EE - стандартами, которые, будучи приняты отраслью, создала целые рынки для серверов, инструментальных средств и услуг. Поставщики технологий отныне не пытались решать базисные проблемы доступа к данным и построения бизнес-логики; вместо этого они сосредоточились на новаторских решениях на базе этих стандартов.
BPEL находится в такой же ситуации раскрытия тех же самых возможностей для интеграции бизнес-процессов. В следующих статьях будут рассмотрены построение, управление и выполнение BPEL-процессов.