工作流引擎选择(为何使用activiti而不是jbpm)

之前在选择工作流引擎时曾经在activiti和jbpm之间有过比较,当时做出的决定是使用jbpm,但实际开发过程中发现这个选择是不合适的。目前我们改为选择Activiti作为工作流模块的引擎,理由如下:

1,Activiti拥有更简洁健壮的接口

JBPM自从版本五后,便重启炉灶,完全抛弃了JBMP4的代码基础,重新基于drools进行了实现。JBPM5,JBPM6似乎缺少一个合格的系统架构师,其接口设计匪夷所思,基本上是按照drools的接口再提供了一套JBPM接口,同名的接口,实现类不断重复出现,代码体系十分混乱。

一个典型的例子,同样是查询待办事项,在JBPM中接口如下:

    List getTasksAssignedAsBusinessAdministrator(String userId, String language);
    List getTasksAssignedAsExcludedOwner(String userId, String language);
    List getTasksAssignedAsPotentialOwner(String userId, String language);
    @Deprecated
    List getTasksAssignedAsPotentialOwner(String userId, List groupIds, String language);
    @Deprecated
    List getTasksAssignedAsPotentialOwner(String userId, List groupIds, String language, int firstResult, int maxResult);
    List getTasksAssignedAsRecipient(String userId, String language);
    List getTasksAssignedAsTaskInitiator(String userId, String language);
    List getTasksAssignedAsTaskStakeholder(String userId, String language);
    List  getTasksOwned(String userId, String language);
    List  getTasksOwned(String userId, List status, String language);

上述接口设计者显然没有考虑接口的修改扩展需要,将各种复杂的查询通过一个又一个的方法提供出来,这将导致今后增加一种查询过滤就必须增加一个getXXX方法,丑陋之至,再看看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(List 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 list();
  List listPage(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资源的热部署,热更新都做了很好的支持

4,Activiti拥有更友好易用的Eclipse编辑插件和在线插件

从下图就可以看到Activiti在流程编辑上的用心,以及JBPM在流程编辑器上的漫不用心:

5,Activiti依赖更少的jar包

Activiti依赖的第三方jar包较少,主要就是mybatics,而JBPM则依赖了一大堆的jar,从drools到繁杂的hibernate,再到自身拆分的零零散散的jar包,让人不由觉得它是一个庞大的怪物。

总结:

JBPM5,JBPM6是一个巨大的失败,使用drools规则引擎来实现工作流引擎听起来是一个很酷的概念,但JBPM开发团队显然没有很好地去掌控好整个架构的变化。因此选择activiti作为工作流引擎至少在可见的几年间都是正道,今后需要实现规则库时,再单独引入drools工具包,相信drools会是一个比JBPM靠谱的工具。


你可能感兴趣的:(工作流引擎选择(为何使用activiti而不是jbpm))