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

 

好文，楼主加油。

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

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

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

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

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

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

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

大家对此的意见呢？

变化不小@@@

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

谢谢楼主分享！