资源模式唱罢、控制模式登场

我们知道，一个商业目标的实现必定由一系列 的活动组成，这些活动的编排即构成了以目标为导向的业务流程。管理的目标即通过合理有效的编排这些活动以期以最少的成本达到最大的收益。这个编排的过程亦 即进行业务流程建模的过程。在进行业务流程建模时反复出现的活动结构构造即产生了模式。在本章中，我们将讨论工作流的控制模式。控制模式关注业务流程中活 动的编排，一方面强调与实际业务的契合，另一更为重要的方面则是如何合理调配这些活动。

 

本章讨论的控制模式共计 43种。需要注意的是，这些模式的出发点是基于对实际业务进行描述的，与具体的工作流系统没有太大的关联。而一个工作流系统对工作流模式的支持程度则直接决定了该系统对业务的建模能力。所以在某种程度上，衡量一个合适的工作流系统时，往往会考虑其对工作流模式的支持程度。

 

本章讨论的控制模式按照描述、应用和实现展开，分别对应着模式的介绍、模式对实际业务的映射和工作流产品对该模式的实现支持。最后是小结。作为约定，我们将业务流程里的活动映射为任务，将对活动的建模描述映射为任务节点。

 

一、       基本控制模式

基本控制模式包括 5个模式，是其他控制模式的基础。

 

1、顺序（ WCP_01: Sequence ）

描述

在同一个流程实例里，任务会在前续任务完成后顺序触发。

图 4-1

如图 4-1所示，任务 A执行完毕后会顺序触发任务 B的执行，任务 B执行完毕后会顺序触发任务 C的执行。

 

同义词

顺序执行、串行路由。

 

应用

顺序模式是工作流建模的基础，是流程定义里最基本的构建块，用以描述连续串行的一系列任务，这些任务之间的触发是无条件的。

顺序模式也是实际的业务中应用最多的模式， 当实现一个业务价值需要执行多个任务时，最自然的方式就是排序并顺序完成这些任务，典型的如流水线作业。当企业人数不多，业务模式简单（不需要过多的任务 或任务之间存在很强的线性依赖关系），管理成本很低时，顺序模式是最自然的选择。

 

2、并发分裂（ WCP_02: Parallel Split ）

描述

分支分裂为两个或多个后续分支，当分支执行完毕后触发后续并发分支的同时执行。并发的分支有可能在后续合并为一个分支，也可能不合并。

 

图 4-2

如图 4-2所示，任务 A完成后将同时触发任务 B和任务 C的执行，任务 B和任务 C的执行不存在前后关系。

 

同义词

AND-split、 Fork、并行路由、并行分裂。

 

应用

在传统的软件开发里，开发过程被典型的分为了 5个阶段，如下图所示：

 

图 4-3

这 5个 阶段是顺序执行关系，典型的当需求分析完毕后会有一个需求冻结状态，在这种状态下才开始正式的软件设计和实现。该模式最大的弊端在于在需求分析阶段不可能 捕获用户所有可能的需求，而且客户的需求是变化的，开发阶段由于需求冻结对于客户完全黑盒，导致最后的交付无法实现客户期望的业务价值。

在敏捷开发里，开发过程由多个迭代组成，在每个迭代里，需求分析、架构设计、编码开发、测试和交付都是同时进行的，客户参与到这个过程中，客户能够从不断的交付中提出新的需求，这样软件才能够更好的响应变化，不至于在最终交付时出现业务价值的偏差。

 

图 4-4

其实从某种角度上看，不同企业的组织管理结构也决定了它所采用的业务流程模式。在图 4-3所 示的开发流程里，每个阶段都对应于不同的部门，需求分析有专门的业务部门，开发部门内部分为了架构部门、开发部门和测试部门，交付则又有专门的实施团队， 在这种情况下，从管理的成本考虑，顺序执行无疑是最自然和最便宜的选择（这也是为什么在传统企业里实施敏捷困难的原因之一）。

而在敏捷开发团队里，整个团队则是围绕开发流程建立，减少了内部不必要的协调沟通成本，能够达到相对较高的执行效率。

 

实现

