工作流調(diào)度算法

1、工作流調(diào)度算法作者:qwerty |源自：原創(chuàng)|發(fā)表日期:2007-4-14 |閱讀次數(shù):242 |【保存文章至硬盤】【打印文章】主要比較：OBE，Shark，OSWorkflow，jBpm。分析一下他們的調(diào)度算法，就 基本上可以知道其能力有多強(qiáng)。OBE的引擎調(diào)度機(jī)制說(shuō)到開(kāi)源引擎，首先就要說(shuō)一下OBE，這是最早一款支持XPDL的開(kāi)源工作流 引擎。可惜由于沒(méi)有良好的持續(xù)維護(hù)，到如今，雖然Adrian依然還在對(duì)其進(jìn)行 一些補(bǔ)充和修改，但已經(jīng)掩飾不出其“落寞”的容顏了( HYPERLINK /james999/category/57982.aspx)%e3%80%82 /james999/categ

2、ory/57982.aspx)。OBE的引擎運(yùn)轉(zhuǎn)調(diào)度算法是很簡(jiǎn)單的，其所有的調(diào)度規(guī)則都是依據(jù)于 WorkflowRunner類的run方法。采用遍歷循環(huán)的方式，這個(gè)遍歷機(jī)制就是：/* 摘自 WorkflowRunner 類的 run 方法 */while (!_activityStack.isEmpty() /_activityStack中暫存著需要被激活的活動(dòng)實(shí)例ActivityContext ap = (ActivityContext)_activityStack.pop();_ctx.setActivityContext(ap.activity, ap.instance);/雖然叫exe

3、cute，但是其實(shí)際上是一個(gè)激活活動(dòng)實(shí)例的行為executeActivityInstance(ap.activity, ap.instance);/*在初始化任何一個(gè)活動(dòng)實(shí)例后，將這個(gè)活動(dòng)實(shí)例放A_activityStack這個(gè)堆棧 中。然后調(diào)用WorkflowRunner的run方法。在這個(gè)方法中，遍歷_activityStack 堆棧中的活動(dòng)實(shí)例，進(jìn)行運(yùn)行。*/ 但是什么情況下會(huì)激活WorkflowRunner的run呢？ StartProcess， startActivity，completeActivity，executeTransition 這些情況下，都會(huì)造成 run 的 運(yùn)行。O

4、BE的調(diào)度算法是很簡(jiǎn)單，但是執(zhí)行這個(gè)調(diào)度過(guò)程，是比較繞的。想弄 清楚到底如何運(yùn)行的，大家有必要去仔細(xì)閱讀閱讀WorkflowRunner類。從 StartProcess 方法開(kāi)始，跟蹤起 startActivity，completeActivity， executeTransition這幾個(gè)方法之間的調(diào)用關(guān)系。這樣的引擎調(diào)度機(jī)制是比較單 一的。將一些控制判斷交給了外圍的過(guò)程。引擎本身并沒(méi)有多少實(shí)際的調(diào)度，只 是一個(gè)執(zhí)行體：獲取需要執(zhí)行（激活）的活動(dòng)實(shí)例，然后執(zhí)行（激活）。工作流引擎核心調(diào)度算法與PetriNet by胡長(zhǎng)城（銀狐999）補(bǔ)充一下，OBE有 個(gè)非常值得參考和吸收的地方，就是其Li

5、stener的應(yīng)用。雖然Listener對(duì)引擎 來(lái)說(shuō)只是一個(gè)外設(shè)，但是卻為其跟蹤整個(gè)引擎得調(diào)度留下了很多可擴(kuò)展接口。當(dāng) 然OBE內(nèi)核主要是兩個(gè)類:WorkflowRunner（負(fù)責(zé)引擎調(diào)度）和EngineContext （運(yùn)行環(huán)境）Shark的引擎調(diào)度機(jī)制和OBE同樣支持XPDL的模型描繪語(yǔ)言的還有一個(gè)引擎Shark，Shark是目 前體系結(jié)構(gòu)最為龐大和完善的開(kāi)源工作流引擎。不光提供了對(duì)分布式的支持（基 于Corba），而且提供了多線程的事務(wù)安全控制。Shark的內(nèi)部調(diào)度機(jī)制也比較簡(jiǎn)單，與OBE類似。Shark的整個(gè)調(diào)度方法也基 本上是基于WfProcessImpl內(nèi)的run方法，也采用的是遍

6、歷循環(huán)的方式。只是 OBE是遍歷待激活的活動(dòng)實(shí)例，而Shark是遍歷已經(jīng)完成的活動(dòng)實(shí)例，然后往 下推進(jìn)。一一估計(jì)Shark是故意為了避免。與OBE類似，所以選擇了這么一 種算法。因?yàn)槟銜?huì)發(fā)現(xiàn)，他們的執(zhí)行推進(jìn)機(jī)制是較為相像的。Shark遍歷循環(huán)的機(jī)制是: /* 摘自 WfProcessImpl 類的 run 方法 */protected void run (SharkTransaction t, WfActivitylnternal lastFinishedActivity)如說(shuō)是啟動(dòng)流程，啟動(dòng)流程實(shí)例的時(shí)候，不指定lastFinishedActivityif (lastFinishedActi

7、vity=null) Set starts=getProcessDefinition(t).getStartingActivities();for (Iterator it=starts.iterator(); it.hasNext();) startActivity(t,asDefId,actDef,null);開(kāi)始遍歷已經(jīng)結(jié)束的活動(dòng)實(shí)例while (lastFinishedActivities.size()0) if(!state.equals(SharkConstants.STATE_OPEN_NOT_RUNNING_SUSPENDED) 執(zhí)行當(dāng)前活動(dòng)實(shí)例后續(xù)的行為queueNext(t

8、, (WfActivityInternal)lastFinishedActivities.get(0);lastFinishedActivities.remove(0); else return;/*任何一個(gè)活動(dòng)點(diǎn)完成之后（不論是Complete還是Terminate），會(huì)將自身放 入lastFinishedActivities列表中，然后調(diào)用run方法，促發(fā)對(duì)這個(gè)列表的循環(huán) 遍歷。*/有興趣對(duì)這方面研究的，可以看看WfProcessImpl內(nèi)的start、run、 activity_complete、activity_terminate 這幾個(gè)方法。工作流引擎核心調(diào)度算法與PetriNet

9、by胡長(zhǎng)城（銀狐999）從調(diào)度機(jī)制上說(shuō)，shark和obe基本雷同。甚至可以看到，其兩個(gè)運(yùn)行類都基 本上有些類似：shark 是 WfProcessImpl 類，obe 是 WorkflowRunner 類。 兩個(gè)類都是即包含了調(diào)度的前推因素（比如起動(dòng)流程實(shí)例、活動(dòng)實(shí)例結(jié)束等方 法），也包含了調(diào)度的規(guī)則運(yùn)算（run方法）。唯一不同的就是，shark是對(duì)已 經(jīng)完成的活動(dòng)實(shí)例進(jìn)行遍歷，然后前推；而OBE則是對(duì)需要激活的活動(dòng)實(shí)例進(jìn) 行遍歷，進(jìn)行前推點(diǎn)評(píng)：OBE和Shark的run調(diào)度方法，是比較常用的調(diào)度機(jī)制。首先效率上比較還 是可以，其實(shí)比較直觀，也容易理解。而且連個(gè)引擎的執(zhí)行機(jī)制有一定的雷同，

10、這可能是由于兩者都采用XPDL的緣故。但是，受他們調(diào)度機(jī)制的影響。OBE和Shark是很難支持復(fù)雜的運(yùn)轉(zhuǎn)模型，比 如“搶占模式（Workflow Pattern中叫延遲選擇）”。OSWorkflow的引擎執(zhí)行機(jī)制OSWorkflow與其說(shuō)是一個(gè)工作流引擎，不如說(shuō)是一個(gè)“可嵌入式狀態(tài)機(jī)”。其 機(jī)制并不類似于我們通常所說(shuō)的“流程”。其是以“動(dòng)作（Action）”作為驅(qū)動(dòng) 的。所以O(shè)SWorkflow用在如“bug跟蹤”等處理流程中，是非常適合的。從狹義上說(shuō)，OSWorkflow是不存在什么調(diào)度機(jī)制的。如果硬要說(shuō)的話，那么就 可以從AbstractWorkflow這個(gè)類的兩個(gè)方法來(lái)看：doActio

11、n和 transitionWorkflow。 OSWorkflow應(yīng)該說(shuō)是一個(gè)執(zhí)行機(jī)制：執(zhí)行某一個(gè)Action，并將狀態(tài)從A轉(zhuǎn)變?yōu)锽。這個(gè)狀態(tài)的轉(zhuǎn)變，可能是從一個(gè)step的某一 個(gè)status變?yōu)榱硪?status；也可能是從一個(gè)step的某一個(gè)status變?yōu)榱硪?個(gè) step 的某一個(gè) status。（注：對(duì)osworkflow 來(lái)說(shuō)，step+status 表現(xiàn)為一 個(gè)state）。在這種狀態(tài)變遷過(guò)程中，會(huì)執(zhí)行一系列的Function。當(dāng)然，OSWorkflow 有很大的靈活性取決于其Function機(jī)制。這種Function機(jī)制，有興趣的可以 參考參考。最近很多人詢問(wèn)我，是否可以將OS

