·您的位置: 首页 » 资源教程 » 编程开发 » JAVA、JSP » 读jBpm Responsibilities

读jBpm Responsibilities

类别: JAVA教程  评论数:0 总得分:0

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



-= 资 源 教 程 =-
文 章 搜 索
关键词:
类型:
范围:
纯粹空间 softpure.com
Copyright © 2006-2008 暖阳制作 版权所有
QQ: 15242663 (拒绝闲聊)  Email: faisun@sina.com
 纯粹空间 - 韩国酷站|酷站欣赏|教程大全|资源下载|免费博客|美女壁纸|设计素材|技术论坛   Valid XHTML 1.0 Transitional
百度搜索 谷歌搜索 Alexa搜索 | 粤ICP备19116064号-1