从JBPM3到JBPM4，兼谈其他

从JBPM3到JBPM4，兼谈其他

 

——兼作后续相关文章序

 

liuu

liuu9(a)163.com

 

JBPM是一个优秀的开源工作流框架，核心引擎算法源自PetriNet理论，并深度了集成了Hibernate作为引擎的持久框架。

 

2006年底，我开始关注JBPM，并准备作实际应用，但是当时关于JBPM的中文资料比较少，于是打算翻译JBPM官方的user guide，翻译初稿在07年上半年完成，对应的版本是V3.1.2，打算在年底利用假期完善后发出来。不过JBPM后来发布了3.2版，其文档也做了相应更新，增加了一些章节，后来工作较忙，没有继续翻译，于是也就一直没有发布。

 

后续JBPM又发布了3.3版，不过文档并没有更新，仍然采用3.2.3的版本，虽然小版本变化不大，但是这样的做法还是不值得提倡。可以说，，缺少优秀、全面的文档，一直是包括JBPM在内的，不少开源框架的通病；而像Spring、Hibernate这样框架能够成为主流，跟丰富的配套文档、教程、以及市售的铺天盖地的书籍是分不开的。虽然JBPM应用广泛，但文档太少、市场上相关书籍缺失，是限制其继续向前发展的一个不小的障碍。在翻译JBPM文档的同时，我也对其源代码进行了分析，其中就发现有一些功能，代码里已经实现，但文档中却并未提及。

 

2009年7月，JBPM正式发布了的4.0，与3.X相比，整个项目几乎重写：新的流程定义语言、新的引擎实现、新颖的PVM概念、新的配置方式、全新的开发接口、全新的数据库结构。。。。。。放眼看去，几乎JBPM4与JBPM3压根就没什么关系。另外，文档方面似乎也终于得到了更大的支持，新的官方文档分成了两部分：userguide和devguide，前者关注如何直接上手、接口使用以及流程开发，后者关注对整个架构的设计、更高级复杂的扩展开发。

 

在8月发布的最新4.1版的devguide里，说到了开发JBPM4的两个目标：

1、  改进可支持性：通过持续集成，对所支持的产品环境、配置提供更好、更长期的支持保证。

2、  降低门槛，提升应用率：区分公共基础型应用和高级定制化应用两种应用模式，让前者上手更快，后者也能减少开发难度。

 

其实，如果从这两个目的出发，可以发现，JBPM4的变化的确是遵从了这两点，而且进一步深入的分析可以得出这样的结论：尽管整个项目几乎重写，但JBPM的核心机制没有变，即本质未变。下面是devguide中列出的JBPM3与JBPM4的一些变更对照表。

 

通用名称的变化

JBPM3	JBPM4	备注
Node（节点）	Activity（活动）	根执行（root execution）和流程实例（proces instance）已经是同一个对象了；而在JBPM3里，在流程实例里有一个指向根令牌（root token）的指针。而且，跟JBPM3不同的是，即使逻辑上只有一条执行路径，在JBPM4中，该执行也可以创建一个子执行，并把自己停下来，而让子执行继续。
Token（令牌）	Execution（执行）
Action（动作）	EventListener（事件监听器）

 

JPDL XML的变化

JBPM3	JBPM4
process-defintion	process
event type=”...”	on event=”...”
action	event-listener
node	custom
process-state	sub-process
super-state	group（尚在考虑）

 

（事件机制的）默认变化

JBPM3	JBPM4
默认情况下，事件传播会触发外部流程元素的动作	默认情况下，事件传播只调用在该元素上订阅了的事件监听器，而不会调用外部元素的监听器

 

从这些变更表中，再结合新的JBPM4.1发布包的内容，可以发现，从JBPM3到JBPM4，真正的变化仅仅是：

1、  流程定义语言的模型没有改变，只是部分元素的命名发生变化

