前言:我计划把我的blog从51cto移到javaeye,陆陆续续地把我对工作流的理解贴上来,和大家交流。
关于工作流,我认为其基石就是工作流模型,我很久以前研究过wfmc,也在项目中应用过jbpm,我认为二者都有缺陷。我的理解如下文。
这里,以一个简单的案例讨论一下流程建模。
案例3-1:某审批业务的业务流程如下,受理科接受用户的申请,并打印相关的回
执;受理后的业务资料移送给审批科进行审批;若审批通过,则继续移交给制证科制作相
关的文书和证件;最后业务材料由档案室归档。在这里暂不考虑审批不通过的情况,也不
考虑文书和证件发放的工作。
通常,我们有如下方法对这个业务进行建模。
第一种方法:
我们可以用UML的活动图描述这个业务,如下图3-1(见附件中的3-1图):
UML活动图从业务层次精确描述了这个案例,但是,这种建模一般只用在需求分析阶段。因为现在好像还没有一个引擎可以去执行它,虽然他也可以转换为xml文件。
因此,活动图是概念层次的建模,离可执行的工作流建模有很大距离。
第二种方法:
我们可以用工作流工具对这个业务进行建模。在这里,我用自己的Bestsolution Workflow Designer(这是我很久以前写的,现在重写一遍,名字改了,叫做FireWorkflow)建立的流程模型,如下图3-2(见附件中的3-2图)。
这个模型是按照WfMC的规范建立的。
从图3-2 可以看出,用工作流设计器建立的流程模型与UML 活动图类似 。唯一的区别在于从图3-2 导出的流程定义文件(xpdl1.0 格式)是从代码执行的角度描述业务的,从而比较方便开发出一个所谓的工作流引擎来执行这个流程定义文件。
然而,WFMC 定义的工作流建模语言,以及其他许多工作流建模语言都没有回答一个根本性的问题:
用这个建模语言定义的流程真的能执行吗?能正确无误地执行吗?从我的经验看,xpdl 还缺乏逻辑严密的语义,在稍微复杂一点的情况下,它定义的流程很难正确执行。
下面我们用第三种方法建模:
如果我们把“案例3-1”所描述的审批系统分为两部分:工作流逻辑子系统和业务逻辑子系统。那么“图3-2”建立的工作流模型完全没有描述出工作流逻辑子系统需要完成哪些工作,业务逻辑子系统需要完成哪些工作;从这个意义上说,它和“图3-1”的UML活动图没有什么本质区别,都是很笼统的一个业务流程而已,只是xml 文件的DTD 有点不同。
我个人认为,
正是这种在两个子系统之间的职责的模糊与混乱导致工作流引擎无法进行正确的计算。
我们把审批系统分成工作流逻辑子系统和业务逻辑子系统。工作流子系统的操作用圆圈表示,业务逻辑子系统的操作用方框表示。如图3-3(见附件中的3-3图)
系统的执行过程如下:
首先,工作流逻辑子系统启动一个新的业务流程实例,然后启动一个新的任务“受理”,并将控制权交给业务逻辑子系统,由业务逻辑子系统完成受理工作。
第二步、受理完成后,控制权交给工作流逻辑子系统。由该子系统决定下一步的业务操作。工作流逻辑子系统根据流程定义以及相关流程变量的计算和判断,得出下一步的工作是“审批”,于是启动之,并将控制权交给业务逻辑子系统。
第三步、第四步以及后续步骤与之类似,直至最后工作流逻辑子系统计算得出流程实例应该结束,于是结束该流程实例。
图3-3 的建模似乎比图3-2 没有什么优越性,反而有点复杂,至少图形变得复杂了。但是我们如果考虑下面这种情况,那么图3-3 的建模的好处就非常明显了。在案例3-1中,我们没有考虑审批不通过的情况,现在把这种情况考虑进去,形成案例3-2。
案例3-2:在案例3-1 的基础上考虑审批不通过的情况。如果审批不通过,则需要告知申请人,然后结束业务流程。
如果我们用xpdl对案例3-2键模,则图形表示如下图3-4(见附件图3-4)
图3-4 的问题在于,业务逻辑和工作流逻辑叠加在一起,没有精确地指出到底在什么时候,由谁来决定审批之后的操作。我们可以理解为由“审批”这个环节决定后续环节是“制证”还是“告知申请人审核不通过”,这种情况下审批环节既代表了业务操作,又代表了工作流逻辑操作。当然,还有其他的执行方式,例如:计算连接“审批”到“制证”之间的狐(xpdl 称之为转移)以及联结“审批”到“告知申请人审核不通过”之间的狐得值来决定下一步的操作。总而言之图3-4并没有把业务说清楚。
如果我们用第三种方法,也就是图3-3 中的方法对案例3-2 进行建模,那么这个模型的局部如图3-5(见附件图-5)。
在图3-5 中,工作流逻辑和业务逻辑分得非常清晰,审批之后执行哪个业务操作是由工作流逻辑子系统的一个“操作”决定的。业务逻辑子系统中的“审批”操作仅仅负责完成业务特定的逻辑,其他的与之无关。
Fire Workflow正是基于这种理解而设计的,进一步,Fire workflow可以通过更加严密的数学逻辑进行证明,这一点还在完善中。。。
- 大小: 16.6 KB
- 大小: 111.9 KB
- 大小: 60.1 KB
- 大小: 32.9 KB
- 大小: 53.2 KB
分享到:
相关推荐
1. Introduction 1.1. Background Work Flow Management is a fast evolving technology which is increasingly being exploited by businesses in a variety of industries. Its primary characteristic is the ...
希望,这些规范能够使不同 种类的 WFM 产品协同工作,并提高工作流应用程序与其他 IT 服务(例如,Email、文档管理等)的集成 能力,从而工作流技术在 IT 市场中被更有效的使用,开发商与用户共同受益。
工作流引擎联盟规定的工作流引擎实现的参考模型,为工作流引擎平台提供参考规范。。。
WFMC工作流参考模型+流程定义和过程模型的交互
关于wfmc工作流标准介绍
WFMC 工作流参模型 英文版 中文版 workflow
jBPM是一款基于LGPL开源协议的开源工作流产品,它没有 采用BPEL或WFMC标准去实现流程引擎;jBPM采用的是一 套自有标准,一种轻量级的XML结构的流程描述语言JPDL, JPDL是jBPM Process Definition Language的缩写...
基于WFMC规范的工作流引擎-Java对象模型转换为DB数据模型接口的解决方案最终版.pdf
基于WFMC规范的工作流引擎——Java对象模型转换为DB数据模型接口的解决方案.pdf
本篇文档的目的是:提出支持上述文档开发的框架。为“工作流管理系统(workflow management systems...本文也讨论了,现有标准对工作流管理系统的适用性,与其他标准 IT 服务的集成性。 但本文不包含更广业务过程机制。
官方的WFMC规范文档,对工作流设计有极高的参考价值
jBPM是一款基于LGPL开源协议的开源工作流产品,它没有采用BPEL或WFMC标准去实现流程引擎;jBPM采用的是一套自有标准,一种轻量级的XML结构的流程描述语言JPDL,JPDL是jBPM Process Definition Language的缩写,相比...
wfmc工作流官方规范文档 xpdl语言的规范,最新的2.1版
进而,结合开环Jackson 排队网络理论,详细讨论了对工作流模 型进行系统静态性能分析及基于系统资源状态的连续时间马尔科夫链(CTMC)的系统动态性能分析的方法,并以 一个实例验证了作者提出的模型性能分析方法的...
WfMC定义:工作流是一类能够完全或者部分自动执行的经营过程,它根据一系列过程规则,文档信息或任务能够在不同的执行者之间传递与执行。 工作流是一种反映业务流程的计算机化的模型,实现经营过程集成与经营过程...
工作流设计开发参考资料中文版,收集整理出来的,希望能对大家有所帮助。内容包括:wfmc工作流标准--接口一;WfMC关于事件的白皮书 ;工作流标准和相关文档 ;工作流参考模型 ;工作流管理联盟规范(接口1);工作流...
符合WFMC标准的可视化JAVA版本的工作流产品简介,可轻松与第三方应用软件集成,应用范围如:银行信贷管理系统、协公办公系统、项目管理系统等等.如有需求请留言或电邮至:luckychr@163.com
2.1 WFMC对工作流的定义 12 2.2 业务流程 16 2.2.1概念 16 2.2.2 业务流程定义语言的介绍 17 2.2.3 业务流程的建立需要遵循的原则 18 2.3 工作流中间件 18 2.3.1 工作流中间件的概念 18 2.3.2使用工作流中间件的...
再加上 PHP 中没有什么好用的工作流,于是干脆自己设计一个,设计的原则 如下: 1 根据 80/20 原则,只使用 wfmc 模型中最符合自身应用的 20%功能 2 充分吸收国内使用 jbpm 开发 BOSS 中遇到的问题,工作流引擎只...
wfmc的工作流模型理论性介绍