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