JBPM与Activity分析

1 概述

这里对现阶段市面上的几个主流工作流引擎进行对比，同时将其与FixFlow进行功能和各方面的对比。这里选定的目标是JBPM和Activit，现在两者最新稳定版本分别是JBPM5以及Activiti5。

同时这里会讲讲FixFlow这个国产工作流引擎，对于国内用户来说，使我们在几个国外工作流之外又有了更多的选择。我们可以看到国内的开源流程引擎也可以做到国际级的水平，同时还可以支持加签、会签、回退等这样的“中国式工作流”。

2 JBPM和Activiti对比

首先先看看JBPM5和Activiti5，这两者现在可以说是国内外最常见到的开源工作流引擎。如果总管两者的发展史会发现两者的奠基人都是来自于一个叫Tom Baeyens的人。所以就会发现JBPM系列和Activiti系列的风格方面有很多相似，而Activiti看起来更像是JBPM的后续发展。

2.1 从JBPM3到Activiti5

从架构层面上来看JBPM3的架构为：

从这张图可以很清晰的看出JBPM的技术架构，可以说作为一个工作流引擎应该有的成分：设计器、控制台、流程引擎、引擎数据库这几者已经明显的标注之上，在后续的各个工作流引擎中这种架构都没有颠覆性的变化。

这里我们来看一下JBPM5的架构

他引入了规则引擎Drools，规则引擎负责了整个流程引擎的运转，而知识仓库的存在。让面向流程的知识管理有了更直观的认识，事实上JBPM的代码操作几乎都是从知识库类开始的。

这张图很好的表现出了一个以BPMS为方向的流程产品应该是什么样的架

构模式。

如果说JBPM是产品经理的造物的话，那么Activiti就是技术人员的杰作，Activiti更多的精力是放在了技术架构的精妙。其易用性方面是JBPM难以比拟的。集成一个Activiti的难度要远低于JBPM，同时JBPM业务化的api体系也着实让技术人员有些头疼。

这张图就是Activiti的架构图，可以看出这张图与其说产品架构图，更有点像技术架构图。在产品层面上，其知识库的概念还没有完全突出出来。

所以说对两者来说，JBPM的产品架构很不错，而Activiti的技术架构比之要强。两者可以说各有所长，不过他们之间有一些已经确定的共识。两者其实都在往BPMS的方向前进。

2.2 优势与共同点

1.

? ? ?

如何设计流程，在组织中高效地对设计出的流程进行沟通，取得共识？

提供跨越组织的流程标准标记符号与术语（BPMN已经成为标准） 流程及相关文档的可视化（流程/内容存储仓库）

提供在组织结构内进行不同层次之间的流程导航（流程存储仓库支

持组织模型）

?

流程定义在各个层次/部门间的一致性，避免业务人员的流程建模

转换到IT系统时受到损耗（流程引擎支持基于图的建模，支持扩展）

2.

? ? ?

如何更好地执行流程？

业务活动的实时监控，预警与控制（BAM） 流程执行的仿真

流程执行的统计分析与反馈（报表）

如何更好地管理流程？

?

3.

打破各个应用系统之间的界线，统一管理所有流程（EAI，与ESB

的集成）

?

对业务人员友好的建模工具

如何在执行流程过程中遵循业内最佳实践和规则？

4.

?

面向流程的知识管理

?

规则引擎

3 FixFlow

JBPM和Activiti如此强大，那么国内也有很多厂商已经在使用了，但是在实际项目里得到的统一结果可能就是“不咋地”。这很简单，因为相比起SSH这样的框架，工作流与业务更贴近，因此对其灵活度的要求就更高。更高的灵活度就意味着更多可定制化成分。因此比如我们想造一辆汽车，SSH可以给我们的可能是生产线、发动机这样成品式的组件，而JBPM和Activiti给我们的则是油漆铁板这样的原材料。其主要问题主要在：

3.1 JBPM和Activiti的中国化

JBPM和Activiti已经被国内大量程序员所了解并加入到所使用的项目中。这两者也是国内架构人员的座上宾。

但是在使用中真的如此顺利么？笔者也曾用过这两者，也和用过两者的同行做过一些交流。我们认为这两者对于国产使用实际效果不佳。尤其在面对中国工作流需求时，两者不但没有提高更多帮助，反而使用户感觉掣肘。

3.1.1 API复杂，学习曲线高

正是由于业务的高可变性，开源的工作流引擎必须提供更多的api以供使用。这种复杂的API使程序员上手非常困难，使用者与其是被自己的业务捆住不如说是被困在寻找各种API的路上。