1.背景

工作流产品众多，而它们之间又缺乏统一的标准，使得不同的产品之间很难实现协同工作。为了解决这一问题，工作流管理联盟（WFMC）于1993 年成立，并提出了工作流参考模型，制定了五个标准接口。

其中有一个接口是过程定义接口。几乎每个工作流产品都有自己的过程定义语言（也称为工作流语言），可以从四个方面（控制流、数据流、资源、操作）来研究流程，工作流模式（Work Flow Pattern）只是涉及到其中的控制流部分。控制流（control flow）描述了活动在不同结构中的执行顺序。控制流对我们有效认识、理解工作流规范具有很大帮助。工作流规范需要不断地扩展，以便满足新的需求，因此有必要对控制流进行基础的认识和分析。

2.模式总述

工作流模式系统化地表述了基本的和复杂的结构。模式（pattern）是从具体形式中抽象出来的。面向对象的设计模式，规定了不依赖于具体的实现技术，同时也不依赖于所在领域的基本需求。 Carl Adam Petri基于Petri网原理提出的21个工作流模式，用于工作流过程建模和分析。这些模式，仅限于静态控制流，而不考虑资源分配、实例控制、异常处理和事务管理。

3.K2 Blackpearl

K2 Blackpearl 是SourceCode公司基于.NET WF构建的流程开发平台的核心产品。代码可支持生成WF代码，流程设计环境使用WPF构建，并完全嵌入到VS 2005中，与微软产品紧密结合。

K2 blackpearl 包括业务流程管理与工作流性能。可以通过建立应用来管理业务流程并使其自动化，或者集业务流程、人员、服务、信息和系统于单一的应用，从而帮助推动业务发展。

4.基础控制过程

这五个模式的共同点在于：模式所涉及流程的执行路径是在设计时即可确定的，不需运行时的信息。包括：Sequence（顺序模式）、Parallel split（并行分支模式） 、Synchronization（同步模式）、Exclusive choice（排他选择） 、Simple merge（简单合并模式）。

1 顺序（Sequence）

• 描述：工作流中的各个活动在同一个进程中按顺序依次执行。
• 案例：“用户付款”后才能进行“发送货物”。
• K2实现：

2 平行拆分（Parallel Split）

• 描述：工作流中从一个线程中的一个点拆分为在多个线程中平行执行的多个活动。这些平行的活动之间没有关联，执行没有顺序关系。
• 案例： “用户付款”后激活了“发送货物”以及“通知用户”的执行。
• K2实现：

3 同步（Synchronization）

• 描述： 在流程中的某个点，多个并行的子流程或者活动，合并成一个流程。流程必须等待所有的分支都执行完以后，才能激活后续活动，这就是“同步”之意。
  模式3一般与模式2配合使用。
• 案例：“发送货物”以及“通知用户”两个并行活动执行完毕后，激活“存档”活动。
• K2实现： 每个分支维护自己的完成标记，所有Line Rules都设置成：所有分支均完成。

4 排他选择（Exclusive Choice）

• 描述：当一个活动完成以后，可以有多个分支进行选择，但是只能选择其中的一个分支，即多选一。
• 案例：“下完订单”后，可以选择“银行卡付款”或者“邮局汇款”，只要选择一种方式即可。
• K2实现 ：两个Line Rules的逻辑是互斥的。

5 简单合并（Single Merge）

• 描述：有两个或多个可选择的分支，在某一点处合并成一个分支，但并不是同步合并（与模式2的区别）。与模式4也有点相似，都是“多选一”，但模式4是分散，而模式5 是合并。一般采用“先进先出”原则，但是后续活动只产生一次（如果后续活动执行多次产生多实例，就是模式8）。
  模式5一般与模式4配合使用。
• 案例：无论在何种方式的“付款”之后，进行“发送货物”。
• K2实现： 每个分支维护自己的完成标记，所有Line Rules都设置成：有且仅有本分支完成。

5.高级分支与同步模式

6 多路选则（Multi-choice）

• 描述：当一个活动完成以后，有多个分支进行选择，可以选择其中的一个或者多个分支，即“多选多”（模式4 选择是“多选一”模式）。选择的多个分支可能存在并行执行的情况。
  模式6可以认为是模式4的扩展。
• 案例：“发起会签”之后，可以多种选则会签方式，但至少要选择一种。
• K2实现 ：3个Line Rules的逻辑是独立的。

7 同步合并（Synchronize Merge）

