jbpm3与jbpm4实现对比

jBPM3 vs jBPM4

JBoss Goup 目前已经发布了 jBPM4 Alpha1 版本，在版本 4 中最大的变化就是引入 PVM （流程虚拟机）的概念，而引擎内部的调度算法中重要的 Token 机制，在新版中也去掉了，纵观整个代码，变化可以说非常的大，笔者接下来就试着来比较一下这种变化，让大家能有个直观的认识。当然 Jbpm4 在 JBoss 的官方网站上的 Road map 中，在今年的 7 月 1 号才会发布第一个正式版本，因此后续可能还会有变化。

1、   流程定义对象的变化：

Jbpm3 流程定义对象关系图：

图一 jbpm3流程定义对象关系图

 

从上图我们可以看出这 jbpm3 中， GraphElement 是流程图中所有流程元素的父对象，而整个流程是由 ProcessDefinition 、 Node 、 Transition 三个主要对象构成；

 

 图二 PVM 实体对象关系图      

 

 

从上图可以看出，由于 PVM 概念的引入，所以在 jbpm3 中的 Graph 包在 jbpm4 中被移除了。在 pvm 中，在设计期，所有节点元素的父类为 ProcessElementImpl ，流程的主要组成元素 Nodelmpl 、 TransitionImpl 、 ProcessDefinitionImpl 、 EventImpl 则都直接或间接继承自 ProcessElementImpl 。在运行期： jbpm4 把流程的运行期行为定义为执行行为（ ExecutionImpl ）及原子操作行为（ AtomicOperation ，其具体实现为 ExecuteNode 、 ProceedToDestination 、 TakeTranstion 、 MoveToParentNode 、 MoveToChildNode 、 signal ），其中 ExecutionImpl 是流程实例、活动实例、事件监听器的所有执行期行为的实现类。

 

图三 jpdl 运行期活动实体对象关系图

  上图是 jbpm4 在运行期的活动实例对象关系图，从图中我们可以看出，在运行期， jbpm4 中定义了两个活动接口 Activity 和 ExternalActivity ，其中 ExternalActivity 继承自 Activity 。 Activity 是所有自动活动节点的父接口，其实现类为 JpdlActivity ，而 JpdlActivity 又衍生出了、 StartActivity 、 JoinActivity 、 ForkActivity 、 EndActivity 、 CreateTimerActivity 、 JavaActivity 、 EsbActivity 等实例活动对象。而 ExternalActivity 是具有等待状态的活动（ StateActivity ）父接口，像人工活动 TaskActivity 就是实现了此接口。

  2、   核心引擎的调度算法

Jbpm3 的核心调度算法是基于 Token 机制的，在运行期这个 Token 在 Node Instance 之间流转，依靠 Token 的触发来推进流程。具体的调度机制，可参加胡长城的文章（ http://blog.csdn.net/james999/archive/2007/09/02/1769592.aspx ）；其实这个 Token 来自于 Pertri-net ，感兴趣的读者可以去看 Pertri-net 中的 Token 及 Place 。

 

图四 jbpm3引擎调度图  

Jbpm4 则去掉了 Token ，那么它的核心调度机制是怎样实现的呢？

 图五 jbpm4流程启动序列图

图六 jbpm4 流程推进序列图

图五是在 jbpm4 中启动一个流程实例的执行序列图，图六是节点推进的执行序列图，从上面两个图中我们可以看到核心的调度是依据 Execution 的转移来实现的（ ExecutionImpl 可以是 ActivityExecution 、 ClientProcessInstance 、 EventListenerExecution 的实例）， Execution 实际上就是取代了 Jbpm3 中的 Token ， Execution 的转移实际上就是根据状态机的变迁（ ActivityExecution 、 ClientProcessInstance 、 EventListenerExecution 实例之间的切换）加上调用相应的原子操作： ExecuteNode 、 MoveToChildNode 、 MoveToParentNode 、 ProceedToDesitination 、 Signal 、 TakeTransition （详见 pvm/internal/model/op 包下的相关类）来实现的。所以 Execution 实例的集合及有向图实际上就是运行期的路径。

 

