工作流引擎選擇（為何使用activiti）

之前在選擇工作流引擎時曾經在activiti和jbpm之間有過比較，當時做出的決定是使用jbpm，但實際開發過程中發現這個選擇是不合適的。目前我們改為選擇activiti作為工作流模組的引擎，理由如下：

1，activiti擁有更簡潔健壯的介面

jbpm自從版本五後，便重啟爐灶，完全拋棄了jbmp4的**基礎，重新基於drools進行了實現。jbpm5，jbpm6似乎缺少乙個合格的系統架構師，其介面設計匪夷所思，基本上是按照drools的介面再提供了一套jbpm介面，同名的介面，實現類不斷重複出現，**體系十分混亂。

乙個典型的例子，同樣是查詢待辦事項，在jbpm中介面如下：

listgettasksassignedasbusinessadministrator(string userid, string language);

listgettasksassigneda***cludedowner(string userid, string language);

listgettasksassignedaspotentialowner(string userid, string language);

@deprecated

listgettasksassignedaspotentialowner(string userid, listgroupids, string language);

@deprecated

listgettasksassignedaspotentialowner(string userid, listgroupids, string language, int firstresult, int maxresult);

listgettasksassignedasrecipient(string userid, string language);

listgettasksassignedastaskinitiator(string userid, string language);

listgettasksassignedastaskstakeholder(string userid, string language);

listgettasksowned(string userid, string language);

listgettasksowned(string userid, liststatus, string language);

上述介面設計者顯然沒有考慮介面的修改擴充套件需要，將各種複雜的查詢通過乙個又乙個的方法提供出來，這將導致今後增加一種查詢過濾就必須增加乙個get***方法，醜陋之至，再看看activiti的介面：

taskquery taskid(string taskid);

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(listcandidategroups);

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();

listlist();

listlistpage(int firstresult, int maxresults);

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

2，activiti擁有更友好的使用者體驗

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

相比之下activiti則更貼近實際的應用場景，它將為開始節點，以及人工任務提供了表單設定，使用者可以設定欄位名稱，字段型別。通過activiti的平台可以根據這些設定去生成表單，但如果不使用其平台只使用引擎的話，也支援通過它來表達與第三方表單的關係。這些表單設定的元資料資訊也可以通過介面去獲取。

3，activiti支援啟動引擎後隨時熱部署

jbpm存在乙個軟肋，乙個runtimeservice只能在啟動的時候指定bpmn資源，一旦啟動後便不再能夠去更新或者增加bpmn了，這會導致我們系統整合的困難，因為我們自然希望整個系統只有乙個工作流引擎例項執行。activiti則提供了deploy機制，將bpmn資源的熱部署，熱更新都做了很好的支援

5，activiti依賴更少的jar包

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

工作流引擎選擇（為何使用activiti）

工作流引擎

工作流引擎

工作流引擎

相關推薦