幾大工做流引擎對比

 

幾種工做流引擎對比：

 

一、jBPM3是一個完整的工做流系統實現，面向開發人員，目的在於簡化對組織核心流程進行支撐的軟件建立，不支持標準。

二、jBPM4引入PVM，使其擁有更強大的擴展性，同時增長BPMS特性，這些特性包括了對BPMN的支持、面向業務人員的Web建模器和簡單統計分析功能的加入。

三、jBPM5基於原先的Drools Flow，支持BPMN，經過與Drools的合併支持BAM，經過內容倉庫增長對流程可視化的支持。因爲放棄了jBPM4的PVM，引擎的可擴展性受到損害，而且再也不支持jPDL。

四、Activiti5基於jBPM4的開源工做流系統，與Alfresco的集成增長了其流程可視化與管理能力，同時經過創新的Activiti Cycle協做組件支持流程相關人員之間的協調，最後，它增強了集成能力。

五、SWF與其說是工做流引擎，不如說是分佈式計算調度框架，SWF中只包括Task和History兩部分，甚至是每一個Task之間若是要傳遞一些數據的話，都只能經過第三方存儲（好比Message Queue或者Redis），不過這也給了編程更大的靈活性，問題是這種靈活性是否是很是須要。

一個SWF由Worker和Decider組成，Worker執行實際的任務，而Decider進行流程控制，二者嚴格上來說沒有區別，只是所執行的任務不一樣罷了。每一個Worker和Decider會按期的去SWF的一個Task List取下一個任務。能夠看出來這更像是一個「多線程」的結構，而SWF官方網站的Use Case是NASA的火星探索計劃中須要處理圖片的系統，這其實也是一個更多側重於計算的系統，流程反而很是簡單。

另外，SWF（Simple Workflow）的一個Workflow不能太複雜，由於全部的流程控制都集中於Decider，若是太複雜的話Decider將無比龐大，給維護和擴展帶來必定的困擾。

Activiti的優點：

一、與jBPM4相比，Activiti5最使人矚目的特性就在於它的協做工具組件。

 

• Activiti Modeler—建模器

  基於開源Signavio Web流程編輯器的一個定製版本，提供了對BPMN2.0圖形化規範的支持，建模後的流程以文件格式進行存儲。

   

  • Activiti probe—管理及監控組件

    對流程引擎運行期實例提供管理及監控的Web控制檯。包含部署的管理、流程定義的管理、數據庫表的檢視、日誌查看、事務的平均執行時間、失敗屢次的工做等功能。

二、Activiti擁有更簡潔健壯的接口

Activiti中提供TaskQuery接口，能夠設置各類查詢過濾，排序方式，最終經過list方法執行查詢，相比jbpm，它還提供了分頁查詢功能，雙方高下立判。

三、Activiti擁有更友好的用戶體驗

JBPM核心引擎徹底沒有關於表單的任何抽象，它的工做機制是經過全局常量，流程變量，任務變量，這些概念十分技術化。

相比之下Activiti則更貼近實際的應用場景，它將爲開始節點，以及人工任務提供了表單設置，用戶能夠設置字段名稱，字段類型。經過Activiti的平臺能夠根據這些設置去生成表單，但若是不使用其平臺只使用引擎的話，也支持經過它來表達與第三方表單的關係。這些表單設置的元數據信息也能夠經過接口去獲取。

四、Activiti支持啓動引擎後隨時熱部署

JBPM存在一個軟肋，一個RuntimeService只能在啓動的時候指定bpmn資源，一旦啓動後便再也不可以去更新或者增長bpmn了，這會致使咱們系統集成的困難，由於咱們天然但願整個系統只有一個工做流引擎實例運行。Activiti則提供了Deploy機制，將bpmn資源的熱部署，熱更新都作了很好的支持

五、Activiti擁有更友好易用的Eclipse編輯插件和在線插件

六、Activiti依賴更少的jar包

Activiti依賴的第三方jar包較少，主要就是mybatics，而JBPM則依賴了一大堆的jar，從drools到繁雜的hibernate，再到自身拆分的零零散散的jar包，讓人不禁以爲它是一個龐大的怪物。

 

 

工做流有版本的概念，jBPM和Activiti上傳一個新的版本後，版本號會增長1，舊版本還沒執行完的流程實例還會繼續執行。SWF的版本是個字符串，隨意指定好了，這樣也很好，字符串名稱更明確。

 

嵌入式部署即將流程引擎嵌入部署於Web應用中

 

最後，總結一下：

shark：系統和功能都比較複雜

Osworkflow：比較靈活的輕量級的框架，可是在流程建模方面不太友好，須要手動編寫xml文件去定義流程文件。

SWF：還有不能支持太複雜的流程