• 描述：在流程中的某个聚合点，多个分支路径合并成一个路径。在聚合点，流程会等待所有的分支到来，才能激活后续的活动。这个模式可以选择分支路径，如果只选择一个分支，实现的功能类似于模式5 简单聚合模式；如果选择两个及以上的分支，实现的功能类似于模式 3 同步模式。
  模式7可以认为是模式5的扩展。
  模式7一般与模式6配合使用。
• 案例：要等待所有需要会签的活动都结束才进入“会签结束”，忽略不需要会签的活动。
• K2实现 ：每个激活的分支都维护自己的完成标记，Line Rules都设置为：所有激活的分支均完成。

8 多路合并（Multi-merge）

• 描述：在流程中多个分支（可能是模式6 多重选择的一个或多个分支；也可能是模式2 并行中的多个分支），在合并时每个分支执行完都会激活后面的活动。与模式5 简单合并的区别在于：简单合并的分支只有一个可执行并且后续活动只激活一次；而多路合并是多个分支可执行，后续活动激活多次。
  有的工作流引擎不支持。
• 案例：报销过程中假如分为住宿费、交通费、飞机票特殊报销，每种类型都需要进行审批。如果飞机票的审批比较严格，拖得较久，可能就需要其他的费用先审批通过进入下一环节。
• K2实现： 无需添加任何的Line Rules。

9 鉴别器（Discriminator）

• 描述：在流程中的某个聚合点，等待所有的分支（可能是并行分支，也可能是多重选l 择分支）中的第一个分支执行到达后，就立刻激活后续活动。
• 案例：M个“会签”活动中只要一个会签完成就立即进入“会签结束”。
• K2实现：“会签”节点的Destination Rules 为Create M Slots，Line Rules的逻辑为at least 1 of slots。

10 M中N鉴别模式 （N out of M）

