原文鏈結： http://www.theserverside.com/articles/article.tss?l=BPELJava

BPEL 的作用

??? 實現從面向過程到面向服務的轉變需要一種語言以描述 Web services 是怎樣被組織成業務流程。如果這種描述是可執行的，即允許我們定義抽象的流程，而且允許我們描述流程準確的執行規則，那將更好。而 BPEL 正是這樣一種語言。事實上它是最先具備以下特性的語言：

??? 1 允許我們定義抽象和可執行的流程

??? 2 有大多數公司支持

??? 3 軟件運行在 bpel 流程可以執行（ BPEL 服務器）和設計（ BPEL 設計器）的平臺上

在我們對 BPEL 做更深入的了解之前，先論述一下怎樣組織 web 服務。這通常有兩種方法：音樂演奏式和舞蹈式。音樂演奏式為一個中心進程控制相關的 web services 并協調在操作中被調用的 web services 中不同操作的執行。音樂演奏時的樂譜就是一次組織過程。被調用的 web services 并不知道他們被調用以組織成一個流程，也不知道他們是一個更高層業務流程的一部分（它們也不需要知道）。只有音樂演奏中的指揮者知道這些，所以音樂演奏方式是將清晰定義的操作和 web services 的調用順序集中起來管理的方式。

??? 相比而言舞蹈方式不依賴一個中心的協調器。每一個在舞蹈方式中被調用的 web service 清楚的知道何時執行它的操作并且知道與誰合作。舞蹈方式是專注與信息交互的合作方式。所有的參與者需要關注業務流程，操作的執行，信息的交互以及信息交互的時機。

??? 通過對組合 web services 以執行業務流程的了解，音樂演奏方式比之舞蹈方式為更靈活的處理方法：

???? 我們準確的知道誰對整個業務流程的執行負責

???? 即使是那些不知道他們是一個業務流程一部分的 web services ，我們也可以組合

???? 當錯誤發生時我們也可以提供可選擇的替代

??? BPEL 遵循音樂演奏的方式。舞臺方式為其他標準采用，比如 WSCI （ Web Services Choreogaphy Interface ）和 WS-CDL （ Web Service Choreography Description Language ）。比之 BPEL ，舞蹈方式還沒有獲得業界的支持。

??? 2002 年 8 月， BEA 、 IBM 、 Microsoft 開發出 BPEL 的第一個版本。從那時候起，越來越多廠商的加入使得在 2003 年 3 月在第一個版本基礎上做了一些調整和改進的 1.1 版本的誕生。在 2003 年 3 月， BPEL 被提交至 OASIS 組織作為標準，后來 WSBPELTC 組織成立。

??? BPEL 可以在公司內部和公司之間使用。在公司內部， BPEL 的作用是標準化企業應用集成和促進以前孤立系統之間的集成。在企業之間， BPEL 使得業務伙伴之間的集成更容易更高效。以 BPEL 描述的業務流程的定義在不影響現有系統的情況下完成升級。在已經是函數環境或將要通過 web services 方式提供服務的環境當中 BPEL 是重要的技術。隨著 web service 技術得到越來越多的使用， BPEL 的重要性將日漸增強。

BPEL 語言

????? 現在讓我們看一下 BPEL 語言。 BPEL 作為一種語言具體設計用來定義業務流程。 BPEL 支持兩種不同類型的業務流程：

???? 可執行流程允許我們指定嚴格的業務流程的細節，他們由音樂演奏引擎執行。在大多數情況下， BPEL 被用作定義可執行的流程

??? 抽象的業務協議允許我們指定僅僅在各參與者之間公共的信息交換。他們不包含處理流程的內部細節并且不是可執行的。

??? BPEL 建立在 XML 和 web services 之上，它是一種基于 XML 的語言，支持包括 SOAP,WSDL,UDDI,WS-Reliable 消息 ,WS-Addressing,WS-Coordination 和 WS-Transaction 的 web services 技術棧。 BPEL 汲取了兩種早先的工作流語言： WSFL(Web Services Flow Language) 和 XLANG 。 WSFL 由 IBM 設計，基于有向的內容。 XLANG 由微軟設，是一種程序塊結構語言。 BPEL 融合了這兩種方法為業務流程的描述提供了豐富的語法。

