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