12、Workflow用于他們的辦公自動(dòng)化系統(tǒng)中。其 實(shí)這方面OSWorkflow處理起來(lái)并不是很適合，通常一個(gè)OA的審批流程是很難 用OSWorkflow做的完美的。JBpm的引擎執(zhí)行機(jī)制如果大家對(duì)UML的Activity Diagram很熟悉的話，理解jBpm就易如反掌了。 在jBpm中也應(yīng)用了 Token。但是這個(gè)Token和PetriNet的概念和語(yǔ)義是不同 的。jBpm的token是用于表示任務(wù)分配給某一個(gè)actor （執(zhí)行者，可以是人、 系統(tǒng)等等）的依據(jù)，也就是說(shuō)，只有某一個(gè)actor拿到token，才有可能去執(zhí)行 任務(wù)。 當(dāng)然，由于jBpm這一塊的算法，也局限了 jBpm的復(fù)雜邏輯處理

13、。從狹義上說(shuō)，jBpm這個(gè)也不能算是什么調(diào)度機(jī)制，也只能說(shuō)是執(zhí)行機(jī)制。只是 這個(gè)執(zhí)行工作流引擎核心調(diào)度算法與PetriNet by胡長(zhǎng)城（銀狐999）機(jī)制要比OSWorkflow復(fù)雜很多。OSWorkflow的推進(jìn)執(zhí)行機(jī)制是Action的執(zhí)行，而 jBpm的推進(jìn)機(jī)制則是Token的轉(zhuǎn)移在往下閱讀閱讀的時(shí)候，大家有必要把jBpm的一些基本元素和理念搞懂?？梢?參考： HYPERLINK /james999/category/57982.aspx /james999/category/57982.aspx首先需要說(shuō)明的是，jBpm在將任務(wù)分配給某一個(gè)Actor (也就是jBpm所描述 得執(zhí)行者)的