??? 一個 BPEL 流程嚴格指定了參與的 web services 被調用的順序。這可以順序或并行地完成。使用 BPEL 我們可以表示有條件的行為，例如一個 web service 的執行可以依賴前一個調用的結果。我們也可以構建循環，申明變量，拷貝和賦值變量，定義錯誤處理程序等。通過組合這些結構，我們可以以一個算法方式定義復雜的業務流程。

??? 因此 BPEL 可以與像 java 這樣的一般編程語言相比，不過沒有 java 那樣強大。但另一方面，它更簡單并適合業務流程的定義。因此 BPEL 不是對 java 這樣的高級語言的替代而是一個補充。讓我們了解一下一個典型的 BPEL 流程。首先，這個 BPEL 業務流程收到一個請求。為了處理這個請求，流程開始調用相關的 web services 并將最后的結果返回給最初的請求發送者。因為 BPEL 流程需要與其他的 web services 通信，所以它非常依賴被合成 web service 所調用的 web services 的 WSDL 描述。

??? 一個 BPEL 流程由很多個步驟組成，每一步驟被稱為一個活動。 BPEL 支持基本的和結構化的活動。基本的活動即為基礎的結構，用作公共的任務，比如：

??? 使用調用其他的 web services

??? 通過發送一個消息等待客戶端調用業務流程使用 ( 收到一個請求 )

??? 使用對同步的操作產生響應

??? 使用處理數據變量

??? 使用指示錯誤和異常

??? 使用等待一段時間

??? 使用結束整個流程等等

??? 這樣我們可以組合這些和其他基本的活動定義準確反映業務流程步驟的復雜算法。為了組合基本的活動 BPEL 支持一些結構化的活動。其中最重要的有：

??? 允許我們定義一系列按順序調用的活動

??? 用來定義一系列并行調用的活動

??? 用來構建分支結構

??? 用來定義循環

??? 在許多的替代路徑中選擇一個的操作使用

??? 每一個 BPEL 流程也可以使用申明變量，使用定義合作鏈接。我們將在文章的下面部分對合作鏈接作更多的探討。

??? 一個 BPEL 流程可能是同步也可能是異步的。一個同步的 BPEL 流程鎖定客戶端 ( 使用這個流程的 ) 直到這個流程完成并返回一個結果給客戶端。一個異步的流程不鎖定客戶端，而是使用一個回調來返回結果 ( 如果結果存在的話 ) 。通常我們使用異步的流程實現長時間的流程，使用同步實現在一個相對短的時間里返回結果的流程。如果一個 BPEL 流程使用異步的 web services ，流程本身同時也是異步的 ( 雖然這不是必須的 ) 。

???? 對于客戶端來說，一個 BPEL 流程看起來就和其他的 web service 差不多。當我們定義一個流程，實際上我們是在定義一個由已存在服務組合而成的新的 web service 。為了調用由 BPEL 描述的業務流程，我們需要調用合成出來的復合 web service 。下圖為一個 BPEL 流程的示意圖：

? 合作鏈接

上面我們提到 BPEL 也申明合作鏈接，現在讓我們解釋一下什么是合作鏈接。我們已經提到 BPEL 和外部的 web services 的交互有兩種方式：

?? BPEL 流程調用其他 web services 上的操作

?? BPEL 流程接收客戶端的調用。在所有客戶端中有一個是發起最初調用的 BPEL 流程的使用者。其他客戶端是 web services 。舉例來說，是那些已經為 BPEL 流程所調用，但是需要回調以返回結果。

?? BPEL 把這些所有和它交互部分的鏈接稱之為合作鏈接 (partner links) 。合作者鏈接可以是被 BPEL 流程調用的 web services ，也可以是調用 BPEL 流程的客戶端。每一個 BPEL 流程至少有一個客戶端合作鏈接，因為必然有一個調用 BPEL 流程的客戶端。

