jBPM3 vs 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）的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是，这个事件没有同时清除运行库的数据，这样还是会造成运行库的无限膨胀问题。

关于JBPM工作流

1.        工作流

       工作流是一项分离业务操作和系统流程的技术。工作流由实体 (Entity)、参与者 (Participant)、流程定义 (Flow Definition)、工作流引擎 (Engine) 四部分组成。

l 实体是工作流的主体，是需要随着工作流一起流动的物件 (Object)。例如，在一个采购申请批准流程中，实体就是采购申请单；在公文审批流程中，实体就是公文。

l 参与者是各个处理步骤中的责任人，可能是人，也可能是某个职能部门，还可能是某个自动化的设备；

l 流程定义是预定义的工作步骤，它规定了实体流动的路线。它可能是完全定义的，即对每种可能的情况都能完全确定下一个参与者，也可能是不完全定义的，需要参与者根据情况决定下一个参与者；

l 工作流引擎是驱动实体按流程定义从一个参与者流向下一个参与者的机制

      前三个要素是静态的，而第四个要素是动态的，它将前三者结合起来，是工作流的核心组成元素。

 

2.        JBPM

       jBPM，全称是 Java Business Process Management，是一种基于 J2EE的轻量级工作流管理系统。

n  jBPM的一个特色是采用了它自己定义的 JBoss jBPM Process definition language (jPdl)。 jPdl认为一个商务流程可以被看作是一个 UML状态图。 jPdl就是详细定义了这个状态图的每个部分，如起始、结束状态，状态之间的转换等。

n  jBPM的另一个特色是它使用 Hibernate来管理它的数据库。 Hibernate是目前 Java领域最好的一种数据持久层解决方案。通过 Hibernate， jBPM将数据的管理职能分离出去，自己专注于商务逻辑的处理。

 

JBPM工作流的应用分析

jbpm工作流步骤：

1、 加载（发布）流程定义

这个意思是，我们通过 jbpm的 designer插件，或者是用其他工具，制定出 processDefinition

，然后将其加载到应用中的过程。这个加载可以是写入内存中，或者是直接写入数据库等。

2、 启动流程

创建流程实例的过程。具体创建实例的方法有多种，可根据自己的需要自行选择。

3、 处理任务

在流程流转的过程中， JBPM引擎会为我们生成任务的实例，我们就需要针对这些任务实例来进行处理，然后结束这些任务实例，并推动流程的流转。

4、 记录流程的相关状态

记录流程状态这点包括且不限于以下内容：

1）流程实例的开启

2）任务实例的创建

3）任务实例的开始执行

4）任务实例的结束

5）流程实例的结束

 

使用jBPM的优势

将业务流程复杂的系统结构清晰话，提供系统运行时的灵活性

1、 解耦系统业务流程

流程独立，可以使用工具定义和建模，利于跟踪、监控、管理、调度、优化和重整

2、 提高系统的灵活性

系统流程定义生产环境的修改和调整，用户和外部工具交互，任务的动态分派

 

使用jBPM时的问题

1、  对当前任务的条件查询

jBPM不提供灵活进行条件查询的 api，如果需要，可以自定义 hibernate查询，从 jbpm相应的数据表中查询任务数据。但需要对 jBPM机制比较了解，而且有些复杂条件难以用 jBPM本身的信息查到。

2、  当前任务的分页

在上一问题的基础上，使用 hibernate分页。

3、  统计各个流程实例的状态

可以通过流程实例，在 jbpm系统表中查询，也可以在业务表的相应数据上加上状态列来统计。前一个比较麻烦，后一个比较直观，但不会因使用 jBMP而使用工作量减少。

4、  工作流数据与业务数据结合

一般通过在流程实例中添加相应的一笔数据的标识作为变量来关联。也可以有针对性的扩展 jbpm的系统表来实现与业务的关联性。

5、  修改流程后的历史数据兼容性问题

Jbpm工作流流程定义有版本的概念，修改流程后要重新发布，与旧的流程不是一个同一个版本。系统可以区别开新旧流程来。

结论

1、  工作量

初步的结论是：引入工作流技术不会明显减少系统开发工作量。相反，在一般情况下，会增加一部分工作量。

如果项目流程比较少，而且比较固定，则使用工作流技术会明显增加开发工作量。

如果项目流程多，而且比较复杂，则使用工作流技术会使项目结构层次更加清晰、更具有扩展性，根据需求有可能要修改和扩展现有开源工作流类库与数据库结构，也会增加额外的工作量。但权衡之下，利大于弊。

2、  关于业务数据与 jBPM 本身的数据

理论上说，如果使用 jBPM，可以将所有业务数据放到 jBPM的 context中管理，不再维护业务数据表。但这样的结果是在流程之外的环境（比如在统计报表中）中无法容易的得到业务数据。所以一般会建立业务数据表，我不使用工作流时一样，然后让 jBMP从业务数据表中得到业务数据，而不在 jBPM中保留业务数据。因此，使用 jBPM后，在业务数据方面基本不会减少工作

 

3、  工作流学习成本

工作流本身的概念较复杂，使用 jbpm，需要学习其工作流的定义和结构，流程定义工具和语言、了解其数据结构。与其它工作流产品（如 Shark）相比， jBPM对 Java开发人员来说学习较低成本，在做流程复杂的项目时，学习成本可以接受。

 

4、  系统用户和角色与工作流整合

流程的流转和任务的分派完成，都是用户在控制，所以需要将用户、角色和权限整合到 jbpm工作流中。

 

5、  系统业务的整合和调整

将流程抽取后，原本连续的业务处理变成一个个的任务节点。需要在每个业务相关处理处添加工作流流程控制、在每个节点处实现相关的业务和流程切入点。

 

 

6、  适用范围

Jbpm工作流适用于：

n 项目流程比较多，流程复杂的项目。

n 系统运行和维护、升级时，流程可能需要修改、调整和跟踪、控制的项目。