对WfMC以及JBPM工作流模型的不同意见

前言：我计划把我的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可以通过更加严密的数学逻辑进行证明，这一点还在完善中。。。

评论

7 楼 nychen2000 2009-04-28  

netren 写道

期待楼主的文档：），还想请教个问题，XPDL中定义了很多元素，我感觉一般应用中好多元素是用不到的，如果要想满足XPDL这个规范，所有的元素都要实现吗，也就是说引擎都要能够解析所有这些元素吗？

我以前也比较迷信WfMC，现在我觉得适用好用是检验软件的唯一标准。既然觉得xpdl很多用不到，那就不要用了。Fire workflow的流程元素是来自于xpdl，但是改造了很多，废除了xpdl中的大部分无用的元素。

现在看来“遵守xpdl标准”之类的宣传语已经没有什么价值。

6 楼 netren 2009-04-28  

nychen2000 写道

netren 写道
审批流程我觉的可以按照XPDL的定义拆分成两个一个是一般的活动，一个是路由选择活动，按照不同的条件选择不同的分支，这样是不是就把问题拆分成业务活动和流程逻辑活动了，而且看起来比较形象，不知道斑竹的意见怎么样：） 我以前也是这么理解的，但是我现在觉得这种模型还不够好。 在现在的Fireworkflow中 ，把你所描述的“一般的活动”分解成两个元素：Activity和Task，“路由选择活动”对应Synchronizer。 其中，Activity和Synchronizer是纯粹的工作流逻辑，Task是业务逻辑。 过些时候，在1.0的文档中，我会详细阐述这种方案的优点。

期待楼主的文档：），还想请教个问题，XPDL中定义了很多元素，我感觉一般应用中好多元素是用不到的，如果要想满足XPDL这个规范，所有的元素都要实现吗，也就是说引擎都要能够解析所有这些元素吗？

5 楼 nychen2000 2009-04-27  

netren 写道

审批流程我觉的可以按照XPDL的定义拆分成两个一个是一般的活动，一个是路由选择活动，按照不同的条件选择不同的分支，这样是不是就把问题拆分成业务活动和流程逻辑活动了，而且看起来比较形象，不知道斑竹的意见怎么样：）

我以前也是这么理解的，但是我现在觉得这种模型还不够好。

在现在的Fireworkflow中 ，把你所描述的“一般的活动”分解成两个元素：Activity和Task，“路由选择活动”对应Synchronizer。

其中，Activity和Synchronizer是纯粹的工作流逻辑，Task是业务逻辑。

过些时候，在1.0的文档中，我会详细阐述这种方案的优点。

4 楼 netren 2009-04-27  

审批流程我觉的可以按照XPDL的定义拆分成两个一个是一般的活动，一个是路由选择活动，按照不同的条件选择不同的分支，这样是不是就把问题拆分成业务活动和流程逻辑活动了，而且看起来比较形象，不知道斑竹的意见怎么样：）

3 楼 zhaofw 2009-03-12  

对于通常的企业应用，物理分离的意义可能不大，但在大应用、跨应用工作流等场景下，物理分离、独立发布需要的

2 楼 nychen2000 2009-03-12  

物理分离不是办不到，但是我觉得物理分离不实用

1 楼 zhaofw 2009-03-12  

我的想法和你这篇文章中描述的非常一致。
工作流就应该是很纯粹的流程流转，具体的业务信息不应该在它上面体现。
在你下面图中的描述里，两个子系统不仅仅是逻辑分离，更应该物理分离