当前主流的两大工作流程引擎是 Activiti 和 jBPM5+ (包括 jBPM5、jBPM6、jBPM7)，本文主要介绍它们的特性及优劣。
一、概念
JBPM，全称是 Java Business Process Management (业务流程管理)，它是覆盖了业务流程管理、工作流、服务协作等领域的一个开源的、灵活的、易扩展的可执行流程语言框架，它可以运行在独立的服务器上或者嵌入任何 Java 应用中。
Activiti 的技术前身是 jBPM3、jBPM4，是基于 jBPM4 设计的衍生版本，采用了 PVM (流程虚拟机，一种可嵌入的、原生的支持多流程语言的独立技术)。
而恰恰相反，JBPM 从版本5以后，放弃了 jBPM4 的基础代码，重启炉灶，基于 Drools Flow 来实现。由于放弃了 jBPM4 的 PVM，引擎的可扩展性受到损害。
二、技术组成对比
| 技术组成 | Activiti | jBPM5+ |
|---|---|---|
| 数据持久/ORM框架 | MyBatis3 | Hibernate3 |
| 持久化标准 | 无 | JPA规范 |
| 事务管理 | MyBatis机制/Spring事务控制 | Bitronix，基于JTA事务管理 |
| 数据库连接方式 | Jdbc/DataSource | Jdbc/DataSource |
| 支持数据库 | Oracle、SQL Server、MySQL等多种数据库 | Oracle、SQL Server、MySQL等多种数据库 |
| 设计模式 | Command模式、观察者模式等 | |
| 内部服务通讯 | Service间通过API调用 | 基于Apache Mina异步通讯 |
| 集成接口 | SOAP、Mule、RESTful | 消息通讯 |
| 支持的流程格式 | BPMN2、xPDL、jPDL等 | 目前仅支持BPMN2 xml |
| 引擎核心 | PVM(流程虚拟机) | Drools规则引擎 |
| 技术前身 | jBPM3、jBPM4 | Drools Flow |
| 所属公司 | Alfresco | jBoss.org |
Activiti 使用 Spring 进行引擎配置以及各个 Bean 的管理，综合使用 IOC 和 AOP 技术，使用 CXF 作为 Web Service 实现的基础，使用 MyBatis 进行底层数据库 ORM 的管理，预先提供 Bundle 化包能较容易与 OSGi 进行集成，通过与 Mule ESB 的集成和对外部服务(Web Service、RESTful 等)的接口可以构建全面的 SOA 应用。
jBPM5+ 使用 jBoss.org 社区的大多数组件，以 Drools Flow 作为流程引擎的核心组件，以 Hiberneta 作为数据持久化 ORM 实现，采用基于 JPA/JTA 的可插拔的持久化和事务控制规范，使用 Guvnor 作为流程管理仓库，能够与 Seam、Spring、OSGi 等集成。
需要指出的是 Activiti 是在 jBPM3、jBPM4 的基础上发展而来的，是原 jBPM 的延续，而 jBPM5+ 则与之前的 jBPM3、jBPM4 没有太大关联，且舍弃了备受推崇的 PVM (流程虚拟机)思想，转而选择 jBoss 自身产品 Drools Fow 作为流程引擎的核心实现，工作流最为重要的“人机交互”任务(类似于审批活动)则由单独的一块“Human Task Service”附加到 Drools Flow 上实现，任务的查询、处理等行为通过 Apache Mina 异步通讯机制完成。
三、优劣对比
- 1.从技术组成上看，Activiti 最大的优势是采用了 PVM (流程虚拟机)，支持了除 BPMN2 规范之外的流程格式，与外部服务有良好的集成能力，延续了 jBPM3、jBPM4 良好的社区支持，服务接口清晰，链式 API 更为优雅；劣势是持久化没有遵循 JPA 规范。
- 2.jBPM5+ 最大的优势采用了 Apache Mina 异步通讯技术，采用 JPA/JTA 持久化方面的标准，以功能齐全的 Guvnor 作为流程仓库，有 RedHat (jBoss.org 被红帽收购)的专业化支持；但其劣势也很明显，对自身技术依赖过紧且仅支持 BPMN2。
四、技术选型
比较不一定要有胜负，要针对具体的项目区别对待，只有适合自己的才是最好的。对于我个人而言，会偏向于 Activiti，除了上手容易外，还有以下几方面的考量：
- 1.Activiti 拥有更简洁健壮的接口
Activiti 中提供 TaskQuery 接口，可以设置各种查询过滤、排序方式，最终通过 list 方式执行查询，相比 jBPM5+，它还提供了分页查询功能。 - 2.Activiti 拥有更友好的用户体验
虽然 JBPM 和 Activiti 都是使用 bpmn 格式作为流程定义语言，但二者都相应的利用了 bpmn 格式的规范扩展了一些自定义的功能，根据这些扩展它们都提供了自己的绑定表单的方式。jBPM5+ 核心引擎完全没有关于表单的任何抽象，它的工作机制是通过全局常量、流程变量、任务变量，这些概念十分技术化。相比之下，Activiti 则更贴近实际的应用场景，它将为开始节点，以及人工任务提供了表单设置，用户可以设置字段名称、字段类型。通过 Activiti 的平台可以根据这些设置去生成表单，但如果不适用其平台只使用引擎的话，也支持通过它来表达与第三方表单的关系。这些表单设置的元数据信息也可以通过接口去获取。 - 3.Activiti 支持启动引擎后随时热部署
jBPM5+ 存在一个软肋，一个 RuntimeService 只能在启动的时候指定 bpmn 资源，一旦启动后便不能再去更新或新增 bpmn 了，这会导致我们系统集成的困难，因为我们自然希望整个系统只有一个工作流程引擎实例运行。Activiti 则提供了 Deploy 机制，将 bpmn 资源的热部署、热更新等都做了很好的支持。 - 4.Activiti 拥有更友好易用的 Eclipse 编辑插件和在线插件
- 5.Activiti 依赖更少的依赖包
Activiti 依赖的第三方 jar 包较少，主要是 mybatis 依赖，而 jBPM5+ 则依赖了一大堆的 jar 包，从 drools 包繁杂的 hibernate，再到自身拆分的零零散散的 jar 包，让人不由觉得它是一个庞然大物。
转载于:https://www.jianshu.com/p/aeda3317e971