??? 通常一個 BPEL 流程也至少有一個調用的合作鏈接，因為它將調用至少一個 web service( 通常不止一個 ) 。不管怎么樣，被調用的合作鏈接可能成為客戶端鏈接——這通常是在異步服務的情況下，流程調用一個操作的地方。然后這個服務 ( 合作者 ) 調用流程上的回調操作來返回被請求的數據。

??? BPEL 像合作鏈接一樣對待客戶端有兩個原因。最顯而易見的是支持異步交互，第二個原因是基于 BPEL 流程可以提供服務的事實。這些通過端口類型提供的服務可以為多于一個的客戶端使用。流程可能希望區分不同客戶端并僅僅提供給他們經授權的功能。舉例來說，一個保險流程可能提供給汽車保險客戶與房產保險客戶不同的一系列操作。

??? 綜上述，我們可以看到合作鏈接描述了指向合作者的鏈接，這樣的合作者可能是：

??? 流程調用的服務

??? 調用流程的服務

??? 兩者兼而有之的服務——它們既被流程調用也調用流程

BPEL 的例子

??? 為了了解 BPEL 流程究竟是什么樣子，下面我們給出一個選擇最好保險服務的非常簡單的 BPEL 流程。首先，我們申明指向一個 BPEL 流程客戶端（稱作 client ）和兩個保險 web 服務 ( 稱作 insuranceA 和 insuranceB) 的合作鏈接。

? <?xml version="1.0" encoding="utf-8"?>

<process name="insuranceSelectionProcess"

???????? targetNamespace="http://packtpub.com/bpel/example/"

???????? xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"

???????? xmlns:ins="http://packtpub.com/bpel/insurance/"

???????? xmlns:com="http://packtpub.com/bpel/company/" >

?? <partnerLinks>

????? <partnerLink name="client"

?????????????????? partnerLinkType="com:selectionLT"

?????????????????? myRole="insuranceSelectionService"/>

????? <partnerLink name="insuranceA"

?????????????????? partnerLinkType="ins:insuranceLT"

?????????????????? myRole="insuranceRequester"

?????????????????? partnerRole="insuranceService"/>

????? <partnerLink name="insuranceB"

???????? ??????????partnerLinkType="ins:insuranceLT"

?????????????????? myRole="insuranceRequester"

?????????????????? partnerRole="insuranceService"/>

?? </partnerLinks>

...

然后，我們為保險請求申明變量 (InsuranceRequest) ，保險 A 和 B 響應 (InsuranceAResposne, InsuranceBResposne) ，和最終的選擇 (InsuranceSelectionResponse)

...

?? <variables>

????? <!-- input for BPEL process -->

????? <variable name="InsuranceRequest"

??????????????? messageType="ins:InsuranceRequestMessage"/>

????? <!-- output from insurance A -->

????? <variable name="InsuranceAResposne"

??????????????? messageType="ins:InsuranceResponseMessage"/>

????? <!-- output from insurance B -->

????? <variable name="InsuranceBResposne"

??????????????? messageType="ins:InsuranceResponseMessage"/>

????? <!-- output from BPEL process -->

????? <variable name="InsuranceSelectionResponse"

??????????????? messageType="ins:InsuranceResponseMessage"/>

?? </variables>

...

最后，我們具體化流程步驟。首先我們從客戶端等待初始的請求信息 () 。然后我們使用并行調用 () 兩個保險 web 服務。保險服務返回保額，然后我們選擇低的保額 (/ ) 并使用將結果返回給客戶 (BPEL 流程的調用者 )

...

?? <sequence>

????? <!-- Receive the initial request from client -->

????? <receive partnerLink="client"

?????????????? portType="com:InsuranceSelectionPT"

?????????????? operation="SelectInsurance"

?????????????? variable="InsuranceRequest"

??????? ???????createInstance="yes" />

????? <!-- Make concurrent invocations to Insurance A and B -->

????? <flow>

???????? <!-- Invoke Insurance A web service -->