14、時(shí)候，也會(huì)將一個(gè)Token對(duì)象分配給這個(gè)Actor。不論這個(gè)Actor 是執(zhí)行接受任務(wù)”還是提交任務(wù)”，其首選都必須獲取一個(gè)ExecutionService對(duì) 象(當(dāng)然，每一個(gè)Actor在獲取其所需要執(zhí)行的任務(wù)的時(shí)候，也就是獲取一個(gè) token對(duì)象標(biāo)識(shí)，那么這個(gè)時(shí)候，token的作用又似乎類似于我們通常所理解 的 WorkItem 意圖)。/* jBpm如何開(kāi)發(fā)調(diào)用*/ExecutionService executionService =JbpmServiceFactory.getInstance().openExecutionService(actorId);InvocationLog in

15、vocationLog = null;/如果是啟動(dòng)流程實(shí)例invocationLog =executionService.startProcessInstance( definitionId,variables,transitionName ) ;如果是結(jié)束任務(wù)State(State是jBpm的任務(wù)點(diǎn)，不要理解成了狀態(tài))invocationLog =executionService.endOfState( tokenId,variables,transitionName );當(dāng)然，看到這兒，大家一定很關(guān)心，這個(gè)Token到底是如何產(chǎn)生的? jBpm 引擎會(huì)在 start of Process

16、Instance 的時(shí)候，產(chǎn)生一個(gè) root-tokeno 并把 這個(gè)root token放入ExecutionContext中，而這個(gè)token對(duì)象會(huì)在流程實(shí)例運(yùn) 行過(guò)程中，跟隨著轉(zhuǎn)移，從而來(lái)表示任務(wù)的轉(zhuǎn)移。先來(lái)看看流程實(shí)例在ExecutionService中是如何啟動(dòng)的：/* 摘自 ExecutionServiceImpl 類的 startProcessInstance 方法 */直接構(gòu)造流程實(shí)例對(duì)象，/并且在構(gòu)造過(guò)程中，產(chǎn)生一個(gè)屬于這個(gè)流程實(shí)例的Token對(duì)象ProcessInstanceImpl processInstance = new ProcessInstanceImpl( de

17、finition );TokenImpl rootToken = (TokenImpl) processInstance.getRoot();/創(chuàng)建執(zhí)行環(huán)境對(duì)象ExecutionContextImpl executionContext =new ExecutionContextImpl( actorId, this, rootToken );獲取后續(xù)Transition，然后將當(dāng)前執(zhí)行環(huán)境賦予此轉(zhuǎn)移TransitionImpl transition =(StateImpl)definition.getStartState().getLeavingTransition( transitionNa

18、me );transition.acceptToken( executionContext );/*工作流引擎核心調(diào)度算法與PetriNet by胡長(zhǎng)城(銀狐999)又是 ExecutionContext，這一塊很多引擎都維護(hù)了一套執(zhí)行環(huán)境對(duì)象，比如OBE中的 EngineContext*/讓我們?cè)賮?lái)看看，如果一個(gè)State被結(jié)束了，那么在ExecutionService中是如何驅(qū)動(dòng)的：/* 摘自 ExecutionServicelmpl 類的 endOfState 方法 */首先需要構(gòu)造一個(gè)執(zhí)行環(huán)境對(duì)象ExecutionContextImpl executionContext =new ExecutionContextImpl( actorId, this, token );獲取Token所在的StateStateImpl state = (StateImpl) token.getState();/轉(zhuǎn)移 TokenTransitionImpl transition = state.getLeavingTransition( transitionName );transition.acceptToken( executionContext );接下來(lái)讓我們跟蹤一下Transition到底十了些什么：/* 摘自 TransitionImpl