读jBpm Responsibilities-JSP教程,Java技巧及代码

        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了。        在整个流程实例运行过程中，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。—— 呵呵，有些杂乱无章了。—— 至少我想在做引擎，会尽量多留些可扩展的接口，这几年实施的经验，让我不得不这样。国内的客户，保准准哪天又为提出一个你压根就像不到的需求······ 比如，猴子捞月。