???????? <invoke partnerLink="insuranceA"

???????????????? portType="ins:ComputeInsurancePremiumPT"

???????????????? operation="ComputeInsurancePremium"

???????????????? inputVariable="InsuranceRequest"

???????????????? outputVariable="InsuranceAResposne" />

???????? <!-- Invoke Insurance B web service -->

???????? <invoke partnerLink="insuranceB"

???????????????? portType="ins:ComputeInsurancePremiumPT"

???????????????? operation="ComputeInsurancePremium"

???????????????? inputVariable="InsuranceRequest"

???????????????? outputVariable="InsuranceBResposne" />

????? </flow>

????? <!-- Select the best offer and construct the response -->

????? <switch>

??????? <case condition="bpws:getVariableData('InsuranceAResposne',

???????????????????????? 'confirmationData','/confirmationData/Amount')

????? ????????????????<= bpws:getVariableData('InsuranceBResposne',

???????????????????????? 'confirmationData','/confirmationData/Amount')">

?????????? <!-- Select Insurance A -->

?????????? <assign>

???????????? <copy>

?????????????? <from variable="InsuranceAResposne" />

?????????????? <to variable="InsuranceSelectionResponse" />

???????????? </copy>

?????????? </assign>

??????? </case>

??????? <otherwise>

?????????? <!-- Select Insurance B -->

?????????? <assign>

???????????? <copy>

?????????????? <from variable="InsuranceBResposne" />

?????????????? <to variable="InsuranceSelectionResponse" />

???????????? </copy>

?????????? </assign>

??????? </otherwise>

????? </switch>

????? <!-- Send a response to the client -->

????? <reply partnerLink="client"

???????????? portType="com:InsuranceSelectionPT"

???????????? operation="SelectInsurance"

???????????? variable="InsuranceSelectionResponse"/>

?? </sequence>

</process>

?? 因為每一個 BPEL 流程都是一個 web service ，每一個 BPEL 流程也需要一個 WSDL 文檔。我們將不再對開發 BPEL 流程的更深入的細節作討論。更多的資料可以參閱由 Packt Publishing 于 2004 年 10 月出版的《 web 服務的業務流程執行語言》 (Business Process Execution Language for Web Services)

? BPEL 和 Java

? 看到從上面 BPEL 流程的例子一些人也許會想這樣一個組合用 java 也很容易實現。對于非常簡單的流程來說這是正確的。但是對于更復雜的流程來說我們會看到 BPEL 比之 Java 的至少兩個重要的優勢。

? BPEL 比之 Java 的第一個優勢是 BPEL 流程是可移植的，甚至可以運行在 Java 平臺之外。 BPEL 流程可以在基于 Java 平臺的音樂演奏服務器上運行也可以在任何其他的軟件平臺上運行 ( 如 .Net 平臺 ) 。這在使用不同平臺的 B-B 交互中顯得尤為重要。

? BPEL 的第二個優勢是它針對業務流程特性的支持。通常業務流程是長時間運行的，特別是他們在 internet 上實現與其他合作者交互的時候。有可能這樣流程的執行需要幾分鐘，幾小時，甚至是幾天才能完成。有可能它們調用一個 web service 需要等待一個相對長的時間以獲得回調的結果。如果我們不使用一個 BPEL 流程而是使用一個 Java 應用程序我們的大部分時間將會擔心什么線程已經完成，什么仍然在運行。我們將不得不跟蹤 Java 線程以確定那些我們能結束，又有哪些需要繼續運行以獲得回調結果。

? BPEL 也用相對簡單的方式支持補償。對在業務流程中那些已經成功完成操作的補償，或者撤銷操作是業務流程中最重要的問題之一。補償的目的是恢復這個被撤銷的業務流程中已經執行完成的活動。