3、   Event-Action 机制的变化

在 jbpm3 中是基于 Event-Action 机制来实现事件与动作的触发的，但是在 jbpm4 中则采用观察者模式来触发事件的。所有用户自己定义的动作，全部要实现 EventListener 接口，这些动作作为监听者（就是事件 Event 的观察者 Observer ）注册到相应的流程定义对象上（ ProcessElement 或者 Node ），而事件 Event 则作为被观察的对象（实际上就是 Observerable ），实际上在 jbpm4 中专门定义出了一个对象 ObservableElementImpl ，流程定义中的 NodeImpl 、 TransitionImpl 、 ProcessDefinitionImpl 均继承自此对象，因此这些元素本身就可以作为 Observerable 而被观察者来监控。

4、   客户端接口的变化

在jbpm4中对客户端的接口统一为7个服务接口：ProcessService、ExecutionService、CommandService 、TaskService 、ManagementService、HistoryService、IdentityService，这7个接口可以从ProcessEngine接口中获得，jbpm4在启动的过程中由JbpmConfiguration负责构建引擎。

Ø  ProcessService-流程定义的服务接口，包括对流程定义的部署、查询、删除操作；

Ø  ExecutionService-执行服务接口，包括启动流程、实例推进、设置变量等操作；

Ø  CommandService-Command模式的服务接口，实际上就是将客户端的请求全部封装在一个调用接口中，然后由这个接口去调用Command接口的众多实现（StartExecutionCmd、SignalCmd、SetVariablesCmd、GetTimersCmd、DeployCmd、NewTaskCmd、SubmitTask、ExecuteJobCmd等等，具体可参加pvm/internal/cmd，task/internal/cmd包及其它包下实现Command接口的类），这是典型的Command模式的应用，感兴趣的读者可以去了解设计模式中的Command模式；

Ø  TaskService-人工活动的服务接口，包括对任务的创建、提交、查询、保存、删除等操作；

Ø  ManagementService-web管理控制台的服务接口，目前只有获得消息及计时器的接口实现；

Ø  HistoryService-目前有对历史库中的流程实例、活动实例进行查询、某个流程定义中的所有活动的平均持续时间、某个流程定义中的某个活动实例的转移的执行次数

Ø  IdentityService-用户、组、成员关系的相关操作方法

 

5、 历史库的加入

jBPM3中数据库设计一直是我比较诟病的地方，尤其是其实例数据库没有设计历史库的概念并按照办结状态将运行结束的实例数据归入历史库，在这种情况下它的实例数据库就会随着时间而无限膨胀，这就阻碍了它的真实应用，而在jBPM4的最新代码中（注意Alpha1还没有出现），历史库的相关功能代码竟然出现了！详见ExecutionImpl最新代码中的fireHistoryEvent方法及一系列的historyXXX方法。在ActivityBehaviour的execute方法中加入了historyTaskStart方法的调用、signal方法中加入了historyTaskEnd方法的调用，而以上2个方法在ExecutionImpl中都是以历史事件（HistoryEvent有4个实现子类ProcessInstanceStart、ProcessInstanceEnd、ActivityStart、ActivityEnd分别用作流程实例的创建结束期、活动实例的创建结束期的历史数据处理）的触发机制来实现的，也就是在整个流程实例执行的过程中，都加入了对将运行数据存入历史库的历史事件（HistoryEvent）的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是，这个事件没有同时清除运行库的数据，这样还是会造成运行库的无限膨胀问题。

 

评论

13 楼 snowfox2008 2009-02-17  

147175882 写道

如沐清风啊,不过我一直都不是很明了PVM的存在.因为不用PVM程序也可以执行下去,不知道楼主是怎么理解PVM的?

PVM是屏蔽流程语言的，例如你可以在jBPM4上运行xpdl，pvm把流程语言的特性给屏蔽了，如果没有PVM，你就只能运行jPDL语言的流层定义

