从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