淺談jBPM5與Activiti之間的差別對比

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）；都有對人工任務的生命週期管理；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是在jBPM三、jBPM4的基礎上發展而來的，是原jBPM的延續，而jBPM5則與以前的jBPM三、jBPM4沒有太大關聯，且捨棄了備受推崇的PVM（流程虛擬機）思想，轉而選擇jBoss自身產品Drools Flow做爲流程引擎的核心實現，工做流最爲重要的「人機交互」任務（相似於審批活動）則由單獨的一塊「Human Task Service」附加到Drools Flow上實現，任務的查詢、處理等行爲經過Apache Mina異步通訊機制完成。

 

 優劣對比：

從技術組成來看，Activiti最大的優點是採用了PVM（流程虛擬機），支持除了BPMN2.0規範以外的流程格式，與外部服務有良好的集成能力，延續了jBPM三、jBPM4良好的社區支持，服務接口清晰，鏈式API更爲優雅；劣勢是持久化層沒有遵循JPA規範。

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

總結：

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