|
2002 年 12 月 01 日
最近發(fā)布的 Web 服務的業(yè)務流程執(zhí)行語言（Business Process Execution Language for Web Services，BPEL4WS）規(guī)范，其定位是成為整合方面的 Web 服務標準。您可以創(chuàng)建能夠如完成 Web 服務調(diào)用、操縱數(shù)據(jù)、拋出故障或終止一個流程等工作的不同活動，然后將它們連接起來，從而創(chuàng)建出復雜的流程。這些活動可以嵌套到結(jié)構化活動中，結(jié)構化活動定義了其中的活動的運行方式，如是串行或是并行還是取決于某些條件。本系列文章的目的是讓讀者對 BPEL4WS 語言的不同部件有所了解，并教讀者如何創(chuàng)建他們自己的完整的流程。
引言
今天，Web 服務能夠通過業(yè)界規(guī)范進行相互通信、公開自己、被發(fā)現(xiàn)和被調(diào)用。然而，直到上周，在將這些服務鏈接在一起以成為一個業(yè)務流程或一個整合時，用戶仍需要從許多相互沖突的規(guī)范中作出選擇 ― IBM 的 WSFL 和 Microsoft 的 XLANG 之間正存在這種情況。Web 服務的業(yè)務流程執(zhí)行語言（BPEL4WS）是 WSFL 和 XLANG 融合的產(chǎn)物，如果運氣好的話，它將成為 Web 服務整合標準的基礎。BPEL4WS 集 WSFL 和 XLANG 兩家之長（前者支持面向圖形的流程，后者則支持流程的結(jié)構化構造）于一身，形成了一個支持以極自然的方式實現(xiàn)各種類型的業(yè)務流程的結(jié)合性的軟件包。除了是一種實現(xiàn)語言之外，BPEL4WS 同樣還可以用來描述業(yè)務流程的接口 ― 辦法是使用抽象流程這個概念。我們將在以后的文章中進一步討論這個問題。
BPEL4WS 的最初實現(xiàn)稱為 BPWS4J，IBM 在 alphaWorks（請參閱 參考資料）上也發(fā)布了這個最初實現(xiàn)。用戶在學習和試驗 BPEL4WS 時可以用這個實現(xiàn)來充當試驗地。
我們在本文討論的是 BPEL4WS 的基本概念。
BPEL4WS 的概念
BPEL4WS 支持兩種截然不同的使用情形：
- 實現(xiàn)可執(zhí)行的業(yè)務流程。
- 描述不可執(zhí)行的抽象流程。
本文中著重闡述第一種情形；本系列以后將會有一篇文章來討論 BPEL4WS 的一些抽象流程概念。
作為可執(zhí)行流程的實現(xiàn)語言，BPEL4WS 的作用是將一組現(xiàn)有的服務整合起來，從而定義一個新的 Web 服務。因此，BPEL4WS 基本上是一種實現(xiàn)這樣的整合的語言。與其它任何 Web 服務一樣，整合服務的接口也被描述為 WSDL portType 的集合。整合（稱為 流程）指明了服務接口與整合的總體執(zhí)行的配合情況。 圖 1說明了從外部看到的 BPEL4WS 流程的上述情況。
圖 1. 作為 BPEL4WS 流程實現(xiàn)的 Web 服務的視圖
BPEL4WS 中出現(xiàn)的整合原語主要來自于工作流和業(yè)務流程集成方面多年的經(jīng)驗，因此，BPEL4WS 的定位是成為一種業(yè)務流程整合語言。
實現(xiàn)服務
上圖云塊中的是什么東西？不同于用傳統(tǒng)的編程語言來實現(xiàn) WSDL 服務，每個 portType 的每項操作并不映射成 BPEL4WS 中的一個獨立的邏輯塊。服務的整個類型（即該服務的 portType 集合）由單個 BPEL4WS 流程實現(xiàn)。這樣，與調(diào)用接口操作的外部用戶相對應的特定“入口點”在 BPEL4WS 描述中指明。這些入口點消費 WSDL 操作的從只輸入（input-only）操作或輸入-輸出（input-output）操作傳入的消息。對于后一種情況，流程還必須指明輸出消息在哪里生成。BPEL4WS 只使用和支持 WSDL 只輸入操作和輸入-輸出（請求-響應（request-response））操作；只輸出（output-only）（通知（notification））操作和輸出-輸入（output-input）（要求-響應（solicit-response））操作既不需要也不支持。
BPEL4WS 流程本身基本上就是一個流程圖，類似于用來表達算法的流程圖。流程的每一步稱為一個活動。存在以下一些基本活動：調(diào)用某個 Web 服務上的操作（ <invoke> ），等待一條消息來響應由某人從外部進行調(diào)用的服務接口的操作（ <receive> ），生成輸入／輸出操作的響應（ <reply> ），等待一段時間（ <wait> ），把數(shù)據(jù)從一個地方復制到另一個地方（ <assign> ），指明某個地方出錯了（ <throw> ），終止整個服務實例（ <terminate> ），或者什么也不做（ <empty> ）。
通過使用語言所提供的任何結(jié)構化活動，可以將這些原語活動組合成更復雜的算法。這些結(jié)構化活動提供的能力有：定義一組步驟的有序序列（ <sequence> ），使用現(xiàn)在常見的“case-statement”辦法來產(chǎn)生分支（ <switch> ），定義一個循環(huán)（ <while> ），執(zhí)行幾條可選路徑中的一條（ <pick> ），以及指明一組步驟應該并行地執(zhí)行（ <flow> ）。在并行地執(zhí)行的一組活動中，您可以通過使用 鏈接（link）來指明執(zhí)行順序方面的約束。
BPEL4WS 允許您遞歸地組合結(jié)構化活動，以表達任意復雜的算法，這些算法表示了服務的實現(xiàn)。
與其它東西交互：伙伴
作為一種用來將一組服務組合在一起以形成一個新的服務的語言，BPEL4WS 流程由向其它服務提出調(diào)用和／或接收來自 客戶機（ 圖 1 中服務的用戶)的調(diào)用組成。前者通過使用 <invoke> 活動來做到，后者則通過使用 <receive> 和 <reply> 活動來做到。BPEL4WS 把與流程交互的其它服務稱 伙伴（partner）。這樣，伙伴或者是流程將其作為算法的一個主要部分進行調(diào)用的服務（ 被調(diào)用的伙伴），或者是那些調(diào)用流程的服務（ 客戶機伙伴）。
第一種類型的伙伴是顯而易見的 ― 流程無疑必須調(diào)用其它服務以完成一些事情。 <invoke> 活動指明要調(diào)用的伙伴以及要調(diào)用伙伴的哪個 portTypes 的什么操作。不過，請注意，被調(diào)用的伙伴最后同樣也可以成為客戶機 ― 流程調(diào)用伙伴上的某個操作以請求某種服務這種情況是可能出現(xiàn)的。隨后，伙伴將調(diào)用流程上的操作以提供所期望的數(shù)據(jù)。
把流程的客戶機當作伙伴對待的原因可能并不這么顯而易見。這樣做實際上有兩個原因：第一個原因是，有時流程可能會需要調(diào)用其中一個客戶機伙伴上的操作。異步交互的主要支持機制如下：客戶機調(diào)用流程上的某個操作以請求某種服務。一旦完成，流程會調(diào)用客戶機伙伴上的操作。此時，客戶機伙伴與被調(diào)用的伙伴已沒有什么明顯差別。
第二個原因是，流程所提供的服務可能被不止一個客戶機使用（使用全部服務或使用服務的幾個部件）。此外，流程可能會希望區(qū)別服務的這些不同用戶。舉例來說，一個表示貸款服務系統(tǒng)的流程提供了單個 Web 服務，但只有其中的一些部件是申請貸款的客戶能訪問的，其他一些部分則是客戶服務代表能訪問的，最終是整個服務則只有貸款擔保人才能訪問。根據(jù)某個操作是由客戶還是由擔保人調(diào)用的，所返回的行為可能會有很大不同。另外，由于使用伙伴來模擬客戶機，所以流程可以指明某些操作只能被某些客戶機調(diào)用。
因此，伙伴可以分為以下幾種：
- 只由流程調(diào)用的服務。
- 只調(diào)用流程的服務。
- 或者既由流程調(diào)用又調(diào)用流程的服務（首先出現(xiàn)哪種情況都有可能）。
前兩種分別是 被調(diào)用的伙伴和 客戶機伙伴，它們都是簡單明了的。請考慮第三種情況下流程首先調(diào)用服務時流程和服務之間的關系。這意味著服務提供了（或發(fā)布了）一個 portType（PT1），然后流程調(diào)用該 portType 的操作。同時，流程必須提供一個服務從其中調(diào)用操作的 portType（PT2）。這樣，從流程的角度看，流程需要來自服務的 portType PT1 并提供 portType PT2 給服務。從服務的角度來看兩者間的關系，則會得到一個相反的結(jié)論：服務提供 portType PT1 給流程并需要來自流程的 portType PT2。不管是流程首先調(diào)用服務還是相反，服務和流程的關系都同上所述。
服務鏈接類型
為第三種類型的伙伴建模時引出了 服務鏈接類型。服務鏈接類型不是從這些參與方中的某一方的角度來定義服務和流程之間的關系，而是表示一種第三方聲明，用這個聲明來說明了兩個（也可能是更多個）服務之間的關系。服務鏈接類型定義了一組角色，其中每個角色指明一組 portType。其思想是，當兩個服務彼此交互時，服務鏈接類型就是對這兩個服務如何交互 ― 各方本質(zhì)上提供了什么 ― 的聲明。
BPEL4WS 用服務鏈接類型來定義伙伴?；旧?，伙伴是這樣來定義的：給伙伴一個名稱，然后指明服務鏈接類型的名稱，確定流程在這個服務鏈接類型中將充當什么角色，確定伙伴將充當什么角色。對于純被調(diào)用的伙伴和純客戶機伙伴的情況，服務鏈接類型中將只有一個角色，因而在定義伙伴時只指明了一個角色?；锇槊Q隨后將在 <receive> 、 <reply> 和 <invoke> 中用來指明所期望的伙伴。
服務引用
伙伴在運行時是如何工作的呢？為了能夠在運行時工作，伙伴必須解析成實際的 Web 服務。這樣，伙伴實際上最后就是一個有類型的 服務引用而已，其類型信息來自服務鏈接類型和角色。BPEL4WS 流程本身不指定伙伴如何綁定到特定服務；人們認為這是一個部署時或運行時的綁定步驟，這個綁定步驟必須被 BPEL4WS 實現(xiàn)支持。
處理問題
開發(fā)者需要有處理業(yè)務流程中的錯誤和從錯誤恢復的手段。BPEL4WS 通過 <throw> 和 <catch> 構造在語言中內(nèi)置了異常（故障）。BPEL4WS 的故障概念與 WSDL 的故障概念有直接聯(lián)系，事實上，前者建立在后者的基礎上。
此外，BPEL4WS 支持 補償這個概念，這是一種允許流程設計者為某些不可逆的動作實現(xiàn)一些補償動作的技術。舉例來說，設想有一個旅行預定流程。一旦確認了一項預定，則必須執(zhí)行一些顯式操作才能取消這項預定。這些動作就稱為原始動作的“補償動作”。
BPEL4WS 引入了作用域這個概念，從而遞歸地支持了故障處理和補償，作用域本質(zhì)上是故障處理和／或補償?shù)膯卧Ｔ敿毨斫庋a償和故障處理，需要一篇以它們?yōu)橹黝}的文章，將來會提供一篇這樣的文章。
服務的生命周期
這些服務的生命周期是什么樣的呢？作為 BPEL4WS 流程實現(xiàn)的 Web 服務有一個實例生命周期模型。也就是說，這些服務的客戶機總是與服務（流程）的某個特定實例交互。那客戶機如何創(chuàng)建服務的實例呢？
與傳統(tǒng)的分布式對象系統(tǒng)不同，BPEL4WS 實例不是通過工廠模式創(chuàng)建的。相反，BPEL4WS 中的實例是在服務的消息到達時隱式地創(chuàng)建的。也就是說，實例不是用顯式的“實例標識（instance ID）”來標識，而是用數(shù)據(jù)消息中的一些關鍵字域來標識。舉例來說，如果流程表示一個訂單實現(xiàn)系統(tǒng)，則發(fā)票號碼可能就是用來標識交互所涉及的某個特定實例的“關鍵字”域。這樣，如果當消息到達流程的“啟動”點時沒有可用的匹配實例，那么就會自動創(chuàng)建一個新的實例并與消息中的關鍵字數(shù)據(jù)關聯(lián)起來。在定位到了合適的實例之后，只能在流程的非啟動點接受消息；也就是說，在這些情況下，消息事實上總是被傳送到特定實例。在 BPEL4WS 中，找到一個合適的實例或者創(chuàng)建一個合適的實例（如有必要的話）的流程稱為 消息相關性（message correlation）。將來也會有一篇討論消息相關性的文章。
結(jié)束語
我們在本文簡要地解釋了 BPEL4WS 主要的底層概念。我們從總體上討論了 BPEL4WS 是關于什么的，然后討論了伙伴、故障、補償以及生命周期。在本系列以后的文章中，我們打算詳細地討論 BPEL4WS 的各個特定方面。
［編者按：本專欄的每一期將交替地提供講述 BPEL4WS 背后的概念的系列和講述如何從技術上實現(xiàn)這些概念的系列。下一期將介紹技術實現(xiàn)。］
參考資料
作者簡介
 |
|
|
|
Sanjiva Weerawarana 是 IBM T.J. Watson Research Center 的 Component Systems 組的一名研究人員。他是 BPEL4WS 規(guī)范、WSDL 規(guī)范以及 WSFL 規(guī)范的作者之一，也是 BPWS4J、Apache SOAP、WSTK、WSDL Toolkit、WSIF 和 WSGW 的開發(fā)者之一。他獲得了 Purdue University 的計算機科學博士學位。您可以通過 sanjiva@us.ibm.com與作者聯(lián)系。
|
|
|
|
|
Francisco Curbera 是 IBM T.J. Watson Research Center 的 Component Systems 組的一名研究人員，也是該組的主管。他是 BPEL4WS 規(guī)范、WSDL 規(guī)范以及 WSFL 規(guī)范的作者之一，也是 BPWS4J、Apache SOAP 和 WSTK 的開發(fā)者之一。他獲得了 Columbia University 的應用數(shù)學博士學位。請通過 curbera@us.ibm.com與他聯(lián)系。
|
|
