© Майк Лехманн
Перевод: Oracle Magazine RE
Статья была опубликована на сайте www.citforum.ru
В предыдущих статьях я рассматривал 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. Он может создать простенький бизнес-процесс, который сначала вызывает один 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-сервисы, которые будут использованы для выполнения полезной работы. Попросту говоря, есть два типа действий:
На листинге 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-процессов.
За дополнительной информацией обращайтесь в компанию Interface Ltd.
| INTERFACE Ltd. |
| ||||