由于后续分支的触发是无条件的，所以在很多工作流产品的实现里省去了 AND-split节点，直接由任务节点进行分支分裂，如下图 4-5所示：

 

图 4-5

jBPM使用 token记录当前流程实例执行的位置并触发流转，建立起 token的父子关系。如下图所示，在 AND-split节点每个并发的分支都会产生一个新的子 token，当子 token到达 AND-join节点后即可通过其访问到它的父 token，再通过父 token遍历其子 token即可获得当前并发分支的执行情况并实现合并。

 

图 4-6

作为约定，我们在后续的说明中，将会采用 token来指代当前流程实例所执行的位置。

 

3、同步（ WCP_03: Synchronization ）

描述

两个或多个分支合并为一个后续分支，当被合并的分支都执行完毕后，后续分支才被触发。

 

图 4-7

如上图所示，当任务 A和任务 B都完成后，才会触发任务 C的执行。

 

同义词

AND-join、汇聚、同步。

 

应用

在实际的应用中， AND-split节点与 AND-join节点一般成对出现。

在任何时候，总结总是有必要的，每次迭代开发结束后，我们都会进行迭代小结，写出应该改进的部分、应该保持的部分，以保持整个团队的迭代前进。

实际上，很多情况下 AND-split节点和 AND-join节点往往隐含着管理意义，上一级的管理者在 AND-split节点进行任务的管理和下发，在 AND-join节点对任务执行结果进行负责。

 

实现

和 AND-split节点一样，在部分工作流产品里，直接采用任务节点进行分支合并，如下图所示：

 

图 4-7

jBPM里，分支的合并实际是 token的合并，子 token生命周期终止，父 token重新激活。

 

4、排他选择（ WCP_04: Exclusive Choice ）

描述

分支分裂为两个或多个后续分支，当分支执行完毕后只能选择触发一个后续分支执行，即多选一。

 

图 4-9

如上图所示，任务 A完成后将会选择触发任务 B或任务 C的执行，任务 B和任务 C之间只能选择一个执行。

 

同义词

XOR-split、排他 OR-split、条件路由。

 

应用

流程里的决策任务。会存在两种决策方式：人为决策和系统决策。由人或一组系统设定条件根据流程执行情况作出后续执行路径的选择。

 

实现

两种实现方式，一种是在 XOR-split节点定义路由选择条件（图 4-10）、一种是在后续转移线上定义触发条件（图 4-11）。

 

图 4-10

 

图 4-11

条件的计算有多种方式：工作流变量与相应条件定义值简单匹配、提供接口由具体实现类返回计算结果、规则引擎进行规则匹配计算。同时，当存在多个后续分支和条件判断时，一般会定义一个默认执行分支。

 

5、简单合并（ WCP_05: Simple Merge ）

描述

两个或多个分支合并为一个后续分支，任何一个分支执行完毕后就会触发后续分支的执行，不需要同步，遵循先进先出的原则。需要注意的是：该模式有个前提条件，即前续分支有且只有一个会执行。

 

图 4-12

如上图所示，任务 A或任务 B只要有一个完成都会触发任务 C的执行，但是任务 A和任务 B有且只有一个可以执行。如果任务 A和任务 B都有可能执行，则变为另外一个模式：多合并模式（ WCP_08）。

 

同义词

XOR-join、排他 OR-join、 merge。

 

应用

在实际的应用中，为保证该模式的前提条件，一般 XOR-join节点与 XOR-split节点成对使用。

 

实现

和 AND-join节点一样，因为不需要任何条件判断，所以在部分工作流产品里，直接采用任务节点进行分支简单合并，但是需要和 AND-join做出区别，如下图所示：

 

图 4-13

6、基本控制模式小结

基本控制模式非常简单，实现起来也没有太大的难度。需要注意的是，对于一种模式往往会存在多种实现方式，笔者的建议是：将条件判断的节点独立出来，由其负责条件计算和路径选择，而任务节点则只关注于实际业务的执行，做到职责分离。例如， AND-split、 AND-join、 XOR-split和 XOR-join节点都会单独存在。

