读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 proposalThe 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了。

补充：Jsp教程,Java技巧及代码