BPMN的流程模型

在之前的一段时间里，只要一提起PDF，我就会头晕，然后是头疼，最后是头大，总之是和头相关。需求很简单：为所有报表提供在线生成PDF版本的功能，这样网站用户在浏览报表时就可以下载离线浏览。对不住了，开源软件，我不得不说，慎用开源软件，慎用！痛苦的查找论坛、痛苦的翻看源码，最后，在支付了200欧后，痛苦消失了，我们购买了商业软件，200欧兼容了更多的网页结构，200欧具有更快的速度，200欧带有一年的技术支持，最最重要的是，200欧，客户出的。

这不是这里的关键，问题是，200欧后，我遇上了新麻烦：报表的PDF版本样式不正确，不正确的原因是图片下方的文字将图片的排列样式弄乱了（图片大小不规则，字数不规则）。在网页中，DOM渲染完毕后，我们使用JavaScript来进行图片与文字高度的重计算，但在PDF中，我们束手无策。

我问BA，可以容忍部分图片排列不整齐否？不出所料。

怀有侥幸，我继续问BA，可以容忍部分文字丢失否？BA说，不可以。意料之中。于是找到徐昊。

徐昊问BA，这些说明文字对客户如此重要吗？

BA说，是的。

徐昊说，为什么？它主要有哪些内容？

BA说，有标题，简单说明以及图片的版权信息，最重要的就是版权信息，一定不能丢失。

徐昊说，能不能这么说，其实对客户最关心的是版权信息。

BA说，是的。

于是问题解决。解决方案是：我们给文字定高，同时将文字缩小以容纳最可能多的字数，这样网站用户在PDF里看到的图片重新恢复了整齐，尽管看不太清图片说明文字，但是用户真正关心的是图片，谁关心哪些无处不在的版权信息呢？你可能会说了，看不清版权信息怎么行？幸好，你问的不是，版权信息有那么重要吗。回答是，这里是PDF，移动你的鼠标到Zoom，点击下拉框，点击150%以上的选项，然后，你会惊讶的发现，那些该死的版权信息到处都是。

BA的职责是帮客户发现的问题，开发人员的职责是解决问题，QA的职责是校验最终的实现是否能够解决客户的问题。具体到一个用户故事上，就是BA编写用户故事，DEV编码开发，QA验收用户故事，这是三个任务，很明显，这三个任务有一个非常重要的共享信息，这个信息就是用户故事所要实现的客户价值（即帮客户解决的问题）。围绕着客户价值，每次迭代开始前，团队都会进行迭代计划会议，所有成员会跟随BA逐一审核各个用户故事；围绕着客户价值，开发人员开发中随时可以和BA进行沟通，就设计问题进行讨论；围绕着客户价值，开发人员每开发完成一个故事，BA、开发人员和QA就会在一起进行一个微型 ShowCase，在期间讨论用户故事的实现是否实现了客户价值，大家对用户故事的理解是否一致。

那么，在相关的任务之间需要能够定义变量，这些变量数据能够在这些任务间共享。

描述

一定的任务范围能够定义变量，在一个流程实例里，该范围所包含的任务实例能够使用该变量。

图 6-4任务范围级别的数据可见性

如图6-4所示，我们划定了一个任务范围，该范围包含了任务A、任务B和任务C，同时，我们在该任务范围内定义了一个变量M，那么，在一个流程实例里，只有任务A、B和C的实例在运行期能够使用该变量，任务D和E的实例都不能访问，不可见。

可以看到任务范围和块任务在概念上比较相似，都是包含一系列的子任务，它们之间的差别在于：块任务一般具有比较独立的执行上下文和业务语义，而任务范围则是对具有相同执行上下文的任务的一种分组。

在工作流系统里，对流程任务进行分组的好处在于：可以为特定的一组任务绑定数变量、异常处理器和补偿动作。例如在图6-4中，如果任务A、B和C中的任一实例执行失败，那么我们就认为整个任务区域执行失败，将统一执行一个业务补偿行为，同时，这些任务共享一个异常处理器。

实现

在jBPM4里，流程定义模型相比jBPM3最大的变化即是引入了任务嵌套的概念，一个任务能够包含多个其他任务，这里的父任务即可充当任务范围的定义。jBPM4针对这种嵌套的任务建立了一套处理机制，总的来说就是建立任务运行期的嵌套关系，查找变量时首先会在任务级别进行查找，如果找不到，则会依次向上查找父任务实例，直至流程实例级别变量，同时，父任务可以统一绑定异常处理器和事件动作。在后续jBPM4的章节，我们将会详细分析该机制的实现细节。

在一个典型的项目团队里，包括了以下几种角色（帽子）： PM（项目经理）、 BA（业务分析师）、 DEV（程序开发者）和 QA（质量保证人员），整个团队的目标是向客户交付价值。

那么，有一天， QA MM来找我，我是开发人员。 MM说，一张图片没有正常显示，我想知道原因，同时想知道你能否修复。我的第一想法是，这不可能，一定是环境的原因。我说，好的，稍等。接下来，我张大嘴巴看到了 MM给我重现的 BUG：本该显示图片的位置一片空白，就像此时我合不上的嘴。这怎么可能呢？我想，这个功能完成的如此之得意，以至于测试用例里的数据都是以我的名字命名的。

几分钟后，或者更长，我叫来 MM，说，找到原因了。

我打开编辑器，光标在源程序的某一行闪烁，我说，最根本的原因在这里。我看到 MM的眼中闪过一丝迷茫。接下来，我却换到另外一个源文件，光标继续闪烁，我说，这里的程序因此受到影响。看得出， MM有点发晕。终于，当我打开第 N个源文件并试图继续讲解时， MM昏过去了。

当 MM苏醒过来时，我在她清澈的双眼中看到了一只清晰的唐僧。

MM肯定感到了不好意思，因为我的讲解中包含了比喻、类推、排比等我力所能及的各种语文知识，看得出，我很努力，我的语文老师也很努力，所以她委婉地说，能不能简单一点？

我想了想，说，测试驱动时测试数据不全导致程序少考虑一种情况。

MM说，能修复吗？

我说，可以。于是故事结束。

就 是这样，当我们执行一项任务时，围绕这项任务必然会产生许许多多的信息，这些信息对于该任务的执行者是必须的，但是对于其他人则不是，有效的沟通往往来自 于简练的表达即只表达对方需要和可以理解的内容，浩瀚的细节只会将真正想表达的内容淹没。其实这里还有这样一层意思：我之所以用这么多的细节信息来淹没 QA，实际上是不太情愿承认程序里有 BUG。 QA想要的结果很简单，是否是程序 BUG，能否修复。而开发人员则往往把自己的程序与自己关联在了一起，认为程序是自己的扩展，程序有 BUG则意味着自己有缺陷。这一关系明显是矛盾的，可是一些团队里开发人员和 QA能够和平相处，而有些团队却势如水火。

那么，对于单个任务而言，需要定义自己的变量，这些变量数据只与该任务相关，只在该任务里可见。典型的工作流应用于任务执行期间的中间数据存储。在文档处理中，一个重要的功能就是需要提供版本管理，在单个任务实例里，办理者能够管理自己处理过的文档版本。

描述

任务能够定义变量，在一个流程实例里，该变量只能被其任务实例所使用。

图 6-2任务级别的数据可见性

如图 6-2所示，我们在任务 B上定义了一个变量 M，此时，在一个流程实例里，只有任务 B的实例才能使用该变量。

实现

存在两种实现方式，一种是如图 6-1所示的，在任务节点定义中声明变量，运行期初始化任务实例的同时初始化该变量并使用； 另一种是在流程定义级别统一声明变量，但是各个任务实例都独立初始化并存储该变量。第二种实现方式在各个任务都需要使用同一语义的变量时很常见，例如各个任务实例都会有参与者，我们在流程定义时声明一个名为 userid的变量，在流程实际执行时，各个任务实例都会独自保存有自己的 userid数据。

等等，这个故事和本章的主题-数 据模式有一毛钱的关系？这只是一个关于沟通的故事。是的，让我们稍微映射一下：这里，晚饭这个流程包含了两个基本的任务，分别是做饭和洗碗，在做饭这个任 务完成时，任务的执行者（老婆）向下一个任务的执行者（我）传递了数据（要洗哪些东西），正如语言是人之间的沟通方式一样，数据是IT系统之间的沟通方式，语言之间的沟通总是最有效的，数据交互却未必，因为IT系统里的数据交互除了让计算机理解外重要的是还需要人理解，IT系统是对现实生活的映射，也正因为如此，现在数据之间的沟通也在向语言靠拢即语义化（REST/语义网）。