可以看到：除去 AND-split和 AND-join节 点，顺序、排他选择、简单合并模式组合的流程和我们编写程序的逻辑流程图非常的相似，也就是这三种模式能够对程序的逻辑流程图进行建模。于是一件有意思的 事情出现了：有快速开发平台产品使用流程引擎来编排程序逻辑。他们的做法是将细粒度的代码逻辑封装为运算构件，然后再通过流程的可视化编辑器将这些运算构 件粘合起来。这样，传统方式下采用代码实现业务逻辑的过程变成了画流程图的过程。笔者认为这样的实现存在相当大的弊端，相当不合理。首先，编写代码变得复 杂了，明明几十行代码能够实现的逻辑却需要经过编写构件、绘制程序流程图、部署、运行好多步才能实现，编程效率可以想象；其次是代码的执行效率低，程序的 运行需要经过一次流程定义的解释才能执行；然后是这种实现完全牺牲了语言自身的特性，面向过程，很难提供代码级别的单元测试环境，只能提供有限的调试。该 实现实际上是定义了一种简单的流程语言，通过该流程语言来进行功能函数（运算构件）调用的编排。任务编排没有问题，服务编排也没有问题，但是如果编排细粒 度到功能函数，那么就超出了流程引擎的作用域。提升编程效率的最好途径总是语言而不是工具。

评论

13 楼 ronghao 2009-12-01  

BlueAeri 写道

还有就是提两点建议：

1、术语能否更加标准或贴切一点？比如“并发分裂”，更多的使用“并行分支”或“平行拆分”，个人感觉“并行分支”比较贴切。

2、模型标注图形能否采用BPMN标准呢？个人觉得那样会更好。

可以参考：
工作流模式的 WebSphere Integration Developer V6 实现，第 1 部分: 12 个基本的工作流模式简介：
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0707_chenbing/

工作流模式的 WebSphere Integration Developer V6 实现，第 2 部分 : 9 个高级的工作流模式简介：
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0803_weishan/

非常感谢你的建议！

我们后期会对所有的术语进行统一，但是这里因为后面有很多分裂模式，所以选择了“并发分裂”，前后会比较一致

标注图形最开始是想过BPMN，可能是出于易于理解的考虑吧，直接使用了现有的方式，在BPMN那一章会专门与BPMN标注进行映射。

谢谢提供的链接，我会好好研究

12 楼 ronghao 2009-12-01  

<div class="quote_title">BlueAeri 写道</div>
<div class="quote_div">
<p>笔者没有必要反应那么大（“<span>相当大的弊端，相当不合理</span>”）吧！我倒是觉得那是个方向。“<span>编程效率可以想象</span>”也许时间长了，但都是简短的<span>功能函数，可以由“工人流水作业”，不需要一大批技术专家去编写那些低级高重复代码了，高级编程人才专注于开发稳定、高效、简单易用的“</span><span>快速开发平台产品</span><span>”，尽量把“</span><span>好多步才能实现</span><span>”的变简单了。“</span><span>代码的执行效率低</span><span>”有点多虑了，鄙人在12年前觉得Java效率低而不学了，现在从12楼跳下来都来不及追赶你们了。“</span><span>只能提供有限的调试</span><span>”这就是目的，</span><span>总体来说基于稳定可靠的“</span><span>快速开发平台产品</span><span>”来是实施项目，就已经成功了大半，感觉现在已经是“平台”时代了，连火箭、卫星都有一系列的研发平台了。。。</span></p>
</div>
<p>我不反对基于脚手架进行业务扩展和封装形成“快速开发平台”<img src="/images/smiles/icon_biggrin.gif" alt="">，但是个人非常反对这种<strong>独特</strong>的用法。<img src="/images/smiles/icon_evil.gif" alt=""></p>

11 楼 BlueAeri 2009-11-30  

还有就是提两点建议：

1、术语能否更加标准或贴切一点？比如“并发分裂”，更多的使用“并行分支”或“平行拆分”，个人感觉“并行分支”比较贴切。

2、模型标注图形能否采用BPMN标准呢？个人觉得那样会更好。

