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