Поєднуючи Web-сервіси

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-сервіс. Але проблема стає набагато більш інтригуючою, коли ви спробуєте розібратися з анатомією типового долгоживущего бізнес-процесу. Відразу постає ряд непростих питань:


Цей список можна продовжити. І, що цікаво, не тільки розробники (на індивідуальному рівні) багато разів намагалися вирішити ці проблеми раніше, для цього пропонувалося безліч "приватних" процесних механізмів, які в тій чи іншій мірі вирішували ці проблеми. Але неминуче кожен з них вирішував їх по-своєму і кожен з них змушував організації прив'язуватися до конкретних постачальникам і нестандартним мов програмування.

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-процесів.

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*