揭秘jbpm流程引擎內(nèi)核設(shè)計(jì)思想及構(gòu)架-資料下載頁
2025-04-08 23:33本頁面
【正文】 ”這個(gè)理念，僅僅只是在“Event”中體現(xiàn)出出來。在我看來，可能的原因有兩個(gè)：（1）jBpm沒有NodeInstance這個(gè)概念。利用Token和TaskInstance，jBpm足以持久化足夠的信息，能夠讓流程實(shí)例迅速定位到當(dāng)前運(yùn)行的狀態(tài)。（2）jBpm的Event已經(jīng)很豐富，并且這個(gè)Event是圍繞“Token的轉(zhuǎn)移”而設(shè)置的，并不是圍繞Node的生命周期設(shè)置的。（3）通常我們需要在Active和Completed的生命周期內(nèi)所要操作的分支與聚合，在jBpm模型中分別由Fork、Join之類的節(jié)點(diǎn)替代。所以jBpm過分關(guān)注Node生命周期的管理意義不是非常大。作為個(gè)人，我并不行賞jBpm這樣拋棄“節(jié)點(diǎn)生命周期管理”的實(shí)現(xiàn)方式，更行賞OBE（最早的基于XPDL模型的java工作流引擎之一）的生命周期約束和管理。但是，也不得不承認(rèn)，jBpm規(guī)避了“繁瑣的狀態(tài)維護(hù)”，反而讓處理變得“簡易”，也更容易被大家所理解和接受，而這也正是OBE逐漸消失的一個(gè)原因：過于復(fù)雜和臃腫。 讓我們在前面那張jBpm的“調(diào)度機(jī)制思維圖”上，再稍稍補(bǔ)充一點(diǎn)（為了突出顯示，與上圖有所改動(dòng)）。這張圖應(yīng)該可以很好的詮釋出，jBpm是如何執(zhí)行各種節(jié)點(diǎn)的，這也是得益于OO的“多態(tài)與繼承”特性。 jBpm的執(zhí)行機(jī)制非常簡單，但還是需要稍微補(bǔ)充一下有關(guān)“分支”方面的處理。jBpm采用sub token的機(jī)制來解決分支方面的處理：當(dāng)遇到有分支的時(shí)候，會(huì)為每個(gè)分支節(jié)點(diǎn)創(chuàng)建一個(gè)child token。在聚合節(jié)點(diǎn)（Join或Merge），則依賴其同步或異步的聚合方式，來分別處理。比如我們參看Fork節(jié)點(diǎn)的執(zhí)行代碼（為了突出重點(diǎn)，省略部分代碼）：public void execute(ExecutionContext executionContext) { Token token = ()。 Iterator iter = ()。 while (()) { String transitionName = (String) ()。 (createForkedToken(token, transitionName))。 } iter = ()。 while( () ) { //省略部分代碼 ExecutionContext childExecutionContext = new ExecutionContext(childToken)。 leave(childExecutionContext, leavingTransitionName)。 }} protected ForkedToken createForkedToken(Token parent, String transitionName) { Token childToken = new Token(parent, getTokenName(parent, transitionName))。 forkedToken = new ForkedToken(childToken, transitionName)。 return forkedToken。}至于Merge節(jié)點(diǎn)，我想此處不用在累贅的展示，有興趣的，可以參看Merge類的execute方法，即可。9 jBpm內(nèi)核結(jié)構(gòu)與實(shí)例對象 Jbpm引擎內(nèi)核的結(jié)構(gòu)非?！熬啞?。除了我們上面所說的那些定義對象（各種Node節(jié)點(diǎn)和Transtion），還有幾個(gè)與“運(yùn)行實(shí)例”相關(guān)的對象。如下圖所示。（1）我們需要描述一個(gè)流程實(shí)例，所以需要一個(gè)ProcessInstance對象。（2）每個(gè)流程實(shí)例，都會(huì)維護(hù)一套屬于其自己的“執(zhí)行環(huán)境”，也就是ExecutionContext對象。注意，這里是一套，而不是一個(gè)。10 后記上半年寫了些bpm和SOA的文章，也被csdn的好友拉著忽悠了不少這方面的概念，弄的好像我開始搞這方面的工作似的。其實(shí)不然，本質(zhì)工作與這有“天壤之別”，完全是非常底層的java技術(shù)應(yīng)用。而workflow，也有兩三年沒有從事這方面的開發(fā)了，所以寫此篇文章，著實(shí)費(fèi)了點(diǎn)功夫。想痛痛快快寫篇有關(guān)“引擎內(nèi)核”的文章，這個(gè)想法由來以及了，卻擔(dān)心自己不足以詮釋清楚，反而容易誤導(dǎo)他人，遂中途多次放棄。正如前面所說的那樣，引擎內(nèi)核的實(shí)現(xiàn)，并沒有一套“固定的模式”或者“固定的實(shí)現(xiàn)體系”，會(huì)因?yàn)楹芏嘁蛩囟斐蓪?shí)現(xiàn)不同。如果想把“引擎內(nèi)核”的實(shí)現(xiàn)真正詮釋清楚，必須把這些相關(guān)因素都詮釋明朗——但這依然是一個(gè)浩大的工程。前些日子，受朋友所托，為他們的公司學(xué)員講了幾節(jié)工作流的課程，期間嘗試jBpm來詮釋了一下引擎的實(shí)現(xiàn)思路，發(fā)現(xiàn)效果不錯(cuò)?！艽艘l(fā)，遂萌發(fā)了以jBpm為實(shí)例，來簡單詮釋“流程引擎內(nèi)核”想法。耗時(shí)一周的業(yè)余時(shí)間，雖然還很難詮釋自己的全部想法，但“點(diǎn)出幾個(gè)要點(diǎn)”，還是應(yīng)該有了。12 /
公司管理相關(guān)推薦
鄂ICP備17016276號-1