?? 補償與大多數業務流程的特性相關，這種業務流程是長時間運行的并且使用異步的方式與松散耦合的 web servcies 通信。就成功完成來說業務流程是非常脆弱的，因為他們所使用的數據本身就是脆弱的。因為它們通常橫跨多個合作伙伴 ( 同時是多個企業 ) ，所以需要關注業務流程可能是完整執行也可能部分結果是未完成的，即補償。這和在企業信息系統中的 ACID 事務類似。 BPEL 使用定義的補償操作的能力支持補償的概念 ( 某種范圍上講這是特殊處理 ) ，這種特性稱之為長時間事務 (LRT) 。

??? 業務流程也可能需要對中心事件做出反映。這樣的事件可能是消息事件或者警告事件。通過在端口類型上的調用操作消息事件由引入消息觸發。警告事件是時間相關的，并且在一段持續時間之后或者一個特殊的時間觸發。 BPEL 對業務流程中的事務管理提供了很好的支持。

??? 這樣就有并發活動。在 BPEL 中并發活動使用活動來模擬。在標簽內聚集嵌套的活動非常直觀，也對表示那些并不太復雜的并發場景非常有幫助。為了表達更復雜的場景，提供在活動之間表達同步依賴的能力。換句話說，我們可以具體指定哪個活動能夠開始，什么時候開始 ( 依賴其他的活動 ) 并且可以定義復雜的依賴。舉例來說，我們常常指定一個特定的活動或幾個活動必須在其他一個或幾個活動結束之后才能開始。

??? 與 web services 的無狀態模式相比業務流程模式需要使用一個有狀態的模式。當一個客戶端開始一個業務流程，一個新的實例將會創建。這個實例在業務流程的生命周期中存在。發送給業務流程的消息 ( 使用在端口類型和通信端口上的操作 ) 需要被轉送到正確的業務流程實例。 BPEL 提供使用特定業務數據來保存指向特定業務流程實例的機制。這種功能稱為相關性 (correlation) 。

??? 我們可以繼續討論，不過很明顯 BPEL 已設計用來滿足定義業務流程的需要。很明顯， BPEL 作為一種編程語言或是一個平臺來說都不能取代 Java 。事實上， Java 平臺是運行 BPEL 流程的一個選擇。

??? BPEL 服務器和開發工具

??? 為了執行 BPEL 流程我們需要一個音樂演奏式的服務器。這樣的服務器為可執行的 BPEL 業務流程提供一個運行的環境。 BPEL 與 web services 緊密相關，也和支持 web service 開發的現代軟件平臺緊密相關，特別是 J2EE 和 .Net 平臺。

??? BPEL 服務器可以使用 J2EE 或者 .Net 應用服務器的環境，這樣他們可以使用應用服務器提供的服務，比如安全，事務，可伸縮性，和數據庫的集成， EJB 組件服務，如 JMS 的消息服務等等。

??? BPEL 服務器在 J2EE 和 .Net 平臺上都已存在。在 J2EE 平臺下我們至少可以在以下中選擇：

