工作流程引擎技术选型：Activiti、jBPM5+

当前主流的两大工作流程引擎是 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 包，让人不由觉得它是一个庞然大物。