好，言归正传。

在 前两章里，我们分别讨论了工作流的控制模式和资源模式，控制模式关注于如何合理调配业务流程里的任务，从而获得理想的执行效率和收益；资源模式则关注于如 何合理调配可用的资源来执行业务流程。本章将介绍工作流系统里的数据模式，从数据的角度分析工作流系统对数据的处理。数据模式共计39种，在下面的介绍中，我们将这些模式分为了四部分，分别是数据可见性、数据交互、数据传输和基于数据的路由。

本章先会概要重复一下与数据模式相关的一些基本概念，例如流程定义、流程实例、原子任务、块任务等。接下来会对具体的39种数据模式进行讨论，讨论的模式按照应用、描述和实现展开，分别对应着实际场景对模式的映射、模式的介绍和工作流系统对该模式的实现支持。最后是小结。

一、基本概念

1、工作流系统里的流程结构

在正式介绍数据模式之前，让我们先简单回顾一下工作流系统里流程的基本结构。

图 6-1 工作流系统里的流程结构

流程定义：对业务流程的建模和描述，其具有足够的细节信息，能够直接被工作流系统所执行。典型的，流程定义由一系列的任务组成，这些任务以图形的形式展现并被连接起来。

流程实例：流程定义的一个执行实例被称为流程实例。一个流程定义可以存在多个同时执行的流程实例。这些流程实例互相独立执行。

任务：一个任务对应着流程定义里的一个单一工作单元。存在四种不同类型的任务：原子任务、块任务、多实例任务和多实例块任务。

原子任务包含简单且独立的任务定义，当其初始化时只会产生一个可执行的任务实例。

块任务是一系列任务的组合，典型的，工作流系统里存在的子流程任务（节点）即是块任务，当一个块任务开始执行时，其将流程控制权传递给与之对应子流程的第一个任务，当子流程完成执行后则将控制权返回给块任务。如图6-1所示，块任务C对应着一个由任务X、任务Y和任务Z组成的子流程，实际执行时，任务C会触发任务X的执行，任务Z执行完毕即子流程执行完成后则会触发任务C执行完成。

多实例任务在实际执行时会产生多个并行执行的任务实例，这些任务实例一般互相独立执行。当一定数量的实例执行完毕后即会触发后续任务的执行。

多实例块任务结合了块任务和多实例任务的定义，其在实际执行时产生多个任务实例，每个任务实例对应着一个子流程实例。

任务实例：任务的一个执行实例。

2、数据相关约定

我们使用def var ${变量名}定义数据元素，同时def var ${变量名}的声明位置决定了变量的作用范围。如图6-1所示，我们在任务C上定义了一个名为M的数据变量，其的作用范围为任务C，任务级别。

我们使用use(${变量名})表明对变量的使用；使用pass(${变量名})表明数据变量的传递。在图6-1里，变量M从任务C传递至任务E。

对于变量的数据类型，典型的有String、integer、float、boolean、date、time等，很多工作流系统使用序列化和反序列化支持存储任意类型的数据类型，如数组、集合、对象。

3、类比的约定

在后续对各个模式的介绍里，我会围绕一个项目团队的故事进行映射，我们如此约定：

流程定义：我们认为所有成熟的软件公司都会建立起其完整并适用的一套软件开发流程，我们将这套流程看作是这里的流程定义。

流程实例：围绕着软件开发流程，我们会使用这套流程来开始我们实际的软件开发项目，我们将所有的软件开发项目都看作是开发流程的执行实例，即流程实例。

任务：项目开发过程中的各项任务。

数据：我们将团队成员之间的信息交流看作是数据交互。

提到流程，第一个问题就是流程的历史。18世纪英国经济家学亚当·斯密在《国民财富的性质和原因的研究》中提出“劳动分工原理”，提出分工有利于提高效率、增加产量，其理由有三：第一，劳动者的技巧因业专而日进；第二，分工可以免除由一种工作转到另一种工作的时间损失；第三，简化劳动和机械的发明使一个人能做许多人的工作。亚当·斯密的分工论蕴涵了最朴素的流程理念。流程产生于一系列的分工。

维基百科里 对业务流程进行了如下定义：业务流程是为特定的对象（客户）创造价值的过程，这一过程由一系列相关联、有组织的活动或任务组成。企业和组织中，业务流程一 般被划分为三种基本类型：管理流程，对企业运行进行管理、协调的流程；运行流程，构成核心业务和创造基本价值的流程，如采购、制造、市场销售等；支持流 程，支撑管理流程和运行流程的流程，如会计、招聘、技术支持等。

接下来我们关注工作流技术的历史。工作流技术发端于1970年代中期办公自动化领域的研究工作，但工作流思想的出现还应该更早，1968年Fritz Nordsieck就已经清楚地表达了利用信息技术实现工作流程自动化的想法。1970年代与工作流有关的研究工作包括：宾夕法尼亚大学沃顿学院的Michael D. Zisman开发的原型系统SCOOP，施乐帕洛阿尔托研究中心的Clarence A. Ellis和Gary J. Nutt等人开发的OfficeTalk系列试验系统，还有Anatol Holt和Paul Cashman开发的ARPANET上的“监控软件故障报告”程序。SCOOP, Officetalk和Anatol Holt开发的系统都采用Petri网的某种变体进行流程建模。其中SCOOP和Officetalk系统，不但标志着工作流技术的开始，而且也是最早的办公自动化系统。

1970年 代人们对工作流技术充满着强烈乐观情绪，研究者普遍相信新技术可以带来办公效率的巨大改善，这种期望不可避免的落空了。人们观察到这样一种现象，一个成功 的组织往往会在适当的时候创造性的打破标准的办公流程；而工作流技术的引入使得人们只能死板的遵守固定的流程，最终导致办公效率低和人们对技术的反感。1970年代工作流技术失败的技术原因则包括：在办公室使用个人计算机尚未被社会接受，网络技术还不普遍，开发者还不了解群件技术的需求与缺陷。总结一下，工作流应用失败的原因有两点：第一点是自动化流程的柔性低；第二点则是限于当时的技术原因。

进入1990年代后，随着IT技术的发展、个人计算机的普及，工作流技术开始重新进入一个新的热潮，这个热潮完全是技术驱动的，这时候出现了大量的工作流技术应用。需要注意的是，工作流技术不仅仅是指专门的工作流管理系统，同时也指拥有工作流特征的各种应用系统，例如各类企业管理软件（ERP）和协作软件里有具有的相应流程组件。工作流技术的应用使得很多应用软件的开发得到一定程度的简化（同时，可以观察到工作流产品的采购客户往往会是系统集成商）。需要注意的是，此时工作流要解决的问题域依旧是实现工作流程的自动化，由此带来的应用局限并没有发生变化。

与此同时，新的管理革命正在发生。

