【文章內(nèi)容簡介】 以創(chuàng)建出表達任意復(fù)雜業(yè)務(wù)邏輯的流程[4]。BPEL標準定義多種結(jié)構(gòu)化活動，實現(xiàn)了不同的控制流模式。BPEL標準定義的結(jié)構(gòu)化活動集合并不是最小集，有些情況下一個業(yè)務(wù)邏輯可以用不同的活動來實現(xiàn)。比如一個順序業(yè)務(wù)邏輯可以使用Sequence活動實現(xiàn)，也可以使用定義合適Links的Flow實現(xiàn)。而Sequence和Flow是BPEL結(jié)構(gòu)化活動中最重要的兩個。（1）Sequence——順序執(zhí)行Sequence活動包含一個或多個按照出現(xiàn)順序先后執(zhí)行的子活動，當最后一個子活動執(zhí)行結(jié)束時Sequence活動結(jié)束。（2）Flow——并行和控制依賴處理Flow活動提供并發(fā)和同步機制。Flow的子活動并發(fā)執(zhí)行，當所有子活動都結(jié)束時Flow才結(jié)束。子活動使能判斷為假而跳過執(zhí)行也認為該子活動結(jié)束。Flow同時啟動各個子活動執(zhí)行，其子活動的各層次子活動之間可能存在同步依賴，因此Flow通過定義Link提供Flow內(nèi)部各層次子活動之間的同步依賴。每個活動都有可選的sources和targets容器，分別包含一組source和target元素，這些元素通過Link確定活動之間的同步關(guān)系。一個Link分別對應(yīng)一個source活動和target活動，規(guī)定在source活動執(zhí)行結(jié)束之前target活動不允許開始執(zhí)行。一個活動可以設(shè)置多個source，也可以設(shè)置多個target。targets容器中有個可選參數(shù)joinCondition定義多個target的布爾組合方式，默認是或，即該活動對應(yīng)的多個source活動只要有一個完成即可開始執(zhí)行該活動。Link定義的過程中不能形成控制環(huán)，即一個source活動對應(yīng)的target活動是其邏輯在前的。除了Sequence和Flow，結(jié)構(gòu)化活動還有Pick（事件觸發(fā)選擇處理）、ForEach（遍歷執(zhí)行）、While、RepeatUntil（循環(huán)執(zhí)行）、If、Elseif（選擇執(zhí)行）等等。這類結(jié)構(gòu)化活動的定義主要是為了能貼近人類語言，按照用戶指定的表達式有選擇地執(zhí)行活動。他們的表達式的解析和條件的判定由該活動本身的執(zhí)行方法處理，然后按照用戶的定義，以串行或者并行的方式來調(diào)度他們。我們可以認為，在流程引擎內(nèi)部，活動總是以串行或者并行的方式進行調(diào)度和執(zhí)行，對其他的活動類型并不關(guān)心。Sequence和Flow結(jié)構(gòu)化活動是流程引擎的主要工作模式和設(shè)計重點，實現(xiàn)了穩(wěn)定可靠的串行與并行控制機制，就能在此基礎(chǔ)上執(zhí)行其他結(jié)構(gòu)化活動。因此，我們把Sequence和Flow活動作為關(guān)鍵點進行研究。 本章主要介紹了BPEL語言的基礎(chǔ)理論，描述了BPEL基本活動與結(jié)構(gòu)化活動的標準屬性和成員，并說明了為什么SEQUENCE和FLOW是流程引擎處理的關(guān)鍵活動類型。為下文鋪開APACHE ODE流程引擎的設(shè)計，提出基于C++的BPEL流程引擎原型設(shè)計方案中如何解決處理并發(fā)控制部分作理論知識介紹。第三章 關(guān)于Apache ODE流程引擎的研究ODE的主要開發(fā)目標是開發(fā)可靠的，結(jié)構(gòu)緊湊的，可嵌入的組件，能夠管理使用BPEL流程描述語言的長時間運行的業(yè)務(wù)流程的執(zhí)行。重點是開發(fā)具有最小依賴性的小模塊，以便重新組裝成一個功能齊全的業(yè)務(wù)流程管理系統(tǒng)。[4,16] Apache ODE結(jié)構(gòu)總覽ODE架構(gòu)中的關(guān)鍵組成部分包括BPEL編譯器、ODE BPEL引擎運行時，ODE數(shù)據(jù)訪問對象(DAOs），ODE集成層(ILs)，和用戶工具[16]。編譯器把BPEL文件轉(zhuǎn)換成運行時可執(zhí)行的格式，運行時以一種可靠方式執(zhí)行他們，并通過DAO層把他們保存起來；運行時在集成層中運行，集成層將BPEL引擎連接到更為廣闊的外部執(zhí)行環(huán)境。 APACHE ODE流程引擎架構(gòu)圖 ODE流程引擎為了研究流程引擎的內(nèi)部機制，必需研究學習其源代碼，因為我們首先考慮開源項目。而在諸多開源項目中，Apache ODE流程引擎是嚴格按照BPEL標準制訂，有詳細規(guī)范文檔可參閱的項目之一。其他流程引擎，如JBPM，擴展了BPEL，加入了其他繁雜的功能，增加了分析的難度。因此選擇參考Apache ODE引擎能拋開其余干擾，在其嚴格的標準下研究流程引擎的內(nèi)部機制。 ODE BPEL編譯器BPEL編譯器負責把BPEL來源（即BPEL流程文件， WSDLs和schemas）編譯成可執(zhí)行的形式。編譯器的輸出結(jié)果不是一個“好的”編譯表現(xiàn)結(jié)果，也不是這些源文件的錯誤信息列表。編譯器生成的結(jié)果是一種對象模型，類似于基本BPEL流程文件的結(jié)構(gòu)。但是，這種變異結(jié)果解決了BPEL中出現(xiàn)的各種名稱引用（如變量名），內(nèi)聯(lián)了所需的WSDL和類型信息，并生成了各種結(jié)構(gòu)（如默認的補償處理）。這些編譯結(jié)果（通常是一個擴展名為cbp的文件）是BPEL運行所需的唯一對象。 ODE BPEL引擎運行時ODE BPEL引擎運行時在BPEL運行時模塊中建立，提供給BPEL流程執(zhí)行的。運行時提供了大量BPEL結(jié)構(gòu)的實現(xiàn)，以處理流程執(zhí)行中最復(fù)雜繁瑣的工作。運行時同時也實現(xiàn)了何時應(yīng)當創(chuàng)建新實例，和把剛收到的消息分發(fā)給哪個實例的邏輯。最后，運行時實現(xiàn)了流程管理的API以供用戶工具使用。為了在不可靠的環(huán)境中實現(xiàn)可靠的執(zhí)行過程，運行時依賴于數(shù)據(jù)訪問對象(DAOs)提供的持續(xù)設(shè)施。這些DAOs的實現(xiàn)可自定義，但通常提供了與關(guān)系數(shù)據(jù)庫的交互。BPEL結(jié)構(gòu)的運行時在實例級上是通過ODE的Java并發(fā)對象(Jacob)框架實現(xiàn)的。Jacob提供了一個應(yīng)用級的不依賴于線程的并發(fā)機制和一個提供執(zhí)行中斷與恢復(fù)的透明機制。Jacob是Java實現(xiàn)ACTORS[Agha]并發(fā)模型中非常大的一塊，其流程代數(shù)有許多功能，如\Pi –calculus。本質(zhì)上來說，Jacob為BPEL的執(zhí)行提供了一個持久穩(wěn)固的虛擬機。 ODE數(shù)據(jù)訪問對象(DAOs)ODE數(shù)據(jù)訪問對象作為BPEL引擎運行時與底層數(shù)據(jù)存儲間交互的媒介。通常，數(shù)據(jù)存儲是一個JDBC關(guān)系數(shù)據(jù)庫：既然如此，那么DAOs就是使用OpenJPA數(shù)據(jù)訪問庫來實現(xiàn)的。這樣就能夠創(chuàng)建自定義的DAO實現(xiàn)，即使JDBC沒有提供相關(guān)實現(xiàn)，也能以某種機制達到持久化保存的目的。BPEL引擎運行時需要DAO對象來以處理以下持久化的問題：（1）積極的情況下——知道哪一個實例被創(chuàng)建；（2）消息路由——哪一個實例正在等待哪一條消息；（3）變量——每一個實例的BPEL變量的值；（4）合作伙伴鏈接——每一個實例的BPEL合作伙伴連接的值；（5）流程執(zhí)行狀態(tài)——Jacob的持久穩(wěn)固虛擬機的序列化狀態(tài)。有關(guān)OpenJPA/JDBC DAO的實現(xiàn)，和相關(guān)組織信息通常在FIGREF中提供。 ODE 集成層ODE BPEL引擎運行時不能在真空中存在：它自己本身是不能影響與外部世界交往的。為此它依賴于一個ODE集成層(ILs)。集成層將運行嵌入一個執(zhí)行環(huán)境。例如，有一個集成層AXIS2和JBI。集成層的基本功能是為運行時提供通道間的通信。AXIS2集成層使用AXIS2庫，讓運行時以Web服務(wù)的方式與外加交互。JBL集成層則嘗試把運行時加入JBI消息總線達到同樣的目的。除了通訊以外，集成層還為運行時提供了線程管理機制，并管理運行時的整個生命周期，例如配置和啟動運行時。 APACHE ODE流程引擎的JACOB框架JACOB，即Java Concurrent Objects（Java并發(fā)對象），是APACHE ODE引擎的內(nèi)核框架。ODE依賴于JACOB 框架去實現(xiàn)BPEL的構(gòu)建。框架提供一些機制去解決兩個構(gòu)建BPEL的關(guān)鍵問題：執(zhí)行狀態(tài)的持久化，并發(fā)處理[17]。即使是用戶只有一個線程，代碼也能夠拆解成并發(fā)處理的問題。通過把整個事務(wù)分解為一些較小的部分，我們就可以控制到那些真正被調(diào)用和執(zhí)行的部分。比如說，我們有一個按照以下次序來執(zhí)行一個過程：1. Invoke2. Receive3. Wait4. Invoke 如果有兩個進程我們需要同時處理，簡單的實現(xiàn)方法是這樣：1. Invoke12. Receive13. Wait14. Invoke15. Invoke26. Receive27. Wait28. Invoke2但是如果我們把代碼分解，引進一個所謂的“中間人”（或者稱為棧），并且不允許活動直接地進行相互調(diào)用，我們就有了以下的調(diào)用次序：1. Invoke15. Invoke22. Receive13. Wait16. Receive27. Wait24. Invoke18. Invoke2從客戶的角度來看，我們就實現(xiàn)了利用單線程達到并發(fā)的效果。在實際情況中，一些活動可能會持續(xù)幾天，倘若進程發(fā)生錯誤時，進程的執(zhí)行狀態(tài)就會丟失。所以用類似“掛起”這種能把執(zhí)行狀態(tài)保存在磁盤的操作會更好。然而把進程掛起到磁盤上存在著一些實現(xiàn)上的問題。在我們希望“掛起”時，調(diào)用?？雌饋硎沁@樣的：()()為了把進程保存到磁盤上，我們需要終止當前的控制進程，這就意味著要彈出所有棧結(jié)構(gòu)。要做到這些，我們只有通過等待活動(Wait)和順序活動(Sequence)的實現(xiàn)去迎合這種需求，因此帶來的會是實現(xiàn)復(fù)雜程度的增加。并且這也意味著所謂“自然”（即符合人們正常思維）的模型不能夠被直接使用。JACOB的目標就是提供一個可選的“自然”的模型來解決這個問題。這個模型能夠允許執(zhí)行狀態(tài)被掛起，但是卻不需要實現(xiàn)類（如wait，Sequence）等做出特別的更改。JACOB的思想就是不使用調(diào)用堆棧，而是以來自外部的通信渠道(munication channel)來控制流程。如上所述，通道是用于流程執(zhí)行環(huán)境中活動的通信的接口。通道有終結(jié)通道(Termination Channel)，父事務(wù)范圍通道(Parent Scope Channel)和補償通道(Compensation Channel)等幾種。某些簡單的通道能使所有活動在創(chuàng)建時就能與其環(huán)境相互作用。當一個活動想要通知其的父級活動他已經(jīng)結(jié)束執(zhí)行，那么這個活動就會調(diào)用其父級活動的終結(jié)通道。通道主要由通道工廠(Channel Factory)中的動態(tài)協(xié)議提供。 Jacob對象(JacobObject)與Jacob可運行的線程狀態(tài)(JacobRunnable)如果你不在乎細節(jié)的話，那么Jacob對象和Jacob可運行的線程狀態(tài)就是方法的實現(xiàn)。當抽象執(zhí)行的時候，這個方法就會執(zhí)行。一個Jacob對象就是一個閉包。維基百科對閉包有如下解釋：“一個閉包是一組由特定文法環(huán)境約束的函數(shù)源碼。閉包文法變量與全局變量的區(qū)別在于，他們并不出現(xiàn)在全局變量的名空間。他們區(qū)別與面向?qū)ο蟮膶ο笞兞吭谟冢麄兗s束于方法，而不是對象?！币话愣訨ava語言并不支持閉包，所以Jacob對象嘗試解決這個問題。但Jacob對象的解決方案并不是一個真正意義上的閉包，而只是使問題變得簡單些。閉包在Java語言中是靜態(tài)編碼的，但是在其他大多數(shù)語言支持的閉包是動態(tài)的。所以在Jacob中，一個閉包應(yīng)當實現(xiàn)某些方法，并提供其他公共方法以控制通道和復(fù)制自身。Jacob可運行的線程狀態(tài)就是一個實現(xiàn)了run()方法的Jacob對象。因為所有的活動都繼承了Jacob可運行的線程狀態(tài)，因此這些活動都應(yīng)當在這個run()方法中實現(xiàn)他們的主要處理。他們的初始化階段在各自的構(gòu)造器中完成。 Lists (MLs)方法集Method Lists 類可以看作是通道的另一端。當只調(diào)用一個通道方法的時候，他們并不會被援引，但是一旦Jacob引擎把通道援引從其內(nèi)部堆棧中頂出來，就會援引方法集（此處能再次看到執(zhí)行堆棧是如何被中止的）。通常方法集的實現(xiàn)在預(yù)引導(dǎo)執(zhí)行環(huán)境中是內(nèi)聯(lián)的，因為這樣比較容易在活動的run方法中申明。對象方法繼承于Jacob對象，這也是一個提交方法集到Jacob的辦法。因此該Jacob運行時就能匹配后面的通道消息。(Virtual Process Unit)和執(zhí)行隊列(ExecutionQueue)虛擬處理單元VPU是所有Jacob處理發(fā)生的地方。當一個Jacob對象被注入虛擬處理單元的時候，他實際上被認為是一個持久化部分(Continuation)，該部分包裹了調(diào)用Jacob對象并執(zhí)行該對象的方法（在我們的實例中，這總是run方法，因為我們只處理Jacob可運行的線程狀態(tài)的實例）。執(zhí)行隊列（ExecutionQueue，與其實現(xiàn)FastExecutionQueueImpl）是虛擬處理單元管理的人工環(huán)境容器，并且將這些人工環(huán)境組織成可推入(push)可浮出(pop)的隊列形式，同時記錄各項執(zhí)行統(tǒng)計。所以虛擬處理單元的主要功能是從SOUP中出列一個回應(yīng)(reaction)，然后通過調(diào)用其抽象run方法來執(zhí)行他（這個回應(yīng)包裹了這樣一個抽象）。然而當Jacob可運行的線程狀態(tài)（通常是一個活動）被執(zhí)行后，有可能發(fā)生一下事情：（1）如果創(chuàng)建了別的抽象，他們就會插入回應(yīng)隊列； （2）如果創(chuàng)建了新的通道，他們就會被保存起來留給以后使用；（3）如果援引了別的通道，該信息將被保存起來以與新的ML匹配；（4）如果創(chuàng)建了一個新的方法集，那么他將被提交至虛擬處理單元以嘗試匹配一個channel援引。虛擬處理單元也負責維持其內(nèi)部狀態(tài)。因此當一個執(zhí)行暫停（例如我們的過程有一個接收活動）的時候，虛擬處理單元的狀態(tài)將序列化，作為一個持久化部分保存到磁盤，當收到繼續(xù)執(zhí)行的時候再讀入此持久化部分，繼續(xù)執(zhí)行。這個邏輯可以參考RuntimeContextImpl的execute方法。還有一點必需指出的是，持久化部分（Jacob可運行的線程狀態(tài)也是）不會“停留”在虛擬處理單元的隊列中。他們只會浮出、執(zhí)行。所以如果一個抽象有持續(xù)的并多于一個操作的時候，他會簡單的執(zhí)行，生成子活動加入隊列。Whileprocess name=while1 targetNamespace=://pxe/bpel/unittest xmlns:bpws= xmlns= xmlns:tns=://pxe/bpel/unittest xmlns:xsd=