可以参考：
工作流模式的 WebSphere Integration Developer V6 实现，第 1 部分: 12 个基本的工作流模式简介：
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0707_chenbing/

工作流模式的 WebSphere Integration Developer V6 实现，第 2 部分 : 9 个高级的工作流模式简介：
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0803_weishan/

10 楼 BlueAeri 2009-11-30  

<div class="quote_title">ronghao 写道</div>
<div class="quote_div">
<div class="quote_title">mock1234 写道</div>
<div class="quote_div">
<div class="quote_title">ronghao 写道</div>
<div class="quote_div">
<p class="MsoNormal"><span>于是一件有意思的事情出现了：有快速开发平台产品使用流程引擎来编排程序逻辑。他们的做法是将细粒度的代码逻辑封装为运算构件，然后再通过流程的可视化编辑器将这些运算构件粘合起来。这样，传统方式下采用代码实现业务逻辑的过程变成了画流程图的过程。笔者认为这样的实现存在相当大的弊端，相当不合理。首先，编写代码变得复杂了，明明几十行代码能够实现的逻辑却需要经过编写构件、绘制程序流程图、部署、运行好多步才能实现，编程效率可以想象；其次是代码的执行效率低，程序的运行需要经过一次流程定义的解释才能执行；然后是这种实现完全牺牲了语言自身的特性，面向过程，很难提供代码级别的单元测试环境，只能提供有限的调试。该实现实际上是定义了一种简单的流程语言，通过该流程语言来进行功能函数（运算构件）调用的编排。任务编排没有问题，服务编排也没有问题，但是如果编排细粒度到功能函数，那么就超出了流程引擎的作用域。提升编程效率的最好途径总是语言而不是工具。</span> </p>
</div>
<p><br>笔者不知道图形也是可以编译的吗？</p>
</div>
<p>这两者有什么必然关系吗？</p>
</div>
<p>笔者没有必要反应那么大（“<span>相当大的弊端，相当不合理</span>”）吧！我倒是觉得那是个方向。“<span>编程效率可以想象</span>”也许时间长了，但都是简短的<span>功能函数，可以由“工人流水作业”，不需要一大批技术专家去编写那些低级高重复代码了，高级编程人才专注于开发稳定、高效、简单易用的“</span><span>快速开发平台产品</span><span>”，尽量把“</span><span>好多步才能实现</span><span>”的变简单了。“</span><span>代码的执行效率低</span><span>”有点多虑了，鄙人在12年前觉得Java效率低而不学了，现在从12楼跳下来都来不及追赶你们了。“</span><span>只能提供有限的调试</span><span>”这就是目的，</span><span>总体来说基于稳定可靠的“</span><span>快速开发平台产品</span><span>”来是实施项目，就已经成功了大半，感觉现在已经是“平台”时代了，连火箭、卫星都有一系列的研发平台了。。。</span></p>

9 楼 ronghao 2009-11-25  

zdonking 写道

ronghao 写道

zdonking 写道

像多路选择，多路合并，以及什么M路选N路，合并M路中的N路。荣同学在写这些的模式的时候能否给些实际场景。呵呵，从来没在实际项目中碰到过。还有就是jbpm无论3还是4，都没有办法直接支持这些模式，通过扩展还是变通的方式间接支持？

我们对Jbpm4有专门3章的讲解，在模式说明中会给出业务应用的场景

:) 个人感觉,这本书偏模型理论多一些，个人很看好这本书，毕竟现在国内很少有人愿意写这方面的书籍了。书既然是偏模型，理论的话，不涉及到具体的工作流实现也挺好吧。虽然jbpm社区比较成熟，活跃度比较高，也比较普及，但是不是3章的篇幅讲jbpm4有点太多呢，毕竟还有好多开源的，商业的实现。而且jbpm4抛开pvm所提供的扩展，其本身所遵循的jpdl规范，也是jbpm自己的东西，还没有上升到业界标准的程度。

恩，我们会将流行的工作流产品进行对比，初步选择是jbpm\osworkflow\shark\active-bpel 商业的 BEA AquaLogic\Ultimus\IBM。我个人对Fireworkflow也很感兴趣。