???? Oracle BPEL Process Manager (http://www.oracle.com/technology/products/ias/bpel/index.html)

???? IBM WebSphere Business Integration Server Foundation??????? (http://www.ibm.com/software/integration/wbisf)

??? IBM alphaWorks BPWS4J (http://www.alphaworks.ibm.com/tech/bpws4j)

??? OpenStorm Service Orchestrator (http://www.openstorm.com)

???? Vergil VCAB Server (http://www.vergiltech.com/products_VCAB.php)

??? Active Endpoints ActiveWebflow Server (http://www.active-endpoints.com/products/index.html)

??? ActiveBPEL engine (http://www.activebpel.org/)

??? Fivesight Process eXecution Engine (http://www.fivesight.com/pxe.shtml)

??? 基于 .Net 平臺的 BPEL 服務器包括：

Microsoft BizTalk 2004 (http://www.microsoft.com/biztalk/)

OpenStorm Service Orchestrator (http://www.openstorm.com)

? OpenStorm 提供包括 J2EE 和 .NET 平臺上的解決方案。除了 BPEL 音樂演奏式服務器之外還有一些可用的 BPEL 設計工具。這些工具支持對 BPEL 流程的圖形化開發并通常和服務器集成在一起：

?? Oracle BPEL Designer

? IBM WebSphere Studio Application Developer, Integration Edition

? IBM BPWS4J Editor

? Vergil VCAB Composer

?Active Endpoints ActiveWebflow Designer

當 Vergil VCAB Composer 在 .NET 平臺上建立時， Oracle, IBM 和 Active Endpoints 的解決方案則是基于 Java Eclipse 框架。我們可以看到在 Java 平臺上更多可用的 BPEL 服務器和設計器。

BPEL+jAVA

? 我們已經看到 BPEL 是組合 web services 成為業務流程的合適語言。 BPEL 不是一般普適性語言 ( 也不想成為 ) 。因此 BPEL 和 JAVA 相互配合， Java 負責 web services 的編程實現和 web services 與 BPEL 流程的執行平臺。

?? 如在規格說明書中提到的， BPEL 是可擴展的。特別是 BPEL 可以擴展至 web services 之外是非常有前景的。這意味著我們可以使用 BPEL 組合不同的資源而不僅僅是 web services 。在 J2EE 平臺中，可能包括 EJBs ， JMS ， RMI ， JCA 和其他資源。對于這個問題通常有兩種解決方法：

??? 支持 BPEL 和 Java 代碼的混合，這就是 BPELJ 的思想

??? 用 WSDL 描述所有的資源 (Java classes,EJBs,JMS 等等 ) ，這是 Web Services 調用框架中的思想

? BPELJ 提供在 BPEL 流程定義中包含 java 代碼 ( 稱之為 JAVA 片斷 ) 的可能性。這一方面使我們能夠從 BPEL 中直接調用 Java 資源 (BPELJ 支持 Java 合作者鏈接 ) ，另一方面，它給了 BPELJ 增強的能力，因為使用 java 片斷，我們可以執行諸如計算值，構建 XML 文檔之類的任務，也可以不用創建 web 服務就執行其他代碼。我們也可以使用 BPEL 變量表達 JAVA 代碼片段。 IBM 和 BEA 支持 BPELJ ，并且已經發表了 BPELJ 的白皮書。

??? 將 java 代碼整合進 BPEL 流程以支持調用 JAVA 資源是非常有用的。但是，在某些情況下這樣的處理方式也會帶來缺點。對一個 Java 資源的調用不同于對一個 web service 的調用。 web 服務調用框架 (WSIF) 遵循另外一種處理思路：在 BPEL 中使用相同的語法調用資源或服務并使用 WSDL 來描述，即使它是一個不通過 SOAP 協議通信的 Java 資源。 WSIF 也允許我們將這樣的服務和實際的實現與協議相映射。

??? 換句話說，我們可以把對抽象服務的描述與基于 SOAP 協議的實現綁定，與 Java 類綁定，與 EJB 綁定或者其它支持的資源，這只需要修改 WSDL 綁定即可。在 BPEL 中沒有代碼的更改是必須的而支持 BPEL 擴展也是需要的。對這種綁定的支持在由 WSIF 提供的支持者那里是堅定不移的。

?? WSIF 是最初由 IBM 的 WSTK (Web Services Toolkit) 開發中 alphaWorks 部分發展而來的 Apache 技術。現在如 Oracle BPEL Process Manager 的一些 BPEL 服務器已經支持 WSIF 。

?? 這兩種方法， BPELJ 和 WSIF 都適合現實世界的場景并且使得 BPEL 在 EAI 和 B2B 中都非常有用。

結束語

??? BPEL 是面向過程轉向面向服務的一種重要語言。因為 BPEL 具體設計用來定義業務流程，因此對業務流程的很多特殊性有很好的支持，如長時間事務，補償，事件管理，相關性等等。 BPEL 非常適合和 J2EE 平臺一起使用，很多 BPEL 服務器也是建立在 J2EE 之上的。結合 BPEL 和 Java 的 BPELJ 以及 WSIF 的思路使得 BPEL 的可用性越來越好。應該看到正在制定的 JBI(Java Business Integration) 規范將會在 JAVA 平臺里給業務集成和 BPEL 一個更好的備有證明文件的位置。