工作流引擎activiti和jbpm哪個比較好？

在常用的ERP系統、OA系統的開發中，工作流引擎是一個必不可少的工具。之前在選擇工作流引擎時曾經在activiti和jbpm之間有過比較，當時做出的決定是使用jbpm，但實際開發過程中發現這個選擇是不合适的。目前我們改為選擇Activiti作為工作流子產品的引擎，理由如下：

1、Activiti擁有更簡潔健壯的接口

JBPM自從版本五後，便重新開機爐竈，完全抛棄了JBMP4的代碼基礎，重新基于drools進行了實作。JBPM5，JBPM6似乎缺少一個合格的系統架構師，其接口設計匪夷所思，基本上是按照drools的接口再提供了一套JBPM接口，同名的接口，實作類不斷重複出現，代碼體系十分混亂。

一個典型的例子，同樣是查詢待辦事項，在JBPM中接口如下：

List<TaskSummary> getTasksAssignedAsExcludedOwner(String userId, String language);

List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, String language);

@Deprecated

List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, String language);

@Deprecated

List<TaskSummary> getTasksAssignedAsPotentialOwner(String userId, List<String> groupIds, String language, int firstResult, int maxResult);

List<TaskSummary> getTasksAssignedAsRecipient(String userId, String language);

List<TaskSummary> getTasksAssignedAsTaskInitiator(String userId, String language);

List<TaskSummary> getTasksAssignedAsTaskStakeholder(String userId, String language);

List<TaskSummary> getTasksOwned(String userId, String language);

List<TaskSummary> getTasksOwned(String userId, List<Status> status, String language);
           

上述接口設計者顯然沒有考慮接口的修改擴充需要，将各種複雜的查詢通過一個又一個的方法提供出來，這将導緻今後增加一種查詢過濾就必須增加一個getXXX方法，醜陋之至，再看看Activiti的接口：

TaskQuery taskName(String name);

TaskQuery taskNameLike(String nameLike);

TaskQuery taskDescription(String description);

TaskQuery taskDescriptionLike(String descriptionLike);

TaskQuery taskPriority(Integer priority);

TaskQuery taskMinPriority(Integer minPriority);

TaskQuery taskMaxPriority(Integer maxPriority);

TaskQuery taskAssignee(String assignee);

TaskQuery taskAssigneeLike(String assigneeLike);

TaskQuery taskOwner(String owner);

TaskQuery taskOwnerLike(String ownerLike);

TaskQuery taskUnassigned();

TaskQuery taskUnnassigned();

TaskQuery taskDelegationState(DelegationState delegationState);

TaskQuery taskCandidateUser(String candidateUser);

TaskQuery taskInvolvedUser(String involvedUser);

TaskQuery taskCandidateGroup(String candidateGroup);

TaskQuery taskCandidateGroupIn(List<String> candidateGroups);

TaskQuery processInstanceId(String processInstanceId);

TaskQuery processInstanceBusinessKey(String processInstanceBusinessKey);

TaskQuery processInstanceBusinessKeyLike(String processInstanceBusinessKeyLike);

TaskQuery executionId(String executionId);

TaskQuery taskCreatedOn(Date createTime);

TaskQuery taskCreatedBefore(Date before);

TaskQuery taskCreatedAfter(Date after);

TaskQuery excludeSubtasks();

TaskQuery taskVariableValueGreaterThan(String name, Object value);

TaskQuery processDefinitionName(String processDefinitionName);

TaskQuery withoutDueDate();

TaskQuery suspended();

TaskQuery orderByTaskAssignee();

TaskQuery orderByProcessInstanceId();

TaskQuery orderByDueDate();

long count();

U singleResult();

List<U> list();

List<U> listPage(int firstResult, int maxResults);

}           

同樣是查詢待辦事項，Activiti中提供TaskQuery接口，可以設定各種查詢過濾，排序方式，最終通過list方法執行查詢，相比jbpm，它還提供了分頁查詢功能，雙方高下立判。

2、Activiti支援啟動引擎後随時熱部署

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

**

3、Activiti擁有更友好易用的Eclipse編輯插件和線上插件**

從下圖就可以看到Activiti在流程編輯上的用心，以及JBPM在流程編輯器上的漫不用心：

4、Activiti依賴更少的jar包

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

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

雖然JBPM和activiti都是使用bpmn格式作為流程定義語言，但二者都相應地利用了bpmn格式的規範擴充了一些自定義的功能，根據這些擴充它們都提供了自己的綁定表單的方式。JBPM核心引擎完全沒有關于表單的任何抽象，它的工作機制是通過全局常量，流程變量，任務變量，這些概念十分技術化。

相比之下Activiti則更貼近實際的應用場景，它将為開始節點，以及人工任務提供了表單設定，使用者可以設定字段名稱，字段類型。通過Activiti的平台可以根據這些設定去生成表單，但如果不使用其平台隻使用引擎的話，也支援通過它來表達與第三方表單的關系。這些表單設定的中繼資料資訊也可以通過接口去擷取。

總結：

JBPM5，JBPM6使用drools規則引擎來實作工作流引擎聽起來是一個很酷的概念，但JBPM開發團隊顯然沒有很好地去掌控好整個架構的變化。是以選擇activiti作為工作流引擎至少在可見的幾年間都是正道，今後需要實作規則庫時，再單獨引入drools工具包，相信drools會是一個比JBPM靠譜的工具。

如果JAVA底子差一點的話可以用XJR快速開發架構，采用主流的Activiti工作流引擎，遵循bpmn規範，可實作XML、Json一鍵導入導出，以及添加了人員動态選擇、便捷式會簽設定、便捷式任務委托設定、添加自定義表單、自定義節點按鈕、動态變量選擇（包括會簽變量、按鈕變量、表單變量）以及各節點屬性優化，遵循以使用者為中心的優化原則，将整個流程的操作變得簡單、快捷，實作0基礎短時間可自由編輯流程模闆。