一、精選部落格

1、縱觀jBPM：從jBPM3到jBPM5以及Activiti5  連結 http://www.infoq.com/cn/articles/rh-jbpm5-activiti5#

2、工作流引擎選擇（為何使用activiti而不是jbpm） 連結 http://blog.csdn.net/classfoo/article/details/20645779

3、Java工作流引擎：jBPM、Activiti以及SWF  連結 http://blog.csdn.net/liangyixin19800304/article/details/12761573

4、用OSWorkFlow和JBPM開發工作流異同  連結 http://blog.csdn.net/victor16345/article/details/5614676

二、各工作流引擎簡介

JBPM（Java Business Process Management）：JAVA業務流程管理，是一個可擴充套件、靈活、開源的流程引擎， 它可以執行在獨立的伺服器上或者嵌入任何Java應用中。

幾種工作流引擎對比：

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

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

3、jBPM5基於原先的Drools Flow，支援BPMN，通過與Drools的合併支援BAM，通過內容倉庫增加對流程視覺化的支援。由於放棄了jBPM4的PVM，引擎的可擴充套件性受到損害，並且不再支援jPDL。

4、Activiti5基於jBPM4的開源工作流系統，與Alfresco的整合增加了其流程視覺化與管理能力，同時通過創新的Activiti Cycle協作元件支援流程相關人員之間的協調，最後，它加強了整合能力。

5、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的優勢：

1、與jBPM4相比，Activiti5最令人矚目的特性就在於它的協作工具元件。

• Activiti Modeler—建模器

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

• Activiti probe—管理及監控元件

  對流程引擎執行期例項提供管理及監控的Web控制檯。包含部署的管理、流程定義的管理、資料庫表的檢視、日誌檢視、事務的平均執行時間、失敗多次的工作等功能。

2、Activiti擁有更簡潔健壯的介面

      Activiti中提供TaskQuery介面，可以設定各種查詢過濾，排序方式，最終通過list方法執行查詢，相比jbpm，它還提供了分頁查詢功能，雙方高下立判。

3、Activiti擁有更友好的使用者體驗

JBPM核心引擎完全沒有關於表單的任何抽象，它的工作機制是通過全域性常量，流程變數，任務變數，這些概念十分技術化。

相比之下Activiti則更貼近實際的應用場景，它將為開始節點，以及人工任務提供了表單設定，使用者可以設定欄位名稱，欄位型別。通過Activiti的平臺可以根據這些設定去生成表單，但如果不使用其平臺只使用引擎的話，也支援通過它來表達與第三方表單的關係。這些表單設定的後設資料資訊也可以通過介面去獲取。

4、Activiti支援啟動引擎後隨時熱部署

JBPM存在一個軟肋，一個RuntimeService只能在啟動的時候指定bpmn資源，一旦啟動後便不再能夠去更新或者增加bpmn了，這會導致我們系統整合的困難，因為我們自然希望整個系統只有一個工作流引擎例項執行。Activiti則提供了Deploy機制，將bpmn資源的熱部署，熱更新都做了很好的支援

5、Activiti擁有更友好易用的Eclipse編輯外掛和線上外掛

6、Activiti依賴更少的jar包

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

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

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

最後，總結一下：

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

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

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