在常用的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基础短时间可自由编辑流程模板。
