縱觀jBPM：從jBPM3到jBPM5以及Activiti5：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5#
工作流引擎選擇（為何使用activiti而不是jbpm）：http://blog.csdn.net/classfoo/article/details/20645779
Java工作流引擎：jBPM、Activiti以及SWF：http://blog.csdn.net/liangyixin19800304/article/details/12761573
用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控制台。包含部署的管理、流程定義的管理、數據庫表的檢視、日志查看、事務的平均執行時間、失敗多次的工作等功能。
- Activiti probe—管理及監控組件
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：還有不能支持太復雜的流程
原文地址：https://blog.csdn.net/tianzongnihao/article/details/80286193