Поєднуючи Web-сервіси, HTML, XML, DHTML, Інтернет-технології, статті

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-сервісу, отриманий через дію . Далі, дані про клієнта вибираються і приводяться до формату, сумісного з сервісом кожного банку, через дію. Сервіси The United Loan Service і the American Loan Service викликаються паралельно з дії , що містить дві дії . По завершенню оцінки, сервіс кожного банку повертає керування бізнес-процесу отримання позички зі своєю оцінкою. Цей вхідний (inbound) запит представлений дією .

Далі, ці результати порівнюються один з одним, щоб визначити найкращу ставку, завдяки використанню дій і , аналогічних конструкції if-then-else в мовах програмування. В рамках дії вибирається найкраща ставка та її значення присвоюється змінній для повернення , завдяки використанню дії . Нарешті, результат обох цих викликів надсилається назад джерела виклику, завдяки іншому дії .

Розглянемо деталі реалізації

Процес, визначений у BPEL, Як правило, складається з двох великих секцій: секції декларацій і секції процесних дій, оточених зовнішнім елементом, який називається і ідентифікує ім’я / назва процесу.

Глобальні декларації. Як правило, перша секція процесу містить глобальні декларації, у тому числі ті, які визначають використовувані Web-сервіси і називаються , або ті, які визначають використовувані змінні і називаються

На лістингу 1 наведено листинги декларацій United Loan і American Loan, а також декларації , очікувані цими 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), звані , обробники помилок глобальних транзакцій (global transaction failure handlers), звані , також декларуються в цій першій секції.

Визначення процесу. Друга частина BPEL-процесу містить логіку процесу – кроки, які будуть зроблені, і Web-сервіси, які будуть використані для виконання корисної роботи. Попросту кажучи, є два типи дій:


На лістингу 2 приведений код, що забезпечує виклик the United Loan Service і American Loan Service. Для виклику кожного банку і включені в деяку послідовність (sequence), тим самим змушуючи їх виконуватися один за іншим. Але обидві дії самі включені в дію , тим самим змушуючи обидві підпослідовності для кожного сервісу (бізнес-процесу отримання позики) виконуватися паралельно.

Лістинг 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>

*

*