2、  流程执行引擎的算法没有改变，只是对原有引擎进行了优化，去掉了冗余的root token。JBPM4出来后，包括在JavaEye里，有不少的文档探讨了JBPM引擎的变化，有的文章分析说其核心引擎的调度机制完全不同了，这是不对的，因为还是Token机制，只是换了个名字（Execution），加上一定的优化（或称简化）。

3、  流程引擎的事件机制没有改变，只是改变了默认的事件触发范围

4、  整个数据库结构完全改变，甚至前缀变成了JBPM4，目的是希望能够跟JBPM3的表不发生冲突，甚至能够两个版本并行运行。其实数据库结构的巨大变化，是第2点变化、以及其他冗余消除的自然结果

5、  接口的变化，文档的调整和重写，只是为了更好的针对公共普通型应用和高级定制型应用，降低二者的开发难度。

 

这里提到的第2点和第4点，我有深刻的体会，因为在当时应用JBPM3的过程中，在分析JBPM3引擎的时候，也逐渐意识到其引擎存在的几个类似问题：

1、  root token其实是冗余，完全可以合并到流程实例里

2、  module instance 也是冗余的

3、  流程定义相关的表也是冗余的

4、  没有历史表

5、  。。。

 

于是从08年底到09年初，参考JBPM3和PetriNet原理，自己实现了一套新的工作流引擎，它就像一个消除了各种冗余、并增加了历史表等功能的JBPM3。在消除冗余后，除掉增加的历史表，数据库结构上比JBPM3的运行表数量减少了一半。在JBPM4发布后，我惊奇的发现，JBPM4的改动方向，跟我的方式非常相似：合并了root token和流程实例、去掉了流程定义相关表、增加了一些历史表等等。除掉历史表和集成的用户表，JBPM4的运行表数量也只有JBPM3的一半左右。可谓之殊途同归，不过虽然设计思路上类似，但实现方式还是有很大不同，因此也不能算是简单的“重复建设”或仅仅是一个“新的轮子”。对于自己实现的这个东西，希望以后进一步成熟后，有机会能够拿出来。

 

虽然JBPM4延续了JBPM3的内在，但是毕竟是一个从新设计并实现的新框架，而且JBPM4中还承载了一个更新的思想：流程虚拟机（PVM）。JBPM4虽然已经发布了两个版本4.0和4.1，但是个人认为其依然还不太成熟。而目前还存在大量的JBPM3应用，由于JBPM4对3完全不兼容，因此迁移的成本很高，跟重新开发没什么差别，所以我相信JBPM3的还会有持续使用，所以我想之前翻译的JBPM3文档应该还是有用的，或许现在已经有了一些翻译版本存在，不过没关系，只要是有用的文档，应该越多越好。如果有时间，希望能够继续翻译下JBPM4的devguide，更能多写一点实际应用的体会，以及其他任何能够有用的文章（说实在话，翻译水平还是有限，很多时候只能生硬的直译）。

 

时间，永恒之矢。技术的发展，有如奔流不息的江涛。但是总有些藏在背后的本质，引起变化的原因，推动发展的规律等等，那些我们未显见的，但却有意义的东西，是相对恒定的，要我们去把握。我们不能只盲目的求新、求变，而要看到，每一天，在太阳升起的时刻，这个世界，99%跟已经过去的一天相比，是几乎完全一样的。而持续引起和支配世界那1%变化的各种定律，从来就没有改变过。

 

是为记。

 

liuu

2009-10-01

 

评论

3 楼 ixu 2009-10-21  

可以联系我 liuu9(a)163.com
不过可能不能及时回复邮件，见谅

2 楼 xjeren 2009-10-20  

我的邮箱[e-mail]

1 楼 xjeren 2009-10-20  

我们也在用JBPM3,感觉性能不是很理想，
看了JBPM4，可是它是一个重新设计并实现的新框架，对我们需要做的改动太大，还是决定优化JBPM3，希望能得到你的指导。