• 描述：在流程中的某个聚合点，等待所有的M 个分支(可能是并行分支，也可能是多多选分支）中的前N 个分支执行到达后，就立刻激活后续活动。与模式9的区别在于模式10有N路同步的概念。
• 案例：M个“会签”活动中只要N个会签完成就立即进入“会签结束”。
• K2实现： “会签”节点的Destination Rules 为Create M Slots，Line Rules的逻辑为at least N of slots。

5.结构化过程

这两个模式的共同点在于：模式所涉及流程的执行路径是由运行时决定的，而非设计时确定。包括：Arbitrary cycles（强制循环模式） 、Implicit termination（隐式终止模式）。

11 任意循环（Arbitrary Cycles）

• 描述： 工作流中的一个点可以让一个或多个活动反复的执行。
• 案例： “修改提交”后进入“经理审批”，但未通过，又回到“修改提交”。
• K2实现：

12 隐式终止（Implicit Termination）

• 描述： 在一个流程中，如果没有活动可执行了那么流程就会终止。换句话说，在工作流中没有active 状态的活动了，而且也没有活动会被激活，这就是隐式终止。（前提：工作流不能处于死锁状态）。
  有的工作流引擎不支持。
• 案例： “主管审批”通过后进入“经理审批”，未通过则无下一个活动。
• K2实现： 如果“主管审批”的输入为“不同意”，流程将终止。
  一般都会采用显示终止，因为隐式终止可能会引起不被察觉的错误，例如意外的输入可能导致流程的结束。

6.多实例过程

“多实例”是指在流程图中，一个活动在同一时刻拥有多个可运行的、处于活动状态的实例。

13 非同步的多实例（Multiple Instances Without Synchronization）

• 描述： 在流程中，一个活动可以激活多个实例，也就是说可以把一个活动分发成几个控制线程。每个控制线程之间都是相互独立的，并不需要同步它们。
• 案例：在网上订购书籍，以书为单位，每一本都会独立产生一个购书实例，并且每个实例之间不需要同步数据。
• K2实现： IPC Event调用方式需要选择为Asynchronous。

14 在设计期间预先确定的多实例（Multiple Instances With a Priori Design Time Knowledge）

• 描述： 一个活动可以激活多次产生多个实例。而产生的实例的个数在流程设计时就事先知道了。一旦所有的实例都执行完成，就会激活其他活动。
• 案例： 有关某些特定资源的请求需要完成固定几个不同的审核流程。
• K2实现 ： 主流程结构为模式2平行拆分 + 模式3同步，IPC Event中调用方式需要选择为Synchronous。

15 在运行期预先确定的多实例（Multiple Instances With a Priori Runtime Knowledge）

• 描述： 一个活动可以激活多次产生多个实例。而产生的实例的个数是变化的，取决于实例的特点或者可用资源数目，但是在流程执行过程的某个时期，在这个活动的实例产生以前，要产生的实例个数是能确定的。所有的实例都运行完成后，激活后续活动。
• 案例： 处理一个订单，订单中有多本书，要分别检查每一本都有库存，所有的书都检查完成后才开始进入送货。
• K2实现： 主要结构为模式6多路选择 + 模式7同步合并，IPC Event中调用方式需要选择为Synchronous。

16 无法在运行期预先确定的多实例（Multiple Instances With a Priori Runtime Knowledge）

• 描述： 在一个活动能够被多次激活的这种情况下，在指定情况下的指定活动的实例数量无论是在设计时或者运行时都不能在活动的实例被创建之前预先确定。但是，在活动被创建之前，在运行中的某个阶段，这个数量是可以预知的。一旦所有的实例都完成了，其它的活动应该被启动。这个模式和模式14的区别在于，在某些实例运行结束之后，新的实例仍能被创建。
• 案例： 订购100 台电脑，涉及多个供应商，但是每个供应商供应多少台电脑是不知道的，因此供应商的数量事先也不确定。但是当每次供应商送货后，就会将现在所拥有的电脑数量和所需的100 台进行比较，来决定是否要下一个供应商继续送货。
• K2实现： 比较复杂，可以利用模式11任意循环实现。

7.基于状态的模式

这三个模式的共同点是：模式所涉及根据当前运行的流程状态来改变流程里的执行路径，包括：Deferred choice（延迟选择模式） 、Interleaved parallel routing（交替平行路由模式） 、Milestone（里程碑模式）。

17 延迟选择（Deferred Choice）

• 描述： 工作流中的一个点，有一个或多个分支已经被选择。与XOR拆分相比，并没有明确的选择，但是，选择是取决于环境的。与AND拆分相比，两者中只有一个被执行。这意味着一旦环境启动了其中的一个，另一个就被取消。要注意，选择是被延迟到两个分支中的一个真正开始执行时，也就是说，选择是可以尽可能的推后的。
• 案例： 在收到货物之后，可选择两种方法将其送到。选择取决于相关资源的可用性。如果资源均不可用，选择会被推迟到直到其中一个资源可用为止。
• K2实现： “监听资源状况”的Destination Rules是一个Robot帐号，只实现监听作用。

18 交替平行路由（Interleaved Parallel Routing）

• 描述： 一组活动以任意的顺序执行，每个活动都被执行，他们的顺序是在运行时决定的，并且在任意一个时刻都不会有两个活动在执行。
• 案例： 体检流程中的活动有各种常规检查和血液检查，哪个在先哪个在后都可以，但是不可能同时检查。
• K2实现： K2并无直接实现方法，需要编码，变通解决。
• 19 里程碑（Milestone）
• 描述： 一个活动能否执行取决于一个指定的状态。也就是说，只有在到达一个特定的未过期的里程碑时，活动才被执行。
• 案例： 客户在确定交付的前两天是可以取消订单的。
• K2实现： 时间上的一些状态可以在Start Rule 和Activity Escalations中实现，其他的复杂逻辑需要编程实现。

8.取消模式

这两个模式的共同点在于：模式所涉及的流程在运行时disables一个活动或者整个流程，包括：Cancel activity（活动取消模式）、Cancel case（实例取消模式）。

20 取消活动（Cancel Activity）

• 描述： 一个可执行的活动被强制失效了，也就是说，一个正在等待执行的活动所在线程被移除了。
• 案例： 网上购书时已经下了订单，“支付货款”活动激活，这时如果取消了订单，那么相应的“支付货款”活动也要取消。
• K2实现： 利用K2 的API实现。

21 取消实例（Cancel Case）

• 描述： 如果一个活动产生了多实例，那么仅仅撤消这个活动是不行的，要将这个活动的所有后代（实例）都移除才行。
• 案例： 网上购书时如果取消了购书的活动，所有因订单激活的购书流程实例都要取消。
• K2实现： 利用K2 的API实现。

9.其他扩展模式

21个工作流模式并不能囊括所有情况，还有其他的一些扩展模式，例如：流程启动、回退、转发、通知、代理、催办、回收、任务批处理、任务分组处理、流程合并、子流程等等。