读jBpm Responsibilities

        jBpm3.0出来十来天了，确只是前两天利用空余时间，简单翻了翻文档介绍，却实在没有时间去再去翻源码了。3.0的模型定义整体上改动不大，但扩充了很多：多了super-state，扩充了event的定义，增加了timer和exception-handler。当然还有一个最大的扩充，那就是有了基于eclipse插件的GPD（jBpm的图形化流程定义），不像2.0还是采用swing，而且2.0简直不能用。——简要了看了一下介绍，3.0的图形化就做得人性多了，总算没白被jboss收购。



哈哈，上面只是一个引子，下面才进入正题。

既然我定的题目是“读jBpm Responsibilities”，那就要从jBpm Responsibilities 说起。

（一）首先来看看jBpm的野心

jBpm是非常有野心的。也许这种野心在其2.0的时候还没有完全显露出来。但是能够被jBoss收购，看来jBoss还是很有眼光，或者也许应该说Tom大叔很有远见和野心。

下面这段话摘自jBpm Responsibilites说明：

A new proposal
The proposal below takes the best of three worlds. In short, this is how you can think of the proposed model : Finite state machines are taken as the basis. Then the concurrency features of activity diagrams are added. And at runtime, the execution semantics of petri nets are used.

        从这句话就可以看出来，jBpm要一口气通吃三种过程建模方法（算法）：利用状态机作为控制状态变迁的基础，并且扩充活动图的建模模型，执行机制采用PetriNet算法。
        当然，因为jBpm目前还仅仅定位于workflow，所以估计短时间内还不会把EPC建模方法纳入。但即使上面所说的三种过程建模方法，也足以让jBpm横扫目前所有开源工作流引擎。甚至可以毫不客气地说，其但从引擎角度来说，已经远远超越目前很多商业工作流产品。

       然而，说实在的，至少现在。我觉得这还仅仅只是Tom大叔的一个梦想。从以前分析jBpm内核代码和算法（主要是jbpm2.0版本，3.0的我还没有看）上来讲，FSM估计在jBpm是比较难应用的，除非jBpm扩充其所描述的action含义，但是这根本是不可能的。对于另外两个，Activity Diagram是jBpm的核心思想，这没地说；至于Petri Net的，jBpm是变相的用了一点，但是远达不到execution semantics这种程度。

 （二）来讲解一下Token

        把jBpm Token理解透彻了，那么也就了解一半jBpm了。
        在整个流程实例运行过程中，jBpm希望有那么一种机制，能够迅速的定位到current state。（有关current state，或者state概念，在这儿就不解释了，不懂得，自己去看jBpm帮助文档吧，这样更加直接）。
        我们知道（当然，如果你对PN熟悉的话），Petri Net利用了一种叫Token的概念，可以迅速而又准确的定位当前所处的Place和Transition，当然，对于PN来说，Token最主要的目的不是这个（而是用于使能的判断），但是却可以很有效的解决这个问题。
        而jBpm于是就借用了这个概念，引入了Token概念，我们可以迅速的利用token可以得到其当前的current state。
        但是如何解决“并行”等诸如此类的问题的迅速定位current state呢，比如splite（jBpm叫Fork）情况？ jBpm为了解决这个问题，于是让Token对象维护了父子关系，这种关系在涉及到Fork的时候会产生。这个我在《工作流引擎调度算法和PetriNet》中有关jBpm的分析中也有说明。
        jBpm让Token这个对象身兼了多种使命：（1）快速定位current state （2）用于fork,join算法 （3）用于告知任务执行者的任务索引，其职能类似于我们通常所说的workitem。
        很难说这种一身多职的方式到底好与坏，至少我发现那些国外工作流大师们好像很倾向于用这种方式，比如Alast所领导的YAWL也是。

（三）Activity、State与Action
        
         这个主题在 jBpm Responsibilities 中体现的不多，另有一篇文章专门介绍了： Why the term 'activity' should be banned... （http://jbpm.org/2/state.of.workflow.html#activityshouldbebanned）
       
        Tom大叔最经典的论证就是：its confusing because an activity is either a state or an action 。的确，在WFMC的概念中，对Activity的描述力度是不细的（所以采用了一大堆application,tool,auto,manual）这些附属概念。
        jBpm就直接很多，就只有State（所处的状态，或者说位置）和 Action（所执行的动作）。但是，估计Tom也遗忘了一个对Auto和Manual的理解。在jBpm中竟然只有State，而且这些State都是人工的，所谓的自动处理均是通过Action来完成—— 赫赫，好像jBpm这么处理，有些不近人情，至少我是很不习惯的。
        
        我是支持Activity这个概念的，但是却也非常喜欢jBpm的Action，以及OSWorkflow的Action。—— 呵呵，有些杂乱无章了。—— 至少我想在做引擎，会尽量多留些可扩展的接口，这几年实施的经验，让我不得不这样。国内的客户，保准准哪天又为提出一个你压根就像不到的需求······ 比如，猴子捞月。