jBPM是目前市場上主流開源工作引擎之一，在建立者Tom Baeyens離開JBoss後，jBPM的下一個版本jBPM5完全放棄了jBPM4的基礎程式碼，基於Drools Flow重頭來過，目前官網已經推出了jBPM6的beta版本；Tom Baeyens加入Alfresco後很快推出了新的基於jBPM4的開源工作流系統Activiti。由此可以推測JBoss內部對jBPM未來版本的架構實現產生了嚴重的意見分歧。本文試著對二者做一些比較。

主要相似之處：

都是BPMN2過程建模和執行環境。 都是BPM系統（符合BPM規範）。 都是開源專案-遵循ASL協議（ Apache的 軟體許可）。 都源自JBoss（Activiti5是jBPM4的衍生，jBPM5則基於Drools Flow）。 都很成熟，從無到有，雙方開始約始於2年半前。 都有對人工任務的生命週期管理。 Activiti5和jBPM5唯一的區別是jBPM5基於WebService - HumanTask標準來描述人工任務和管理生命週期。 如有興趣瞭解這方面的標準及其優點，可參閱WS - HT規範介紹 。 都使用了不同風格的 Oryx 流程編輯器對BPMN2建模。 jBPM5採用的是 Intalio 維護的開源專案分支。 Activiti5則使用了Signavio維護的分支。

Activiti5與jBPM5技術組成對比：

Activiti5使用Spring進行引擎配置以及各個Bean的管理，綜合使用IoC和AOP技術，使用CXF作為Web Services實現的基礎，使用MyBatis進行底層資料庫ORM的管理，預先提供Bundle化包能較容易的與OSGi進行整合，通過與Mule ESB的整合和對外部服務（Web Service、RESTful等）的介面可以構建全面的SOA應用；jBPM5使用jBoss.org社群的大多陣列件，以Drools Flow為核心元件作為流程引擎的核心構成，以hibernate作為資料持久化ORM實現，採用基於JPA/JTA的可插拔的持久化和事務控制規範，使用Guvnor作為流程管理倉庫，能夠與Seam、Spring、OSGi等整合。

需要指出的是Activiti5是在jBPM3、jBPM4的基礎上發展而來的，是原jBPM的延續，而jBPM5則與之前的jBPM3、jBPM4沒有太大關聯，且捨棄了備受推崇的PVM（流程虛擬機器）思想，轉而選擇jBoss自身產品Drools Flow作為流程引擎的核心實現，工作流最為重要的“人機互動”任務（類似於審批活動）則由單獨的一塊“Human Task Service”附加到Drools Flow上實現，任務的查詢、處理等行為通過Apache Mina非同步通訊機制完成。

優劣對比：

從技術組成來看，Activiti最大的優勢是採用了PVM（流程虛擬機器），支援除了BPMN2.0規範之外的流程格式，與外部服務有良好的整合能力，延續了jBPM3、jBPM4良好的社群支援，服務介面清晰，鏈式API更為優雅；劣勢是持久化層沒有遵循JPA規範。

jBPM最大的優勢是採用了Apache Mina非同步通訊技術，採用JPA/JTA持久化方面的標準，以功能齊全的Guvnor作為流程倉庫，有RedHat(jBoss.org被紅帽收購)的專業化支援；但其劣勢也很明顯，對自身技術依賴過緊且目前僅支援BPMN2。

總結：

雖然是比較，但不一定要有勝負，只有適合自己的才是最好的，要針對具體的專案區別對待。對我們自己的專案，其實我更關注的是流程引擎的執行效率以及效能，每小時幾十萬甚至上百萬的流程需要執行，需要多少個服務，叢集、負載的策略是什麼，會不會有衝突？目前這方面的資料還是比較少的，很多問題只有實際遇用到的時候才會去想辦法解決。不過就我個人的感覺而言，Activiti上手比較快，介面也比較簡潔、直觀，值得一試，不過jBPM6的beta版也已經出來了，不知道會有什麼變化，有興趣的也可以試下。