jBPM是目前市場上主流開源工作引擎之一，在創(chuàng)建者Tom Baeyens離開JBoss后，jBPM的下一個版本jBPM5完全放棄了jBPM4的基礎代碼，基于Drools Flow重頭來過，目前官網(wǎng)已經(jīng)推出了jBPM6的beta版本；Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統(tǒng)Activiti。由此可以推測JBoss內(nèi)部對jBPM未來版本的架構實現(xiàn)產(chǎn)生了嚴重的意見分歧。本文試著對二者做一些比較。

主要相似之處：

都是BPMN2過程建模和執(zhí)行環(huán)境；都是BPM系統(tǒng)（符合BPM規(guī)范）；都是開源項目，遵循ASL協(xié)議（ Apache的 軟件許可）；都源自JBoss（Activiti5是jBPM4的衍生，jBPM5則基于Drools Flow）；都有對人工任務的生命周期管理；Activiti5和jBPM5唯一的區(qū)別是jBPM5基于WebService - HumanTask標準來描述人工任務和管理生命周期；如有興趣了解這方面的標準及其優(yōu)點，可參閱WS - HT規(guī)范介紹；都使用了不同風格的 Oryx 流程編輯器對BPMN2建模；jBPM5采用的是 Intalio 維護的開源項目分支；Activiti5則使用了Signavio維護的分支。

Activiti5與jBPM5技術組成對比：

Activiti5使用Spring進行引擎配置以及各個Bean的管理，綜合使用IoC和AOP技術，使用CXF作為Web Services實現(xiàn)的基礎，使用MyBatis進行底層數(shù)據(jù)庫ORM的管理，預先提供Bundle化包能較容易的與OSGi進行集成，通過與Mule ESB的集成和對外部服務（Web Service、RESTful等）的接口可以構建全面的SOA應用；jBPM5使用jBoss.org社區(qū)的大多數(shù)組件，以Drools Flow為核心組件作為流程引擎的核心構成，以hibernate作為數(shù)據(jù)持久化ORM實現(xiàn)，采用基于JPA/JTA的可插拔的持久化和事務控制規(guī)范，使用Guvnor作為流程管理倉庫，能夠與Seam、Spring、OSGi等集成。

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

優(yōu)劣對比：

從技術組成來看，Activiti最大的優(yōu)勢是采用了PVM（流程虛擬機），支持除了BPMN2.0規(guī)范之外的流程格式，與外部服務有良好的集成能力，延續(xù)了jBPM3、jBPM4良好的社區(qū)支持，服務接口清晰，鏈式API更為優(yōu)雅；劣勢是持久化層沒有遵循JPA規(guī)范。

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

總結：

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