精彩的人生

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

BPEL and Java

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)的合作鏈接。
?

?1<?xml?version="1.0"?encoding="utf-8"?>
?2<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/"?>
?3<partnerLinks>
?4??????<partnerLink?name="client"
?5?????????????????partnerLinkType="com:selectionLT"
?6???????????????????myRole="insuranceSelectionService"/>
?7??????<partnerLink?name="insuranceA"???????????????????????????????????partnerLinkType="ins:insuranceLT"?
?8?myRole="insuranceRequester"
?9???????????????????partnerRole="insuranceService"/>
10??????<partnerLink?name="insuranceB"???????????????????partnerLinkType="ins:insuranceLT"
11???????????????????myRole="insuranceRequester"???????????????????partnerRole="insuranceService"/>
12???</partnerLinks>??
13
14

然后，我們為保險請求申明變量(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技術?，F在如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一個更好的備有證明文件的位置。??
?


地址：http://cauzcy.bokee.com/4749126.html