首先,這個評論是我從網上,書中,搜索和整理出來的,也許有技術點上的錯誤點,也許理解沒那么深入。但是我是秉着學習的態度加以評論,學習,希望對大家有用,進入正題!
三大主流工作流引擎:Shark,osworkflow,jbpm!
Shark的靠山是Enhydra。Enhydra做過什么呢?多了!從j2ee應用服務器,到o/r mapping工具,到這個工作流引擎等等。為什么Shark的持久層采用DODS來實現?就是因為他們是一家人。
Jbpm的靠山是jboss。Jbpm3的持久層采用hibernate3來實現,也是因為這個原因吧。Jbpm3的圖形化流程定義已經決定嵌入到jboss eclipse IDE中,大家看看jboss eclipse IDE preview 1.5版,我們已經可以用插件方式編輯一個jbpm3流程定義文件了。
Osworkflow的靠山是opensymphony。我是非常喜歡這個組織的,它做出了很多的好東西。在開發工作流管理系統時,我就推薦用它的另外一個東西:webwork2。筆者主持的開源工作流引擎AgileFlow就是基於ww2+spring+hibernate架構實現的。寫到這里我想是不是它可以和struts2進行完美整合?!
完成本段時說句題外話:現在基本上所有的J2EE應用程序服務器都有自己的工作流引擎,如上面提到的Enhydra,jboss和沒有提到的websphere和weblogic等,可見,學習工作流引擎技術的確是非常重要的。
Shark的流程定義語言是XPDL,我們知道,XPDL的兩個最重要的概念是Process和Activity。XPDL中的Activity是基於UML1.x中的活動圖的概念。活動圖天生的適於工作流程建模,它相對於狀態圖的一個最大的優點是容易做並發線程的分叉控制,這些並發線程可以同時執行也可以順序執行;它還有一個優點是有泳道的概念,可以控制工作流引擎中的任務的產生。Shark的如來神掌是活動圖。
Osworkflow的如來神掌又是什么呢?我們知道,它有個重要概念是State……呵呵,我們知道了,它的如來神掌是FSM。不知道FSM是什么東西??那你讀大學時肯定不是好學生;當然了,不知道也不打緊,你把他類似理解為狀態圖就可以了。Osworkflow中的State是由step和status聯合表達的,一個State就是一個step中的某個status;而state的轉換由action來驅動,類似狀態圖中的event,因為一個event對應一個action嘛。
Jbpm的如來神掌就沒有上面的簡單了,它結合應用了狀態圖+活動圖+PetriNet的知識,而且,這里的活動圖還是UML2.0版的。UML2.0的活動圖中,節點不叫活動(Activity)而叫動作(action),活動成了一個高層次的概念,它包含一個動作序列。一個活動圖展現一系列的動作,這些動作組成了活動。Jbpm把action也改名了,稱為state。Jbpm使用的狀態圖的概念有transition/event等,這個自己去看吧。Jbpm來內部實現中還采用了PetriNet的概念,如token,signal等。什么?又不知道PetriNet什么東東?那你大學是學計算機的嗎?不是?那你可能是學文科的,學機械/電氣/土木工程/交通運輸等專業都有接觸PetriNet的課程,如果沒有學過,還是看看jbpm吧,反正我們也不搞理論,知道大致概念就行。
本人觀點:
做觀點是件吃力不討好的事情,好多國外的大師做的觀點也是被人罵得……我的觀點是:Shark……將登上頭號寶座。應該說,在那篇文章發表前,國內的工作流引擎使用率最高的是osworkflow;到去年年底,Shark就占有了明顯的優勢地位,我分析有如下原因:
1. 國內的企業都看中XPDL,因為這意味着在產品說明書中又可以吹牛說“我們遵循WFMC……”
2. 因為我自詡“Shark工作流引擎在國內的主要推廣者”,大部分給我反饋工作流管理系統開發選用技術的朋友都是用的Shark
3. Shark的確是一套不錯的工作流引擎,就算你只是想學習XPDL,你也可以從學習Shark開始。
4.不過我還是看好osworkflow。