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

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

 

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

这两者有什么必然关系吗？

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

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

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

像多路选择，多路合并，以及什么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也很感兴趣。