8 楼 zdonking 2009-11-25  

ronghao 写道

zdonking 写道

像多路选择，多路合并，以及什么M路选N路，合并M路中的N路。荣同学在写这些的模式的时候能否给些实际场景。呵呵，从来没在实际项目中碰到过。还有就是jbpm无论3还是4，都没有办法直接支持这些模式，通过扩展还是变通的方式间接支持？

我们对Jbpm4有专门3章的讲解，在模式说明中会给出业务应用的场景

:) 个人感觉,这本书偏模型理论多一些，个人很看好这本书，毕竟现在国内很少有人愿意写这方面的书籍了。书既然是偏模型，理论的话，不涉及到具体的工作流实现也挺好吧。虽然jbpm社区比较成熟，活跃度比较高，也比较普及，但是不是3章的篇幅讲jbpm4有点太多呢，毕竟还有好多开源的，商业的实现。而且jbpm4抛开pvm所提供的扩展，其本身所遵循的jpdl规范，也是jbpm自己的东西，还没有上升到业界标准的程度。

7 楼 ronghao 2009-11-25  

zdonking 写道

像多路选择，多路合并，以及什么M路选N路，合并M路中的N路。荣同学在写这些的模式的时候能否给些实际场景。呵呵，从来没在实际项目中碰到过。还有就是jbpm无论3还是4，都没有办法直接支持这些模式，通过扩展还是变通的方式间接支持？

我们对Jbpm4有专门3章的讲解，在模式说明中会给出业务应用的场景

6 楼 ronghao 2009-11-25  

hatedance 写道

什么43种模式，本质上就是顺序循环分支那一套。
业务人员不懂代码，所以让他们画这个流程图，本质就是编程。

如果将工作流的应用限定在简化编程的角度，那确实如此。我们也在思考工作流的应用场景，后面会专门发起一个流程应用的讨论，简化编程只是其中的一小部分。

5 楼 zdonking 2009-11-25  

像多路选择，多路合并，以及什么M路选N路，合并M路中的N路。荣同学在写这些的模式的时候能否给些实际场景。呵呵，从来没在实际项目中碰到过。还有就是jbpm无论3还是4，都没有办法直接支持这些模式，通过扩展还是变通的方式间接支持？

4 楼 hatedance 2009-11-25  

什么43种模式，本质上就是顺序循环分支那一套。
业务人员不懂代码，所以让他们画这个流程图，本质就是编程。

3 楼 ronghao 2009-11-24  

下一部分就是高级分支和汇聚模式，多路选择是其中的一种

2 楼 zdonking 2009-11-24  

多路选择 不算 控制模式 吗？

1 楼 ronghao 2009-11-23  

<div class="quote_title">mock1234 写道</div>
<div class="quote_div">
<div class="quote_title">ronghao 写道</div>
<div class="quote_div">
<p class="MsoNormal"><span>于是一件有意思的事情出现了：有快速开发平台产品使用流程引擎来编排程序逻辑。他们的做法是将细粒度的代码逻辑封装为运算构件，然后再通过流程的可视化编辑器将这些运算构件粘合起来。这样，传统方式下采用代码实现业务逻辑的过程变成了画流程图的过程。笔者认为这样的实现存在相当大的弊端，相当不合理。首先，编写代码变得复杂了，明明几十行代码能够实现的逻辑却需要经过编写构件、绘制程序流程图、部署、运行好多步才能实现，编程效率可以想象；其次是代码的执行效率低，程序的运行需要经过一次流程定义的解释才能执行；然后是这种实现完全牺牲了语言自身的特性，面向过程，很难提供代码级别的单元测试环境，只能提供有限的调试。该实现实际上是定义了一种简单的流程语言，通过该流程语言来进行功能函数（运算构件）调用的编排。任务编排没有问题，服务编排也没有问题，但是如果编排细粒度到功能函数，那么就超出了流程引擎的作用域。提升编程效率的最好途径总是语言而不是工具。</span> </p>
</div>
<p><br>笔者不知道图形也是可以编译的吗？</p>
</div>
<p>这两者有什么必然关系吗？</p>