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)的触发。这样实例列表的查询可以只查询历史库。不过这里很遗憾的是,这个事件没有同时清除运行库的数据,这样还是会造成运行库的无限膨胀问题。
分享到:
相关推荐
本文将对JBPM和Activiti进行深入的分析,并与国内的工作流引擎FixFlow进行对比。 #### 二、JBPM与Activiti对比分析 ##### 2.1 架构特点 **JBPM架构** JBPM采用了模块化的设计思路,其架构主要包括以下几个部分:...
文件名为"纵观jBPM:从jBPM3到jBPM5以及Activiti5.doc",与标题一致,预示着文档内容会深入探讨jBPM的历史发展,以及在不同版本中的演变,同时可能有对比Activiti5的部分。 **详细知识点可能包括:** 1. **jBPM3**...
jbpm和shark工作流引擎对比 本文对jbpm和shark工作流引擎进行了深入的比较,涵盖了稳定性、易用性、灵活性、可监管性、扩展性和可维护性等多方面。工作流引擎是企业信息化建设中非常重要的一环,选择合适的工作流...
【jBPM5与Activiti5的对比】 jBPM5在设计上更注重面向业务人员,增强了BPMS特性,如支持BPMN2.0标准,提供业务规则集成,以及更强大的流程模拟和监控能力。与此同时,Activiti5作为jBPM的一个分支,保留了jBPM4的...
2. 集成应用:讲解如何将jBPM4与Spring、Hibernate等常见框架集成,实现业务逻辑与流程控制的无缝结合。 3. 流程持久化:解释jBPM4如何存储和恢复流程实例的状态,确保流程的持久性。 4. 测试与调试:提供测试策略和...
这些天,想着把jbpm4.4与ssh2整合一下,由于之前从来没用过jbpm,也不知道各版本之间会有什么差异(经过网上的收集对比,还真有些差异),整合起来,还真是有些步履艰难。收集了不少别人的整合资料和源码,但是最终...
3. **创建流程图**:使用流程图工具(如Jbpm本身的Designer或第三方工具如PlantUML),根据JPDL文件中的信息手动或自动生成图形化表示。每个节点需要在图上正确放置,转换线连接它们,确保流程的逻辑清晰可见。 4. ...
"工作流比较分析报告.pdf"很可能是一份深入的研究报告,它对比了jbpm与其他工作流引擎的优缺点。这样的报告对于选择合适的工作流解决方案至关重要,因为它提供了各种选项的性能、易用性、社区支持等方面的评估。通过...
本篇文章将深入探讨两种流行的Java工作流引擎——jbpm和ccbpm,并对比它们的特点、功能以及适用场景,旨在帮助开发者更好地理解这两种工具。 jbpm是一款开源的工作流引擎,由JBoss社区开发,它提供了完整的BPM解决...
3. **工作流引擎**:它是jbpm的核心,负责执行流程实例,包括启动流程、执行活动、处理分支和合并、以及完成任务。 4. **持久化**:jbpm使用Hibernate作为默认的持久化机制,确保流程实例和相关数据在系统重启后仍...
该研究采用工作流模式框架,不仅比较了这些开源系统的功能特点,还与 Staffware、WebSphere MQ 和 Oracle BPEL PM 这三款商业 BPM 系统进行了对比分析。 根据研究结果,可以得出以下几点结论: 1. **目标用户群体**...
4. **环境与兼容性** 该流程实例是在JBoss-IDE 1.6环境下测试通过的,特别指出它适用于jbpm3.1版本。原文中的流程不适用于jbpm3.1,因此进行了相应的修改和优化。 5. **学习资源** 原文来源于...
jbpm则由JBoss公司开发,其最新版本jbpm3采用了Hibernate3作为持久层,这也是由于二者同属JBoss生态系统的缘故。jbpm3的一大亮点是其图形化流程定义已整合到JBoss Eclipse IDE中,开发者可以通过插件轻松编辑流程...
3. **持久化机制**:JBPM使用Hibernate作为默认的持久化层,确保流程实例、任务状态等数据能够安全存储和恢复。 4. **任务管理**:包括任务分配、任务处理和任务查询等功能,支持自定义任务工作流,以适应不同业务...
3. **版本控制**:系统可以记录每次设计的修改,便于回溯和对比不同版本的流程模型。 4. **协同编辑**:多人可以同时在线编辑同一个流程图,增强了团队协作效率。 5. **兼容BPMN标准**:遵循Business Process ...
4. 如果问题仍然存在,检查Eclipse Designer插件的配置,确保其内部处理XML文件的编码设置与Eclipse的工作空间设置一致。 5. 使用Eclipse的“Compare with”功能对比正常和乱码的gpd.xml文件,找出差异,可能有助于...
- **jBPM 3**: 包含了所有必要的文件和文档,适用于初学者和开发者。 - **jPDL Process Designer**: 单独提供,专注于流程设计的功能。 #### 2.2 项目目录结构 了解JBPM项目的目录结构对于开发和定制非常重要,通常...
- 对比分析了GOP与其他编程模型的优势和劣势。 ##### 7.3 GOP与Petri网比较 - **Petri网** 是另一种常用于描述和分析并发系统的模型。 - 两者之间的主要区别在于表达能力和易用性。 #### 八、应用领域 ##### 8.1 ...