1990年迈克尔·哈默在《哈佛商业评论》上发表了题为《再造：不是自动化改造而是推倒重来》(Renglneenllg work：don"t automate，obliterate)的文章，文中提出的再造思想开创了一场新的管理革命。1993年迈克尔·哈默和詹姆斯·钱皮在其著作《企业再 造：企业革命的宣言)(Reengineering the Corporation；a Manifesto for Business Revoiution) 一书中，首次提出了业务流程再造(BPR：Business Process Reengineering)概念，并将其定义为：对企业业务流程进行根本性的再思考和彻底性的再设计，以取得企业在成本、质量、服务和速度等衡量企业绩 效的关键指标上取得显著性的进展。该定义包含了四个关键词，即：“流程”、“根本性”、“彻底性”和“显著性”。

以此为标 志，形成了新的业务流程理念，并伴随着对传统企业金字塔式组织理念和管理模式的反思，新的理念强调企业以业务流程为中心进行运作、打破传统的部门隔阂、增 加客户价值和企业效益（降低成本）。以业务流程为中心取代职能分工，成为管理的首要原则，围绕流程建立起来的组织具有更高的敏捷性、效率和效益，呈现出扁 平化、网络化的特征。

新的管理理念催生新的IT产品，BPM产品孕育而生。可以说一个好的IT产 品总是对应有相应的理论基础，那种简单的对现有工作方式的复制化是没有生命力的（一个小的而典型例子是电子印章软件，从布局到排版都很逼真。可是现实中印 章的设计是为进行文件的状态确认，非常直接，但是在电脑上摹仿这种印章，不但用着别扭，看着也十分难过，更重要的是，明明通过工作流的控制已经能够确认文 件的状态，却一定要通过电子印章来生硬模拟。）。很多技术人员以XPDL和BPEL来区分流程产品是工作流还是BPM，认为BPM更为强调软件的系统集成能力。实际上，工作流软件与BPM软件最大的区别不在于技术实现，而是它们解决的问题域发生了变化。

工作流软件解决的问题域是流程的自动化，而BPM软件解决的问题则是业务流程的优化。

因为解决的问题域发生变化，那么BPM软件相比工作流软件在技术上的变化就很清晰了：强调对流程运行的监控、强调对流程运行数据的分析、强调对各种企业应用软件的集成能力、强调快速的开发能力。实际上很多BPM软件的前身即是工作流产品，从技术角度上理解，工作流软件和BPM软件是没有区别的，BPM软件是工作流软件发展的结果，只是开发商出于市场的考虑换上一个不同的标签而已（非常类似于当前的药品市场，同一种成分换个名称就变成新药）。然而从处理问题的角度考虑，区别两者则又是必要的。

但是BPM软件面临的问题依旧存在，因为很多BPM软件解决问题的思路并不正确，很多BPM软件依旧是通过自动化流程来实现业务流程的优化，这再次回到工作流软件所面临的问题：企业很多业务流程很难自动化、自动化流程的柔性很低。对于这些问题，BPM软件试图通过简化编程（快速开发、SOA思想）和系统集成来尽可能自动化多的流程，通过增强流程定量分析能力来尽可能的增加流程柔性。这实际上是在用正确的方式做错误的事，因为解决问题的思路从一开始就决定了这并不是一条正确的路。

相比而言，Nimbus的Control-ES软件则选择了另外一条道路，它并不强调流程的自动化，它是从咨询软件发展而来的，这决定了其解决问题的另外一种方式：强调对现有流程的评估和重构而非自动化。在Control-ES里，流程是作为企业财产保存的，仅仅文档化。这几乎立刻扩大了其对业务流程的描述能力，但是其的咨询背景也决定了它的局限性：无法实时获取业务流程执行的数据（完全依靠咨询人员的工作），于是Control-ES更多是作为咨询人员的工具而存在的。从某种意义上说，流程改进本来就是一项咨询工作，很多IT厂商甚至没有任何业务领域经验，拿出其BPM软件就宣传能够实现客户流程的优化是一件很搞的事情，很多所谓的流程梳理实际仅仅是对现有流程的复制再现，没有任何改进可言。

          一种更好的方式是文档化所有业务流程，然后通过系统集成能力实时获得关键的数据信息，实现以流程为中心的数据撮合，关键的流程执行和改进则交由人去灵活执行。对这种实现思路我们将在本书的最后部分进行讨论。可以看见的是，流程优化从来也不应该是IT系统能够完成的事情，IT系统所要做的是为流程优化撮合必需的数据，做为支撑系统而存在。

          说完BPM软件，最后我们需要关注的一个方向是云计算。越来越多的企业将其工作放置到了网上，典型的如Google提供的各种在线服务，文档、邮件、Excel等，这种趋势触发了新的业务模式，云中的工作流即是其中一种，通过提供在线的工作流程自动化，将各种在线服务通过流程粘合起来。在这方面，Cordys走在了最前面。

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

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

一、       基本控制模式

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

1、顺序（WCP_01: Sequence）

描述

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

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

在前面的资源模式里，我们讨论了创建模式、推模式和拉模式，它们实际对应着工作项的一个正常生命周期：创建、提供/指派、资源选取开始执行。在前面的讨论里，工作项的执行都是由资源驱动的（从工作项待办列表里选取执行），而自动开始模式则提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行往往表明了该工作项的最高优先级，需要马上开始执行。

图 5-42

如图5-42所示，自动开始模式对应着红线标识着的工作项的状态变迁，共有4种模式：创建即执行、指派即执行、成堆执行和链式执行。

1、创建即开始执行（WRP_36: Commencement on Creation）

描述

资源能够在工作项一创建完毕就开始执行。

图 5-43

如图5-43所示，任务A工作项一创建就插入员工甲的办理列表，需要员工甲马上开始执行。

应用

该模式应用在关键的优先级高的任务里，通过系统推送，强制资源优先执行该任务，省去任务的等待时间。

实现

该模式的实现实际是系统同时完成了工作项的创建和推送，系统需要确定具体的执行人，工作项不会分配给角色、岗位等资源组以提供给相应资源进行选择。

2、指派即开始执行（WRP_37: Commencement on Allocation）

描述

资源能够在工作项一指派完毕就开始执行。

图 5-44

如图5-44所示，任务A工作项一旦被员工甲从可拾取列表拾取就马上插入员工甲的办理列表，需要员工甲马上开始执行。

应用

该模式跳过了工作项的指派状态，实际是对创 建即开始执行模式的扩展，在创建即开始执行模式里，工作项必须预先确定明确的执行人，不能分配给角色、岗位等资源组，而在该模式里除了支持创建即开始执行 模式里的情况，同时也提供了对这种情况的支持，工作项可以提供给多个资源拾取，一旦一个资源拾取则必须马上开始执行（从这个角度看，该模式与资源驱动执行-提供工作项模式是相同的）。

3、成堆执行（WRP_38: Piled Execution）

描述

资源能够成堆执行相同任务的不同工作项。

图 5-45

如图5-45所示，员工甲有多个任务A的工作项需要执行，这些注意的是，这些工作项并不是由一个任务实例所产生的，它们属于不同的流程实例，是由多个流程实例里的任务A生成的。一旦员工甲开始任务A工作项的执行，那么他将执行所有任务A的工作项，即将任务A相关的工作项全部打包执行。这一功能由系统驱动，系统将与任务A相关的工作项依次推送至资源的办理列表。

应用

开发人员甲熟悉持续集成工具，此时同时有多个软件开发项目需要搭建持续集成环境。一旦他为某个项目组搭建了持续集成环境，那么处于执行效率的考虑，最好的方式无疑是他一鼓作气将所有的持续集成环境都搭建完毕。

相同/相似的工作交由同一资源一并执行，这些工作具有完全或大部分相似的执行上下文（相同的知识、能力要求），从这个角度能够达到最高的工作效率。

实现

系统需要在进行工作项状态变迁操作时提供相应的钩子，以进行相应的回调操作。

4、链式执行（WRP_39: Chained Execution）

描述

在一个流程实例里，当前一个任务的工作项执行完毕后，能够自动开始执行下一个任务的工作项。

图 5-46

如图5-46所示，任务A和任务B是两个连贯的任务，它们都分配给员工甲执行，当员工甲执行完毕任务A的工作项后，任务B生成的工作项将马上被系统发送至员工甲的办理列表，员工甲需要马上办理。

应用

该模式实际是将资源胶黏在一个流程实例上，同样是出于执行效率的考虑（两个任务位于同一流程实例里，具有相同的执行上下文）。该模式的应用具有前提条件：流程定义时，连续的任务由相同的资源进行处理。

七、可见性模式

可见性模式讨论各种不同资源对工作项的可见 性，不同的资源由于角色、权限的不同，对工作项拥有不同的可见范围。由于涉及到权限，那么根据不同的组织机构设置，必然会出现不同的工作项权限分配，这里 不讨论具体的工作项权限分配，仅从工作项的状态来讨论这些工作项区分可见性的必要性。

可见性模式包括2种：未指派状态工作项的可见性和指派状态工作项的可见性。实际上，工作项处于执行状态或完成状态也存在不同的可见性。

1、可配置的未指派工作项的可见性（WRP_40: Configurable Unallocated Work Item Visibility）

描述

能够配置未指派工作项的可见性。

图 5-47

如图5-47所示，可拾取列表里存在3个工作项：任务A工作项、任务B工作项和任务C工作项。员工甲可拾取的工作项包括：任务A和任务B工作项；员工乙可拾取的工作项包括：任务B和任务C工作项，那么由此产生的可见性是：员工甲只能看到任务A和任务B工作项，而员工乙则只能看到任务B和任务C工作项。而作为员工甲和员工乙的部门经理，他需要了解每个属下的工作情况，所以他可以看见所有甲乙可见的工作项。

应用

随着企业规模的发展，几乎所有企业的组织模 型都会形成金字塔型的结构，一方面是出于分工的需要，另一方面则是出于管理的需要，每一层级的人员都需要对上一级负责，同时管理下一层级的人员。处于管理 的需要，管理者必然需要了解下属的工作情况，这样权限就自然产生了，具体到工作流的任务里，管理者需要对其所管理下属的工作具有可见性。

其实不仅仅是对于工作项，对于流程实例本身 也具有可见性的分配。对流程负责的人必然具备最大的可见性和权限，流程根据任务分解，如果仅仅只对某一任务负责，那么则只对该任务具有可见性，而如果需要 对多个任务负责，那么就需要对多个任务具有可见性，最直接的负责人就是具体执行该任务的人员，但是引入管理的层级后，职责的承担也会形成层级的关系，从上 至下层层承担，此时担负最大职责的人员往往不再是具体的工作执行人员，而是相应的管理人员。

实现

在前面所描述的情况里，支持员工甲乙的可见性是比较简单的，因为每条工作项记录都携带有参与者信息，但是部门经理显然不在这些参与者信息里，所以需要引入与组织权限模型相匹配的工作项查询机制，即不同于工作项列表的查询列表。

2、可配置的指派工作项的可见性（WRP_41: Configurable Allocated Work Item Visibility）

描述

能够配置已指派工作项的可见性。

图 5-48

如图5-48所示，待办列表里存在3个工作项：任务A工作项、任务B工作项和任务C工作项。指派给员工甲的工作项包括：任务A和任务B工作项；指派给员工乙的工作项包括：任务C工作项，那么由此产生的可见性是：员工甲只能看到任务A和任务B工作项，而员工乙则只能看到任务C工作项。而作为员工甲和员工乙的部门经理，他需要了解每个属下的工作情况，所以他可以看见所有甲乙可见的工作项。

八、多资源模式

到目前为止，我们讨论的工作项都是与某一特定资源一一对应的，即一个工作项只能由一个单一资源执行，或者严格来说，一个工作项在任何时间段都只能由一个单一资源执行（考虑到工作移交的情况）；同时，一个资源在任何一个时间段都只能处理一个工作项。

多资源模式将会讨论两种不同的情况：一个资源同时执行多个工作项、多个资源执行同一个工作项。

1、同时执行（WRP_42: Simultaneous Execution）

描述

资源能够同时执行多个工作项。

图 5-49

如图5-49所示，员工甲的办理列表里有三个工作项，他能够同时执行这三个工作项。

应用

和计算机一样，虽然在任何时刻都只能处理一项工作，但是通过将多项工作切分成多个线程交替执行，从某个时间段看，人能够同时处理多项工作。

人能够选取相关联的多个工作，同时开始执行，在执行的过程中，合理安排这些工作的执行时机和顺序。

实现

几乎所有的工作流系统都不会约束人员往自己的办理列表里增加多个工作项。

2、增加资源执行（WRP_43: Additional Resources）

描述

资源能够要求增加资源来处理他正在执行的工作项。

图 5-50

如图5-50所示，员工甲和员工乙同时处理一个工作项。

应用

在一些复杂的场景里，一项工作往往需要多个资源共同协作完成。

典型的在一个会签任务里，一个发文需要多人签字通过，同时在会签过程中，经常出现动态加签的情况：需要新的人员加入进行签字。

在敏捷开发里，所有的开发工作都是由两个开发人员共同结对完成。

实现

工作项作为工作流系统里最小的工作单元，如果将其分配给多个资源，无疑会增加编程模型的复杂度。最常见的实现方式是增加工作项，一个任务节点对应多个工作项，对于需要增加资源的情况，增加工作项。

九、小结

在本章里，我们讨论了工作流的43种资源模式，这些模式分为7类，分别是创建模式、推模式、拉模式、折回模式、自动开始模式、可见性模式和多资源模式。

创建模式在系统创建工作项时生效，其位于工作项生命周期的创建阶段，创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项。

接下来，系统需要将工作项推送给相关的资源进行执行，这个推送的过程即是推模式所包含的内容。工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送可以理解为系统将生成的工作项推送至相应资源的工作项列表里。

推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行，这是拉模式所包含的内容。

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如重新分配、重做、挂起等等。折回模式对应着这些情况，折回代表着工作项状态的反复、回退。

自动开始模式提供了一种系统驱动工作项执行的方式，系统直接驱动工作项执行往往表明了该工作项的高优先级，需要马上开始执行。

可见性模式讨论各种不同资源对工作项的可见性，工作项自身作为资源与权限相关。

多资源模式讨论一个资源执行多个工作项和多个资源执行同一个工作项的情况。

从这些模式的讨论可以看出，这些模式更多关 注的是对实际业务执行的场景描述，关注通过合理分配任务和调配工作的执行为组织带来最大的执行效率。从另一个角度看，由于这些模式都以业务作为出发点，这 给工作流系统的实现带来了复杂性，很多模式当前的工作流系统都无法完全支持或直接支持。在很多情况下，模式的支持需要很多的约束，而这种约束往往需要在工 作流实施阶段结合客户具体情况进行限定，这实际强调了工作流实施的重要性，工作流系统的应用是由工作流产品加实施两部分组成，很多时候，实施占据了更大的 比重，这就对工作流产品的可扩展性提出了要求。应用工作流不仅仅是选择工作流产品，更重要的还包括选择合适的实施团队。

在下一章里，我们将讨论另外一种工作流模式-数据模式。

实际工作中，工作的执行状态不可能总是与预想相符的，总会出现各种各样的情况，例如原本分配给员工甲的任务由于甲要请假不得不重新分配，由于新的紧急任务员工乙当前的工作需要挂起一段时间等等。折回模式则刚好对应着这些情况，折回代表着工作项状态的反复、回退。

图 5-33

如图5-33所示，折回模式对应着红线标识着的工作项的状态变迁。这些状态变迁对应着以下情况：

委派：资源将先前指派给他的工作项委派给他人执行。

系统重新分配：系统将没有完成的工作项重新提供或指派给其他资源执行。

退回指派：资源撤销指派给他的工作项，工作项可以重新指派给其他资源。

工作移交：资源将其已经开始执行的工作项移交给他人执行。

挂起/恢复执行：资源临时挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

跳过：资源选择跳过指派给他的工作项的执行，不执行该工作项。

重做：资源重新执行先前已经完成的工作项。

提前执行：资源在流程实际触发该工作前已经开始执行该工作。

折回模式共有9种。

1、委派（WRP_27: Delegation）

描述

资源能够将先前指派给他的工作项指派给另外的资源执行。

图 5-34

如图5-34所示，委派对应于红线标识着的工作项状态变迁。

应用

委派在平常工作中非常常见，例如员工甲将要请假，他将他要完成的工作委派给同事乙执行；在协同办公里，领导将相关工作委派给下属执行等等。

实现

实际应用中，委派按照粒度分为了两种：一种 是工作项的委派，这是一种细粒度的委派，指单一任务实例的委派，与某一特定的任务实例关联；另一种是业务的委派，这是一种粗粒度的委派，例如，员工甲将其 负责的某类业务的工作全部委派给员工乙，这意味着属于这类业务的所有工作都将由员工乙执行。业务的委派通常与权限紧密关联，实际实现时为避免用户权限的混 淆，一般采取分开登录系统的方式进行实现，即员工乙如果想处理员工甲委派给其的工作，则需要用员工甲的账号和其给定的密码重新登录系统，并注销掉自己账号 的使用。

需要注意的一点是：委派意味着原先指派的资源还必须对该工作负责，例如员工甲将某项工作委派给员工乙执行，尽管员工乙实际执行了该工作，但该工作仍然必须由员工甲负责。所以在实现中，员工甲必须能够保持对委派工作项的追踪和控制。

2、系统重新分配（WRP_28: Escalation）

描述

系统能够重新分配已经分配的工作项，以加快工作项的执行。

图 5-35

如图5-35所示，工作项原先提供或指派给了一个或多个资源执行，现在由于各种原因，需要优化该工作项的执行，所以将该工作项收回重新分配，提供或指派给其他的资源。

应用

工作分配的优化。很多时候，计划跟不上变 化，工作也是这样，分配工作前有许多的考虑因素，例如个人能力、工作经验、技能要求等等，但在实际工作中往往会发现原先的人力分配并不合理，或者有些人承 担了太多的职责，或者有人能力超出其目前担承的职责等等（在敏捷软件开发里，我们通过频繁的交换结对编程以达到部分的平衡），在这种时候就需要对工作进行 灵活的重新分配以到达最高的执行效率。

实现

实际实现中非常受限，对流程的优化始终是一 个对人的命题，而不是对机器对工具的命题，工具所能做到的只是尽可能多的提供可供参考的数据模型，例如各种报表、数据分析等等，最后做出决策的还是人。所 以该模式的实现也以提供给流程管理员重新分配工作项的能力为主，同时提供工作项超时的提示为辅。

3、退回指派（WRP_29: Deallocation）

描述

资源撤销指派给他的工作项，工作项可以重新分配给其他资源。

图 5-36

如图5-36所示，资源能够退回原先指派给他的工作项，该工作项可以交由系统重新分配给其他资源。

应用

同样是工作分配的优化，只不过该模式由资源驱动。

实际工作中，由于各种原因，例如经验不足、当前承担职责过多等等，发现自己并不能很好完成当前的任务时，可以提出不执行该任务。

实现

实现的难点在于资源退回工作项后的重新分配，即如何重新分配该工作项。

与提供给多个资源模式对应，该模式的最简单支持是退回重新提供给多个资源。例如工作项分配给开发人员这一角色执行，开发人员甲拾取了该工作项（故事卡），经过一番痛苦和彷徨，最终将该工作项退回，这样所有开发人员又都能拾取该工作项。

4、有状态工作移交（WRP_30: Stateful Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态将得到保存。

图 5-37

如图5-37所示，资源将已开始执行的工作移交给其他资源执行。该模式与委派模式很相似，差别就在于委派模式是将未开始执行的工作进行重新指派执行，而该模式则是将已开始执行的工作进行重新指派执行。委派模式中的委派者仍需要为委派出去的工作负责，而移交则同时意味着责任的移交。

应用

工作移交非常常见，最常见的原因包括位置调动、离职、休假等等。

实现

在大多数的工作流系统实现里，业务数据与流程数据是相互隔离的，仅仅通过某一字段进行关联（例如业务主键），流程的目标是携带业务数据进行流转。在这种情况下，该模式的实现变成了默认实现，系统不需要做任何回退或清理操作，直接做工作项的转发即可。

5、无状态工作移交（WRP_31: Stateless Reallocation）

描述

资源将正在执行的工作项移交给其他资源执行，该工作的状态不会得到保存。

与有状态工作移交对应。

应用

工作的无状态移交通常意味着工作的重新执行，并且原有的工作对重启的工作而言没有太大的价值。

实现

与有状态工作移交相比，该模式需要处理相应业务数据的回退或清理。直接支持该模式比较困难，需要在实施时根据情况对该任务节点操作业务数据的权限进行限定，并在限定的基础上进行记录和回退。

6、挂起/恢复执行（WRP_32: Suspension/Resumption）

描述

资源能够挂起当前执行的工作项，并在某一个时候重新恢复执行该工作项。

图 5-38

应用

资源对分配给其的工作进行优化执行，能够根据自己和当前的实际情况合理的安排工作执行，挂起正在执行的工作，执行当前最重要或效率最高的工作，然后再返回执行该工作。

实现

基本的状态变迁。

7、跳过（WRP_33: Skip）

描述

资源能够选择跳过指派给他的工作项的执行，不执行该工作项，并将该工作项标识为完成。

图 5-39

应用

实际工作中，对于非关键工作，可以选择跳过，以便进行后续更为紧急或重要的工作。

实现

对于实现工作项本身的状态变迁来说，支持该模式非常简单，问题在于业务数据的依赖关系，如果后续工作的处理依赖于该节点处理后的业务数据，那么简单的选择跳过该工作项的执行就会产生问题。所以一个好的做法是给一些关键任务节点加上约束，不允许执行跳过操作。

8、重做（WRP_34: Redo）

描述

资源能够对先前完成的工作项重新处理，同时，该工作的后续工作项（后续任务所对应的工作项）也将被重新处理。

图 5-40

应用

对已完成的工作进行重新处理并不少见，但该 模式最为重要的部分还是在于要求所有后续工作的重新处理。所以该模式一般应用在极其重要的关键任务节点，例如非常重要的决策节点，因为后续的任务严重依赖 于该节点所作出的决策（所产生的数据），一旦决策发生变化，那么相应的后续工作必须都要做出变化。这也是业务敏捷性的一种反映。同时需要注意，该模式也是 一种代价高昂的应用，因为这往往意味着该业务流程实例中的很多工作都需要重新处理，所以如何在业务处理中尽早发现可能的环境变化并及时作出决策的调整并避 免成本高昂的返工才是最为重要的一点。

现在的软件开发越来越强调于拥抱变化，强调 代码的重构和演进，尽管如此，如果软件的基础架构需要根据当前业务变化发生重大变更，那么这依旧是一件成本高昂的事情，因为一旦基础架构发生变化，那么很 多模块实现将不得不重新编写代码。所以尽管越来越多的开发团队开始引入敏捷的开发方法，但是经验丰富的开发人员才是整个敏捷团队的基石（敏捷开发非常重视 人）。

实现

从该模式里能够看到资源模式与控制模式的结合，工作项的重做需要后续任务的重新执行，这需要取消当前的执行任务，并将流程实例的控制点重新返回至该工作项所对应的任务。这涉及到两种控制模式，分别是：取消任务模式和任意循环模式（具体可以参考第四章的说明）。

9、提前执行（WRP_35: Pre-Do）

描述

在工作项实际提供或指派给资源执行之前，资源已经可以执行该工作项。

图 5-41

如图5-41所示，任务A还在执行，任务B还未激活，但此时员工甲已经可以开始执行任务B的工作项。该模式的实现需要一个前提条件：任务B不能依赖于任务A的执行结果，即不能依赖于前续任务的处理输出。

可以看出，该模式与前面推模式里的提前分配模式非常相似，所不同的是：提前分配强调一种通知机制，强调预先准备；而提前执行则已经可以开始实际的执行工作。

应用

和提前分配模式不同，该模式实际提供了一种 流程任务执行的灵活机制，在预先定义的业务流程里，任务的执行是具有一定顺序的，可能在大多数情况下，这种顺序是合理的，但是在某些具体的流程实例里，某 些串行执行的任务节点可以并行的执行以达到最好的执行效率和负载均衡，在这种情况下，就可以应用该模式并行执行部分任务。

需要注意的是，该模式仅仅引入了一种实际执行任务的灵活性，是对业务流程定义固化的补偿，如果在一个业务流程中频繁应用到该模式，则往往意味着流程定义本身需要作出调整。

与推模式相比，拉模式的区别在于动作的主语发生了变化：推模式的主语是系统，由系统将工作项推送至资源的工作项列表，那么，接下来的主动权交由单个资源本身，由其拉动工作项的执行。

图 5-28

如图5-17所示，拉模式对应着工作项的五种状态变迁：

由提供给一个资源拾取到指派给一个资源负责执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项；

由提供给多个资源拾取到指派给一个资源负责执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并将在未来的某个时候执行该工作项，余下的资源将不再有机会执行该工作项；

由提供给一个资源拾取到开始执行，这意味着该资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项；

由指派给一个资源负责执行到开始执行，这意味着该资源开始执行该工作项；

由提供给多个资源拾取到开始执行，这意味着多个资源中的一个资源拾取了该工作项，其将负责该工作项的执行，并立即开始执行该工作项，余下的资源将不再有机会执行该工作项；

拉模式共有6种，分为两组：前三种模式关注工作项的状态变迁；后三种模式关注工作项显示在资源工作项列表里的顺序以及选择执行的方式。

1、资源驱动指派（WRP_21: Resource-Initiated Allocation）

描述

资源能够将工作项指派给自己，负责该工作项的执行，但是不必马上开始执行该工作项。

图 5-29

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项，该工作项由可拾取列表移至待办列表。可拾取列表通常是一个共享的列表，而待办列表则是某一资源的专属列表。资源拾取工作项，意味着工作项从共享状态进入到专属状态。

该模式实际对应着工作项的两种状态变迁：由提供给一个资源拾取到指派给一个资源负责执行；由提供给多个资源拾取到指派给一个资源负责执行。

应用

该模式符合大多数的工作场景，我选择负责执行该工作，但我并不马上开始，我可能还有其他的工作需要处理，等到处理完毕后才处理该工作。

实现

分配给角色、部门等资源组的工作项通常都以共享的形式分配给所有的组内成员，一旦有人拾取即进入他的专属待办列表，其他人不再可见。

2、资源驱动执行-指派工作项（WRP_22: Resource-Initiated Execution – Allocated Work Item）

描述

资源能够开始执行指派给其的工作项。

图 5-30

如图5-30所示，员工甲开始执行任务A工作项，该工作项由待办列表移至办理列表。

该模式对应着工作项的一种状态变迁：由指派给一个资源负责执行到开始执行。

实现

最基本的工作项状态变迁，所有的工作流系统都提供支持。

3、资源驱动执行-提供工作项（WRP_23: Resource-Initiated Execution – Offered Work Item）

描述

资源能够选取提供给其的一个工作项，并马上开始执行该工作项。

图 5-31

如图5-29所示，员工甲拾取了可拾取列表里的任务A工作项并立刻开始执行，该工作项由可拾取列表移至办理列表。

该模式对应着工作项的两种状态变迁：由提供给一个资源拾取到开始执行；由提供给多个资源拾取到开始执行。

应用

与描述略有不同，实际应用该模式是强制要求资源一旦拾取了共享的工作项就必须马上开始执行，基于两点的考虑：一是工作项能够尽快执行；二是工作项能够指派给当前最为空闲的资源，不会出现该工作项被一繁忙资源卡住，造成等待和阻塞。

在敏捷开发里，我们使用故事卡管理项目的开 发，故事卡足够小（如果大的故事卡则分解为多个任务），每天早上由开发人员挑选移动该卡，一旦该卡由可开发状态移动至开发状态，则必须进行该卡的开发工 作，这样项目的真实进展随时得到显示，同时不允许一个开发人员同时进行多张卡的开发。

实现

通过这三个模式我们可以发现，工作流系统实现这些模式只是在不同的工作项列表里移动这些工作项，以反映工作项不同的状态和变迁策略，这对于IT系 统而言这不是很困难，困难在于如何能保证人确实是这么做的，例如说一旦拾取就必须开始执行，工作项的跳转很简单，但无法保证的是拾取该工作项的人一定会按 照要求马上开始执行该工作项，也就是说业务流程项目的实施不仅仅包含技术实施，也包含了一套与之相应的管理实施。那种期望上一套流程系统就能马上提高生产 效率和管理水平显然是不现实的，其中一定包含管理方式的变化和组织机构的变化。

敏捷开发中，早上的站立会议是重要的部分，每个团队成员都会汇报昨天的进展和今天将要进行的工作，这样就保证了工作执行的有效性。

4、系统决定工作队列内容（WRP_24: System-Determined Work Queue Content）

描述

工作流系统能够排定资源工作项列表里的工作项顺序和内容。

图 5-32

如图5-32所示，员工甲共享的可拾取列表默认按时间排序工作项。

应用

实际应用中工作项的排序条件非常多，其目的就是将最重要或优先级最高的工作项排在最前面，引起资源的注意或优先执行。

实现

实际实现时有多种排序策略，通常会有时间排序，例如先进先出、先进后出等，同时也有很多其他的排序元素，例如工作项的预定完成时间、执行该工作项的成本预算、工作项的优先级或重要程度等，系统查询工作项时根据这些影响因素进行默认排序。

5、资源决定工作队列内容（WRP_24: Resource-Determined Work Queue Content）

描述

资源能够排定其工作项列表里的工作项顺序和内容。

应用

为资源提供一定程度上排定工作项的灵活性。每个人关注的视角和侧重点不同，就会产生不同的排序和内容过滤。

例如，作为老板，我可能更为关注各个工作的成本预算，我需要按成本排定各项工作；而作为秘书，我更为关注老板下发各项工作的重要程度，我需要按老板指定的重要程度排定工作。

实现

提供工作项列表的客户端排序，一般情况下列表显示系统给定的顺序，用户可以在客户端进行二次排序，典型的Web系统中，工作流系统提供JavaScript的表格控件，利用Ajax异步请求重新排序或进行工作项的过滤。

6、自主选择（WRP_26: Selection Autonomy）

描述

资源能够根据自己个人的情况选择执行工作项。

图 5-32

如图5-32所示，员工甲能够根据自己的情况选择执行任务A、B、C中任意一个工作项。

应用

尽管老板要求先实现功能最后再重构，但是我认为当前代码如果不进行一定重构会严重影响后续的开发效率，所以我决定先进行部分重构。

实现

几乎所有工作流系统都不会对用户实际选择执行工作项的方式进行限制，也没有办法限制。但是系统一般会把重要的工作项加以高亮显示，让用户优先选择。

在创建阶段，系统根据不同的创建模式为任务 节点产生了一个或多个工作项，每个工作项或分配给单个资源或分配给角色、部门等。那么接下来，系统就需要将这些工作项推送给相关的资源进行执行，这个推送 的过程即是推模式所包含的内容。需要注意的是，推模式讨论的是对单个工作项的推送。

在前面我们已经了解到，工作流系统通过工作项管理器即不同类型的工作项列表与用户进行交互，这里的推送也可以理解为系统将生成的工作项推送至相应资源的工作项列表里。

图 5-17

如图5-17所示，推模式对应着工作项到三种状态的变迁：提供给一个资源拾取执行；提供给多个资源拾取执行（这些资源中只会有一个会实际执行，属于竞争关系）；指派给一个资源负责执行。

推模式共有9种，分为3组， 第一组包括提供给单个资源、提供给多个资源和指派给单个资源，讨论工作项推送的最终分配状态；第二组包括随机指派、循环指派和最短队列指派，关注当工作项 分配给角色、部门等包含多个资源的资源组时，如何从中确定最终的一个资源并进行指派；第三组包括提前分配、即时分配和推后分配，关注将工作项推送给用户的 时间。

1、提供给单个资源（WRP_12: Distribution by Offer - Single Resource）

描述

能够在非绑定的基础上将工作项推送给单个资源。

图 5-18

如图5-18所示，任务A工 作项被系统推送至员工甲的可拾取列表。这意味着员工甲不必为该工作负责，他可以选择执行该工作也可选择忽略或拒绝。如果他选择拒绝或忽略且工作项超时，那 么会导致系统对该工作项的重新分配。如果他选择执行该工作，那么他首先需要拾取该工作项，这会使该工作项进入他的代办列表，意味着其必须对该工作负责。

应用

该模式类似于现实工作中的征求意见，先将工作分配给你，然后找你谈话，征求你对该工作的看法，如果合适那么就由你执行，否则再找他人执行。

实现

参与者对工作项的拒绝会导致系统对工作项的 重新分配，这是实现该模式的难点。如何重新分配该工作项，采取何种重新分配策略，这些都具有很大的复杂性。实际上这些工作流模式单个看起来可能比较清晰明 了，但一旦组合起来，例如该模式与创建模式结合起来，那么就有了多种情况变得复杂起来。对于复杂的问题，最好的解决办法就是留给实施阶段，由用户情况作出 使用限定。这也再次强调了工作流实施在工作流应用中的重要性。

2、提供给多个资源（WRP_13: Distribution by Offer – Multiple Resource）

描述

能够在非绑定的基础上将工作项推送给多个资源。

图 5-19

如图5-19所示，任务A所 生成的工作项被推送给多个员工的可拾取列表。这些员工不必为该工作负责，他们可以选择执行该工作也可选择忽略或拒绝。如果他们都选择拒绝或忽略且工作项超 时，那么会导致系统对该工作项的重新分配。如果有一名员工选择执行该工作，那么该工作项进入他的代办列表，其他员工将不再具有拾取该工作项的机会。

应用

该模式是典型的竞争参与，即多人可以完成该工作，先执行者先得。类似于寻找志愿者。

实现

该模式的实现一般是创建阶段将工作项分配给角色、部门等包含多个资源的分组，在推送阶段，将该工作项送至这些组下所有资源共享的可拾取列表里，工作项的实例只有一个，但是多资源可见。

3、指派给单个资源（WRP_14: Distribution by Allocation – Single Resource）

描述

能够在绑定的基础上将工作项推送给单个资源。

图 5-20

如图5-20所示，任务A工作项被系统推送至员工甲的待办列表。这意味着员工甲必须为该工作负责。

应用

该模式是应用最多的模式，直接指定任务的负责人。

在采用军事化管理的企业里，上级的命令一定要执行，下属没有商量和拒绝的权利。

实现

相比提供，指派实现非常容易，直接将工作项推送至选定资源的待办列表。

4、随机指派（WRP_15: Random Allocation）

描述

当存在多个资源可供选择时，从中随机选择一个资源进行工作项的指派。

图 5-21

如图5-21所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统会随机选取一名开发人员负责该工作项的执行。

应用

该模式提供了一种指派资源的非确定性机制。

5、循环指派（WRP_16: Round Robin Allocation）

描述

当存在多个资源可供选择时，循环选择其中一个资源进行工作项的指派。

图 5-22

如图5-22所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统会循环轮流选取一名开发人员负责该工作项的执行。

应用

不患贫而患不均，平等的分配工作。

6、最短队列指派（WRP_17: Shortest Queue）

描述

当存在多个资源可供选择时，选择其中一个具有最少待办工作即最短工作队列的资源进行工作项的指派。

图 5-23

如图5-23所示，任务A所生成的工作项在创建阶段分配给了开发人员这一角色，在推送阶段，系统发现员工甲的待办列表里有两条待办工作（任务B和任务C），员工乙的待办列表里没有待办工作，所以系统将任务A工作项指派给员工乙负责该工作项的执行。

应用

该模式的目的在于能够最快开始工作的执行，找出相比而言最为空闲的资源迅速开始工作。但是实际应用中，仅仅依靠工作的数量来判断资源是否空闲是不可靠的，因为工作和工作之间还存在着难易之分。

7、提前分配（WRP_18: Early Distribution）

描述

在工作项实际可以执行之前即将该工作项通知或潜在的分配给资源。

图 5-24

如图5-24所示，任务A还在执行，任务B还未激活，但此时任务B的工作项已经提前分配给员工甲，该工作项的主要职责是通知员工甲将由其来完成任务B并能开始一部分准备工作，而实际的工作则要等到任务B被激活后才能进行。

应用

该模式强调的是预先计划，即管理的计划性。

在我们实际的项目开始之前，项目经理已经通知我们将要进行的开发工作，让我们提前熟悉相关的技术。这样当项目开始时就能提高最初迭代的开发效率。

从某种意义上说，稍微复杂一点的工作都应该做到提前通知、提前准备，即计划的必要性。

实现

让工作流系统直接支持该模式比较困难，因为该模式嵌套在控制模式和不同的工作项创建模式里，找不出一种通用的模式，无法预判工作项的生成和实际的参与者。在一定范围内，可以采用下面的方式变通：

图 5-25

如图5-25所示，在自动节点执行时能确定任务B的参与者的情况下，可以通过自动节点给员工甲发送邮件或消息进行通知，工作流系统并不生成工作项。

8、即时分配（WRP_19: Distribution on Enablement）

描述

在工作项实际可以执行时将该工作项分配给资源。

应用

机器执行的工作，重复单一的审批工作，无计划性的工作，如各种突发情况的处理。

实现

大多数工作流系统的标准实现，满足任务执行条件时先激活任务节点，然后创建工作项、分配工作项。

9、推后分配（WRP_20: Late Distribution）

描述

在工作项实际可以执行后的某个时间才将该工作项分配给资源。

图 5-26

如图5-26所示，任务B已经激活且已生成可以执行工作项，但是系统并没有将其分配至员工甲的工作项列表里。这是因为员工甲正在执行任务A的工作项，直到其执行任务A完毕，系统才会把任务B工作项推送至工作项列表。

应用

保证流程和资源对工作的负载处于一种良好的状态，避免出现下图的情况：

图 5-27

在敏捷开发里，我们强调客户合作，整个的开发过程对用户透明，用户知道当前正在进行的开发工作，也清楚开发团队的开发速度，在这种情况下，一旦有新的需求加入，用户会推迟该需求的实现，或者推迟当前其他需求的实现，从而保证整个团队的开发效率。

实现

该模式的实现依赖于推后的策略，即在什么情况下推后分配，满足什么条件下进行分配。具体实现同样采取推后模式，推后到实施阶段实现。

创建模式在系统创建工作项时生效，如下图所示，其位于工作项生命周期的创建阶段。

图 5-2

正如上面提到的，工作流系统在执行任务节点时会为其创建相应的工作项，根据情况工作项可以是一个也可以是多个。

创建模式作为流程模型的构成部分在流程设计期指定，通常在任务节点的定义里进行定义，与一个任务关联，其用来限定可执行该任务的资源范围。系统根据创建模式限定的资源范围生成工作项，工作项可以直接分配给人，也可以分配给角色、部门、岗位等。

1、直接分配（WRP_01: Direct Distribution）

描述

在设计期直接为任务指定特定的资源，该任务的工作项能够在运行期分配给它。注意，指定的资源可以为多个，如果是多个的话就会生成多个工作项，为每个资源生成一个单独的工作项。该模式实际限制执行该任务的资源范围。

图 5-3

如图5-3所示，任务A在定义时直接指定给员工甲，任务B在定义时直接指定给员工乙，当实际执行任务A和任务B时，将由员工甲和员工乙分别执行。

应用

该模式一般应用于流程里的关键路径。同时， 在中小企业里，该模式是应用最多的分配模式，因为人员少，管理扁平，所以每个人的职责都非常清晰。该模式也是执行效率较高的资源模式，因为人和任务直接绑 定，所以不会产生推诿等情况，便于管理也便于追究责任，因为运行情况完全在设计期确定。而随着企业规模的扩大，管理层次的复杂，一个任务往往需要交由特定 的部门、岗位或角色来执行，这样无形中会影响任务执行的效率。

该模式的缺点在于一旦关键人物因为各种原因不能及时处理任务，那么将造成整个流程的挂起等待。

实现

最简单的资源模式，设计期确定资源，运行期工作流引擎不需要做额外的工作。

2、基于角色的分配（WRP_02: Role-Based Distribution）

描述

在设计期为任务指定一个或多个角色，该任务的工作项能够在运行期分配给这些角色。实际执行该任务时，资源将从属于这些角色的资源中产生。该模式实际限制执行该任务的资源范围。

图 5-4

如图5-4所示，任务A在定义时指定给“开发人员”这一角色，该角色包括了两名员工甲和乙。实际执行任务A时，将由员工甲或乙来执行。

应用

企业达到一定规模，就会产生人员的分组，角色是典型的分组方式，将具有相似属性的人员定义为一个特定的角色，这些属性通常与工作的内容相关，例如开发人员、项目经理、总经理等，而角色通常又会与权限产生关联。

将任务分配给角色意味着将会有多个员工可以执行该任务，执行效率相比直接分配会有下降，这也是企业扩大后管理成本增大的一种表现形式。

实现

工作流系统内置的组织机构模型需要对角色进行支持。引擎运行期通过角色访问属于该角色的人员。

3、延迟分配（WRP_03: Deferred Distribution）

描述

在设计期为任务指定资源的标识，典型的，在工作流系统里，该标识对应于一个数据字段变量，例如userid。即在设计期并不确定资源，资源的确定被延迟至运行期，系统运行期从该数据字段里获取该任务分配的资源。

图 5-5

如图5-5所示，任务B在定义时资源的标识指定为userid，实际执行时，任务A由员工甲执行，其指定了下一任务的执行者为员工乙即设置了userid这一变量为员工乙的id，在任务B实例创建时，它访问userid，发现该变量里是员工乙的id，于是将该任务分配给员工乙。

需要注意的是，根据具体的分配策略，运行期该数据字段不仅可以指定人员，也可以指定角色、部门等。

应用

该模式给资源的分配引入了灵活性。资源的确定延迟至运行期，即任务可以根据具体的实际情况再确定执行人。具体实施时，这个指定的数据字段可以通过一系列的规则运算得出。

在国内应用中，该模式被大量应用在人工干预流程中，例如下一任务的执行由上一任务的办理者指定。

实现

一般通过工作流变量来包含资源的id。为了区别该id是人员id还是角色id，一般内置特殊变量，例如userid、roleid、groupid等。

4、按权限分配（WRP_04: Authorization）

描述

能够指定资源的范围，只有该范围内的资源才具有执行该任务的权限。

图 5-6

如图5-6所示，只有项目经理才有权限对开发人员申请软件的要求进行批准。

应用

随着分工的细化，每个人工作内容的不同，必然会产生权限的概念。权限实际代表着对同一件事情，每个人执行工作内容的差别。权限越大能执行的操作越多意味着需要负责的方面越多。

该模式强调通过权限对执行任务的资源加以限定。

实现

在大多数的软件系统中，角色不仅仅代表具有相似属性的一组人员，同时其也是最重要的权限概念，人员往往不与权限直接关联，角色将人员与权限两者进行关联。所以，对任务设定权限可以通过指定角色来完成。

5、职责分离（WRP_05: Separation of Duties）

描述

在一个流程实例里，能够指定两个任务必须由不同的资源执行。

图 5-7

如图5-7所示，任务A和任务B在设计期被指定不能由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，尽管员工甲也属于经理，但是将不能由其执行。

应用

职责分离，不能既当运动员又当裁判员，不能又当跳水队领队又当全运会裁判长。

典型的报销流程里，一般员工的差旅报销由财务人员核实，但如果某名财务人员需要报销差旅费显然不能由自己审批，需要另外一名具有同样权限的财务人员审核。此时就可以对申请任务和审核任务两个任务节点应用该模式。如下图所示：

图 5-8

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。

6、流程实例整个处理（WRP_06: Case Handing）

描述

在一个流程实例里，所有的任务都能够分配给同一个资源执行。

图 5-9

如图5-9所示，流程实例中的所有任务都由同一个人执行：任务A、B、C都由员工甲执行。

应用

在应用该模式的流程里，通常流程里的任务都 是紧密关联的。流程里的任务往往执行在一个紧密相关的上下文里，如果所有的工作都由一个人执行，那么在其了解该上下文的情况下连贯执行这些任务会具有更高 的效率；而如果执行任务的过程中换人，那么新换的人无疑还需要时间对该流程实例相关的上下文进行熟悉，这样无疑会多付出执行成本。

同一个软件的开发最好由同一拨开发人员完成，如果中途更换开发人员，那么新来的开发人员需要一段时间熟悉该软件，会对开发进度产生影响。同样的道理，在软件上线前增加开发人员不一定会提高开发效率，很多时候甚至作用相反。

实现

可以在实现延迟分配模式的情况下实现该模式，即在第一个任务节点初始化设置参与者变量，后续任务全部使用该变量。如下图所示：

图 5-10

7、经验获取（WRP_07: Retain Familiar）

描述

在同一个流程实例里，当存在多个资源都能执行某一工作项时，能够将该工作项分配给执行了前某一工作项的同一资源。

图 5-11

如图5-11所示，任务A和任务B在设计期被指定由相同的资源执行，同时它们都指定分配给经理这个角色。那么在运行期，在一个流程实例里，任务A被分配给了员工甲执行，那么在进行任务B的分配时，任务B依旧由员工甲执行。

应用

该模式刚好与职责分离模式相反，正如它的名字所暗示的，这些任务之间存在着紧密关联，如果执行了其中一个，那么就会熟悉这些相关联任务的背景上下文，积累一定经验，那么后续任务的执行相对其他人来说会变得容易。提高任务执行的效率。

图 5-12

如图5-12所示，在软件销售的过程中，售前和编写标书是重要的两步，这两个任务最好由同一个人进行处理，因为参与软件售前的人更熟悉客户的实际情况和需求，如果分开由不同的人员执行，那么必然会存在前者与后者的交流成本。

实现

后续节点进行任务分配时，需要获取与之关联前续节点的分配执行信息。流程定义期，在定义任务节点属性时建立两者的关系。运行期可以通过参与者变量（工作流变量）建立起运行期关系。

8、基于能力的分配（WRP_08: Capability-Based Distribution）

描述

能够基于资源的能力进行工作项的分配，能力作为组织模型的一部分建模为资源的属性。

图 5-13

如图5-13所示，任务A需要交与开发人员执行，同时其对办理该任务的人员能力提出了要求，要求只有熟悉JAVA且工作经验大于2年的开发人员才能执行该任务。这样就缩小了选取资源的范围。

应用

人力资源管理中很重要的一点就是要做到人尽 其用，每个人的能力都能得到最大的发挥，其实也就是根据能力将人放置到最合适的工作中去。从这一点看，该模式是对人尽其能的实现。但是如何定义各个人员的 能力，这本身就比较的主观，执行各项工作需要具备的能力也具有主观因素，更何况很多时候能力并不能与表现划上等号，模型是固定的但人是变化的受环境影响 的，所以工具本身就是工具，工具的应用最后还是依赖于人。

实现

实现需要两部分：一部分是组织机构对人进行建模时需要包括能力模型；另一部分是流程建模时需要给任务定义执行该任务所需的能力约束，这些约束是一系列的领域特定条件，需要有特定的解析器进行条件的解析。

很多工作流引擎提供有参与者接口，接口返回人员ID列表供给任务分配，从而将这部分工作委派到工作流实施时实现。

9、基于历史的分配（WRP_09: History-Based Distribution）

描述

能够基于先前的工作历史决定当前任务的分配。

图 5-14

如图5-14所示，当需要在员工甲和员工乙之间做出选择时，会选择此前执行类似任务时完成最好的员工。需要注意的是，这里的历史不再是限定在同一流程实例的任务执行里，可能是同一流程模型的执行历史，也可能是不同流程模型的执行历史。

考虑历史时，有很多的考虑因素，例如完成类似任务最好的员工、完成类似任务最快的员工、完成类似任务出差错最少的员工等等。这些考虑因素依赖于具体的任务内容和背景。

应用

国家篮球队比赛前，主教练会考察各个位置里各个球员的联赛比赛历史情况，其中不仅会考虑出场时间也会考虑各项数据，从而做出选择。

实现

同基于能力的分配模式一样，该模式的实现依赖于工作流具体应用的场景，也就是需要到实施阶段结合实际实现。从某一种角度也说明，应用工作流产品时，产品实施阶段也是最重要的步骤，选择工作流产品不仅仅是选择产品也需要考察其背后的实施团队。同时也可见，这些模式在诸如政府OA这些应用中是根本应用不上的。

实现需要两部分：一部分是对用户任务执行历史进行统计分析找出关键的评定因素；另一部分是流程建模时需要给任务定义执行该任务所需的历史因素约束，这些约束同样是一系列的领域特定条件，需要特定的解析器进行解析。

10、按组织分配（WRP_10: Organizational Distribution）

描述

能够基于人员在组织机构中的位置以及与其他人员的关系分配工作项。

图 5-15

如图5-15所示，审批任务需要由申请人的部门经理执行，即需要员工甲的部门经理执行。这种情况即基于人员之间的关系分配工作。

基于人员在组织机构中的位置分配即需要在工作流模型里建立起与用户相匹配的组织机构模型，可以将任务分配给部门、角色、临时组、岗位等。

应用

应用最为广泛的模式，实际工作中几乎所有的工作都必然和组织机构具有联系。其他模式，如基于历史的分配、基于能力的分配等都是基于该模式之上的扩展，直接分配、基于角色的分配则直接是该模式的简单情况。

实现

对该模式的支持实际上是对用户组织机构模型的支持。正如前面所提到的，很难存在一种工作流产品能够支持所有的组织机构模型，但是大部分的产品都会提供一套元模型或扩展机制，需要在实施过程中最大限度的契合客户业务。

11、自动执行（WRP_11: Automatic Execution）

描述

任务的执行能够自动完成，不需要人员参与。

图 5-16

如图5-16所示，请假审批后需要将情况通知给申请人，该任务由计算机完成，不需要人的参与，也不会产生工作项。

应用

随着自动化水平的提高，越来越多的工作可以交由计算机或相应的机器设备完成。流程中的自动执行节点也会逐渐增加。

实现

实际上工作流产品对该模式的支持即是支持各种的企业集成方式，不管是通过Web服务还是消息，工作流需要驱动相应的设备机器或应用系统进行工作并传递给必须的数据。所以也可以看出，随着信息化程度的提高，目前工作流应用越来越趋向于企业集成领域。这也是为什么基于Web服务编排的BPEL会逐渐取代XPDL成为工作流流行标准的原因之一。