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