12 楼 ynstudio 2009-02-17  

高手！
我也在研究jbpm4。我们的工作流就基于jbpm4来做的，不过现在才开始流程管理之类的功能的开发。

11 楼 supercwg 2009-02-17  

jbpm 4 是不是不支持 Spring 啊？？？ 好像都没有看到关于jbpm的技术架构文档介绍的

10 楼 147175882 2009-02-17  

如沐清风啊,不过我一直都不是很明了PVM的存在.因为不用PVM程序也可以执行下去,不知道楼主是怎么理解PVM的?

9 楼 rmn190 2009-02-17  

谢谢楼主分享！

8 楼 kjj 2009-02-17  

学习jbpm 中，以前看过3 ,脑袋都看大了，还用的jsf ，其中概念贼多，看了4 ，感觉到非常清晰，呵呵，有前途,这个应该会是个产品版了，但愿这次设计中能加入回滚功能！是回退流程容易一些！

7 楼 whaosoft 2009-02-17  

变化不小@@@

6 楼 snowfox2008 2009-02-17  

5、历史库的加入
jBPM3中数据库设计一直是我比较诟病的地方，尤其是其实例数据库没有设计历史库的概念并按照办结状态将运行结束的实例数据归入历史库，在这种情况下它的实例数据库就会随着时间而无限膨胀，这就阻碍了它的真实应用，而在jBPM4的最新代码中（注意Alpha1还没有出现），历史库的相关功能代码竟然出现了！详见ExecutionImpl最新代码中的fireHistoryEvent方法及一系列的historyXXX方法。在ActivityBehaviour的execute方法中加入了historyTaskStart方法的调用、signal方法中加入了historyTaskEnd方法的调用，而以上2个方法在ExecutionImpl中都是以历史事件（HistoryEvent有4个实现子类ProcessInstanceStart、ProcessInstanceEnd、ActivityStart、ActivityEnd分别用作流程实例的创建结束期、活动实例的创建结束期的历史数据处理）的触发机制来实现的，也就是在整个流程实例执行的过程中，都加入了对将运行数据存入历史库的历史事件（HistoryEvent）的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是，这个事件没有同时清除运行库的数据，这样还是会造成运行库的无限膨胀问题。

大家对此的意见呢？

5 楼 miqingyang 2009-02-16  

变化很大，功能更强大了，又要好好看看jbpm了

4 楼 snowfox2008 2009-02-16  

呵呵，你说的没错，我这个描述是基于它的发布版本Alpha1的，而你说的最近版本，我在svn上（http://anonsvn.jboss.org/repos/jbpm/jbpm4/trunk）也下来看过了，那两个类的名字确实是改了，但是方法声明没有任何变化。

对于PVM就是专门来屏蔽不同流程语言的差异的，呵呵要不也不叫VM了，VM这个东西可不是随便叫的。而功能扩展起来也是很强大，例如基于Command模式，我们很容易的扩展出收回、会签等功能，接下来我会专门写一个基于jBPM4的扩展机制如何扩展出我们想要的功能，而对原有代码不做任何侵入的文章，而这个也会在我们的开源项目jBPM-side中一一实现。

3 楼 beeke 2009-02-16  

楼主你这个API老了
今年一月份有个大修改：
Activity 和 ExternalActivity 改成了ActivityBehaviour和ExternalActivityBehaviour
而Node改成了Activity

在我看来，jbpm4和jbpm3没啥关系，内核基本都重写了
而基于pvm的设计有很强的扩展性。甚至你可以使用自己的流程描述语言去代替jpdl。
实际上，基于pvm的jpdl实现代码总共也不过100k

2 楼 snowfox2008 2009-02-16  

呵呵，第4部分，客户端接口的变化的一部分在拷贝的时候，竟然丢掉了一部分，现已补全。

1 楼 linliangyi2007 2009-02-16  

好文，楼主加油。