揭秘jbpm流程引擎內(nèi)核設(shè)計(jì)思想及構(gòu)架-文庫吧資料
2025-04-14 23:33本頁面
【正文】 e創(chuàng)建工人任務(wù)。public Token(ProcessInstance processInstance) { = processInstance。（注：以下所有參考代碼，為了突出主題，都已經(jīng)將實(shí)際代碼中的event,log等處理刪除）public ProcessInstance( ProcessDefinition processDefinition ) { = processDefinition。 以下截取部分代碼實(shí)現(xiàn)，僅供參考。 7 jBpm的過程調(diào)度機(jī)制 Net思想 jBpm的過程調(diào)度機(jī)制是吸納了Petri Net的一些思想。 節(jié)點(diǎn)的類型和擴(kuò)展我們可以通過定義自己的Node節(jié)點(diǎn)對象，來補(bǔ)充jbpm自定的節(jié)點(diǎn)對象。如下圖所示：這是一張非常標(biāo)準(zhǔn)的“活動圖”，如果我們用jbpm的設(shè)計(jì)器，看看這樣一張“流程圖”：不論你如何繪畫，改變不了這張圖的本質(zhì)：它就只有兩個(gè)基本元素：節(jié)點(diǎn)和轉(zhuǎn)移。 流程：節(jié)點(diǎn)與轉(zhuǎn)移的組合 僅利用節(jié)點(diǎn)和轉(zhuǎn)移的組合，就可以表達(dá)一個(gè)“過程（Process）”。但是jBpm的節(jié)點(diǎn)是沒有這樣的屬性的，或者說的更準(zhǔn)確些，是Activity Diagram模型的節(jié)點(diǎn)沒有這樣的特性。可能有的人會說，還需要關(guān)心節(jié)點(diǎn)的轉(zhuǎn)入轉(zhuǎn)出的類型，比如And Splite或者Xor Join之類。這個(gè)節(jié)點(diǎn)可能是start state，也可能是一個(gè)task node，或者是一個(gè)fork。jBpm采用的是Node和Transition來表示“節(jié)點(diǎn)”和“有向弧”。那么這套定義對象也需要從最基礎(chǔ)的“抽象”說起。因?yàn)檫@個(gè)定義對象是屬于Engine Kernel的一部分。流程引擎就需要把“xml格式的流程定義”解析為一套對象，而這套對象的結(jié)構(gòu)則反映了流程的結(jié)構(gòu)。當(dāng)然，jBpm也有自己的一套，名為jPDL，也是一個(gè)xml格式的。利用這個(gè)描述語言可以描述一個(gè)流程的定義。在WfMC的Workflow Reference Model中，對流程引擎的功能描述，其中就包含一項(xiàng)：解析流程定義。jBpm采用了Activity Diagram的模型語義：其將用Start State、State、Action State（Task Node）、End State、Fork、Join、Decision、Merge、Process State這幾個(gè)“元素”的組合來描述任何一個(gè)流程。而是如何去解決“形式化的描述一個(gè)流程”的問題。 但是，當(dāng)你試圖修改jbpm代碼的時(shí)候，你會顧慮jbpm的LGPL協(xié)議嗎？（很多國內(nèi)企業(yè)從來不考慮這個(gè)協(xié)議問題，寒）。西方人認(rèn)為“往回流轉(zhuǎn)的情況肯定也是一種業(yè)務(wù)規(guī)則所定義，那么肯定可以通過分支或條件來解決”，而東方則把“回退作為一個(gè)人性化管理和處理的潛在特點(diǎn)”。這一點(diǎn)可能是東西方文化的差異性所在，因?yàn)閲鴥?nèi)的流程應(yīng)用，比較關(guān)注“運(yùn)行軌跡”。所以本質(zhì)上就不支持“multiinstance”模式。（1）很顯然，只能有一個(gè)startstate。 當(dāng)然，還有一些優(yōu)點(diǎn)，是很多開發(fā)人員并不太注意的，比如：（1）jbpm的Node機(jī)制非常靈活，開發(fā)人員可以很容易定制“業(yè)務(wù)化語義的節(jié)點(diǎn)”，并滿足運(yùn)行時(shí)候處理的需要。（4）jbpm提供了可擴(kuò)展的Task及分配機(jī)制，來滿足復(fù)雜人工活動的處理。（2）jbpm提供了可擴(kuò)展的EventAction機(jī)制，來輔助活動的擴(kuò)展處理。自從被Jboss收購之后，整個(gè)結(jié)構(gòu)完全本著“微內(nèi)核”的思想進(jìn)行設(shè)計(jì)。jBpm采用了Activity Diagram的模型，而osworkflow則是FSM的模型。（3）一些臨時(shí)的“執(zhí)行”信息，便于引擎針對某種情況進(jìn)行處jbpm，“精簡”的開源流程引擎. 好的開源工作流引擎不多，jbpm和osworkflow算是其中兩個(gè)有特色而且比較容易實(shí)際應(yīng)用的。基本上實(shí)例對象會包含如下信息：（1）與流程實(shí)例的狀態(tài)或控制信息（2）與活動實(shí)例的狀態(tài)或控制信息。之所有有時(shí)候我們會把一個(gè)流程引擎也叫做“狀態(tài)機(jī)”，很大程度上也是這個(gè)原因。經(jīng)過引擎的調(diào)度，實(shí)例運(yùn)行到某個(gè)節(jié)點(diǎn)了，此時(shí)必須必須提供一套機(jī)制，來判斷當(dāng)前節(jié)點(diǎn)是否可執(zhí)行，如果可執(zhí)行，那么需要提供一套runtime envrioment來執(zhí)行節(jié)點(diǎn)——這就是引擎的執(zhí)行機(jī)制。 jBpm本身就吸納的token這套機(jī)制，當(dāng)然，與Petri Net的調(diào)度機(jī)制還是有所區(qū)別。引擎的調(diào)度機(jī)制有很多種實(shí)現(xiàn)方法，有的甚至是與“所依賴的模型有關(guān)”。比如jBpm的定義對象，是與其所基于的Activity Diagram模型相對應(yīng)的。工作流引擎本身就是一種“base on model”的組件，流程實(shí)例的執(zhí)行都是依賴于所定義的“流程定義”，而工作流引擎則是提供了這樣一種環(huán)境，來維持流程實(shí)例的運(yùn)行。（3）流程執(zhí)行問題：當(dāng)流程運(yùn)行到某個(gè)節(jié)點(diǎn)的時(shí)候，需要一套機(jī)制來解決：是否執(zhí)行此節(jié)點(diǎn)，并如何執(zhí)行此節(jié)點(diǎn)的問題，并維持節(jié)點(diǎn)狀態(tài)生命周期。總的來說，引擎內(nèi)核主要關(guān)注四個(gè)方面的問題： （1）流程定義問題：不是說如何圖形化的定義流程，而是如何用一套定義對象，來詮釋所定義的流程。4 擎內(nèi)核所關(guān)注的四個(gè)主要問題引擎內(nèi)核所關(guān)注的是一個(gè)非?！俺橄蟆睂用娴膯栴}，而不同引擎關(guān)注的“一套完整的執(zhí)
公司管理相關(guān)推薦
鄂ICP備17016276號-1