三、推模式

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

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

图 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成为工作流流行标准的原因之一。

在上一章里，我们谈到了工作流的控制模式，控制模式强调的是对业务流程进行建模，业务流程的目标是实现一个商业目标或者管理目标，业务流程的执行往往由一系列的任务所构成，控制模式建模的实质在于合理调配这些任务，以期以最少的成本达到最大的收益。

本章将介绍工作流的资源模式，如果说控制模式更为宏观，强调的是业务流程里各个任务的合理调配的话，那么资源模式则深入细节，将要讨论单个具体任务的执行情况。提到任务的执行，那么谁能执行这些任务呢。答案很直接，是人。不管是在公司企业还是政府里，人都是最重要的资源，除去人之外，还有其他的非人力资源，例如机器、设备、计算机等。探讨这些资源如何执行业务流程中的具体任务，如何调配这些资源即构成了本章的内容，即资源模式。

本章介绍工作流的资源模式，共计43种。提到模式，很多人会想到四人帮，想到他们的设计模式，但是需要与编程里的设计模式区别的是：程序里的设计模式关注的是代码，通过应用设计模式做到代码的职责清晰、不重复、开发人员友好等等；而工作流里的模式关注的是业务价值，通过合理调配任务和资源为组织带来最大的业务价值，工作流模式是对实际业务的直接描述，与具体的工作流产品实现没有直接的关系（后面我们可以看到，很多模式当前的工作流产品很难实现），两者的出发点完全不同。

本章先会讨论与资源模式相关的一些基本概念，例如资源、工作项、组织机构建模等。接下来会对具体的43种资源模式进行讨论，讨论的模式按照描述、应用和实现展开，分别对应着模式的介绍、模式对实际业务的映射和工作流产品对该模式的实现支持。最后是小结。

一、基本概念

1、资源
既然是资源模式，那么什么是资源。在本章的前言里，我们已经提到人是业务流程执行里最为重要的资源，除去人之外，随着自动化水平的提高，还有其他的非人力资源，例如机器、设备、计算机等。资源指的是能够进行工作的实体，通俗一点，就是能够执行业务流程里任务的实体。对于需要盈利的公司而言，就是找到一种可以盈利的模式，然后找寻能够执行这些盈利工作的资源，通过资源的工作达到盈利的目的，通过合理调配这些资源达到利益最大化。

因为人是最为重要的资源，所以在后续对资源模式的讨论中，没有特殊说明，资源指的都是人力资源，大多数的模式也将以人来说明。

典型的，人是某个组织机构里的成员。组织机构对人员进行分组，执行相关的工作以达到共同的目标。例如，企业的目标是盈利，政府的目标是为人民提供更好的公共服务。组织机构对人员的分组具有多种形式，最常见的就是部门、角色和岗位（实际上与角色相比，岗位更多体现的是一种业务职能，而角色更多体现的是管理职能，与权限相关）。对于大的跨地域的组织而言，还有分支机构的划分，此外，还有临时组（典型的如以交付为核心的软件开发公司里的项目组）。在很多情况下，人可能具有多个角色、属于多个部门，这些，增加了管理的复杂性。

对工作流产品而言，要对资源模式进行支持，则必然涉及到对资源分组的支持，在大多情况下，资源分组即组织机构模型。只有支持目标客户的组织机构模型，才能在实施工作流产品时最大限度的契合客户业务。当然，如果产品是某个行业的标准，让客户模型向产品靠拢也是另外一种方式。

2、工作流产品里的组织机构建模
所有的工作流产品都有自己的组织机构模型，其是工作流产品里一个重要的模块。但是一套模型往往很难契合多种业务场景。在大多数的产品实现里，都会提供一套元模型，例如人（Person）和组（Group），然后建立多套与业务相关的模型向元模型适配，例如，角色、部门都是组的一种形式，它们只是拥有不同的业务语义而已。

在工作流产品实施时，很重要的一步就是进行组织机构建模，然后将建立完成的模型与工作流产品内置的模型进行适配，在适配的过程中，妥协是经常出现的。

3、工作项
一个业务流程由一系列相关的任务组成。在工作流产品里，使用图形化的节点代表这些任务，而实际的任务被映射为工作项（work item），任务的调用被映射为工作项的执行。一般情况下，一个任务对应着一个工作项，但是存在一个任务需要多人完成的情况，这个时候一个任务就会对应着多个工作项。工作项可以看作是工作流中最小的工作单元，其代表着一个单一资源对某一任务的执行。

既然在工作流系统里任务的执行被映射为工作项的执行，那么就一定存在着人与工作项这个计算机概念的交互，在工作流系统里，这一交互通过工作项管理器来进行管理。即我们通常所见的工作项列表（任务列表），我们通过这一列表拾取任务、处理任务以及管理任务的状态。

4、工作项的生命周期
工作项有其自己的生命周期。
 
如图5-1所示，当工作流系统执行某一任务节点时就会创建工作项，工作项可以是一个也可以是多个，正如上面已经提到的，工作项代表着一个单一资源对某一任务的执行即一个工作项只能由一个资源来执行，现在我们讨论的是一个工作项的生命周期。

工作项被系统创建完毕后即处于创建状态，接下来系统会选取资源来执行该工作项。有两种状态：一种是提供状态，一种是指派状态，这两者的区别在于一个是可选的一个是必须的。如果系统提供一个工作项给你执行，这意味着你符合执行该工作的条件，但你不必为该工作负责，即你可以选择执行该工作也可以选择拒绝，你只是该工作的合适候选者；而如果系统指派一个工作项给你执行，则意味着你必须为该工作负责，该工作必须由你来执行。因为一个工作项只能由一个资源来执行，所以如果是指派的话，那么只能指定一个资源；而提供，则可以提供给一个资源也可以提供给多个资源来候选。通常工作项管理器会提供两种列表来区分这两种状态，分别是待拾取列表和待办列表，一旦资源对待拾取列表里的工作项进行拾取，工作项即进入到资源的待办列表，状态成为指派状态。

工作项进入指派状态即意味着执行该工作的资源已确定，那么接下来就可以由资源来开始执行该工作，执行的过程中可以将工作暂时挂起中断处理，后续可以再恢复对该工作的执行。如果工作成功完成，则工作项成为完成状态；如果工作因为各种原因没有成功完成，则工作项置为失败状态。
似乎一到年末，就会忙起来。

05年的时候忙着和现在的老婆谈那从来没谈过而导致过分饥渴的恋爱；06年的时候新配置了机器，忙着通关使命召唤和生化危机；07年的时候和张祖良一起翻译AJAX企业级开发，第一次翻译，忙得像黄牛，慢得像蜗牛，在心里祈祷，翻译出来的东西不被骂就好；08年的时候和丁雪峰、总司令又一起翻译Spring攻略，第二次翻译，熟练了一些，但是每一个句子还是要花上很多时间，很多时候还得一个词一个词的确认，翻译对我来说是个苦力活，第一次翻译完我就告诉自己不要再翻译了，但是Spring攻略确实是一本好书，完全是书本身吸引了我，同样在心里祈祷，不要糟蹋了这本书。09年了，和辛鹏一起完成这本《Head First Process-深入浅出流程》，还是祈祷，千万不要写出垃圾，有时候，我常想，有必要这么辛苦吗？我是一个喜欢意淫的人，经常就把思绪抛到了多年之后，在未来里洋洋自得，于是回来时就有了动力。

我负责该书的第一部分，包括了工作流的控制模式、资源模式、数据控制模式与异常处理模式，包括了对三种流程规范的介绍、对开源工作流的介绍、对jBPM4的分析。辛鹏负责该书的后半部分，他对流程应用有着非常丰富的经验，目前他正在杭州实施一个BPM的大项目，其中包括了完整的IBM产品套件，包括了企业集成和ESB。很多人认为工作流只是OA，这其实是一个误区，工作流确实在OA里应用的非常多，但这仅仅只是一个方面。说实话，我对本书也非常的期待，非常期待辛鹏在书中分享他众多的实施经验，他是一个非常勤奋的人，这点让我钦佩不止，常常想，等我到了30多岁，还会不会有一颗勤奋的心。

家住燕郊，上班在东直门，每天在路上四个小时，挤那传说中的930，时常安慰自己：哥挤的不是930，哥挤的是寂寞。谢谢老婆，尽管还还着房贷存在着心理障碍，但是还是为我在东直门租了个房子，下周起就可以走路上班了，这样也会有了更多的时间来完成这本书。

还是那句话：战战兢兢。

十一过完，公司的新项目也开始了，时尚网站。技术栈包括了：OSGI、JCR、REST、渐进式增强。该项目有个巨大的亮点，不是徐昊是我们的技术leader，而是开发人员中一半是女生，这样每天pair的时候就生活在祖国的花园中了。

希望能写些有价值的东西，征得刘江的同意，将会在博客连载部分章节。第一部分连载的将是工作流的资源模式，内容包括前言、基本概念、创建模式、推模式、拉模式、迂回模式、自动开始模式、可见性模式、多资源模式以及最后的小结。限于篇幅，将会分节进行连载。考虑到复制麻烦，将会在开放流程社区连载所有内容，博客会连载概要并提供链接。



一、    代码主要结构
所谓流程设计器者，无怪乎读取xml文件，图形展现，操作图形元素，改变xml文件，回写，如此而已。

既然如此，设计器的流程结构就非常清晰：首先是xml框架解析xml文件为Model模型组件，然后Model模型组件被展现为Component视图组件；用户对Component视图组件进行操作，这些操作被同步的修改到Model模型组件；最后用户保存时，Model模型组件经过xml框架解析回xml文件，该文件被上传到服务器或本地覆盖原有的xml文件。

那么代码结构就很清晰了：xml框架、Model模型组件和Component视图组件。但是等等，Model与Component如何交互呢？这里就需要GEF框架嫁接起两者的联系。同时，一个流程设计器往往要同时编辑多个流程定义，相比具体的流程定义而言，设计器拥有一些全局的对象，这些全局对象包括系统菜单栏、工具条、整个设计器布局框架（ProcessDesigner）、设计器入口（ProcessEditor），还有就是负责保存全局属性和发布/订阅定制事件的TheModel对象。

二、    Component视图组件
很直接，Component视图组件指的是与用户打交道的、与流程定义相关的视图元素。注意这里的一个定语：与流程定义相关的，即不包括系统菜单、工具条这些东东。这些视图元素很简单，包括画图板、各种节点元素和连接线元素。

代码位于org.jbpmside.view.component和org.jbpmside.view.component.node下。主要类SurfaceComponent、NodeComponent和ConnectionComponent。看类名就很清晰这些类分别代表着什么组件：
•    SurfaceComponent代表画图板；
•    NodeComponent代表节点；
•    ConnectionComponent代表连接线；

org.jbpmside.view.component.node下的类就是NodeComponent类的子类，代表具体的单个节点类型了，包括开始节点、结束节点、Fork节点、Join节点等等。

Component视图组件使用了degrafa来渲染表现形式。

目前缺少一个属性弹出框组件，职责展现和修改节点/连接线属性。

三、    Model模型组件
Xml流程定义文件解析为本地Model模型组件，本地建模和jBPM4的PVM建模一致，代码位于org.jbpmside.model下，重要的类：
•    ProcessModel代表流程定义；
•    NodeModel代表节点定义；
•    ConnectionModel代表连接线定义；
剩下的就是具体节点类型的模型类，例如StartNode/EndNode/TaskNode等。

目前模型类还非常简单，因为前段时间主要关注Component视图组件部分，接下来很快会与jPDL规范完全同步，同时ProcessModel/NodeModel/ConnectionModel会进行重构，目标是与jBPM4模型完全一致。

 最新的模型位于org.jbpmside.model.common下，对jpdl4的支持位于org.jbpmside.model.jpdl4下，未来需要将Component与Model的关联迁移至common包下。

四、    GEF框架
GEF框架嫁接Model与Component。

1、    IGraphicalEditor与IEditPart
IGraphicalEditor与IEditPart是GEF框架里最重要的两个接口：
•    IGraphicalEditor代表整个图形编辑器，IGraphicalEditor里最重要的方法：



返回当前的图形视图。在当前的设计里，设计器支持多个TabPane，每个流程定义会拥有一个单独的图形视图（即一个TabPane），这里的图形视图即指当前处于激活（编辑）状态的画图板；很显然IGraphicalEditor是一个全局类。

•    IEditPart代表单个的图形编辑元素，很显然，这些元素是和Component组件一致的，IEditPart里最为重要的方法：

Component组件继承于IEditPart，这样就瞬间将Component组件与Model关联起来。IEditPart重要的实现类包括GraphicViewer与GraphicEditPart。
GraphicViewer被SurfaceComponent继承；
GraphicEditPart被NodeComponent和ConnectionComponent继承。
 
2、    Tool
Flex应用程序是基于事件驱动的，用户对界面的操作即反映到各种鼠标和键盘事件上。在原先的设计里，由Component组件自己来处理各种原生事件，当需要其他组件协作时，通过TheModel发出应用定制事件。在GEF的设计里，Component组件的原生事件处理被委派到Tool类进行处理。Component组件只管理自身的图形渲染和变化。
例如SurfaceComponent处理鼠标点击事件代码：


     
注意this.tool方法，这个方法同样是由GraphicViewer和GraphicEditPart分别  引入的。注意有些时候组件的Tool是需要切换的，例如鼠标点击面板，通常会导致被选中的节点或连接线选中状态消失，但是当工具条选中一个节点时，这个鼠标事件会导致向面板增加相应的节点。这时需要ToolManager来进行Tool却换的管理，针对SurfaceComponent/NodeComponent/ConnectionComponent分别有SurfaceToolsManager/NodeToolsManager/ConnectionToolsManager来管理不同的Tool切换策略。需要注意的是ToolManager和Tool都是无状态的，全局唯一，所有视图组件共用。

3、    Command
视图组件的变化会导致Model组件的变化。Tool处理视图原生事件、调用CommandService执行各个Command具体操作视图组件和Model对象实现视图组件和Model组件的变化。

CommandService与SurfaceComponent进行一对一绑定。CommandService持有CommandStack，实现单个Tab编辑界面内Command的redo和undo。

具体操作视图组件和Model对象必须通过Command。

五、    TheModel全局类的用途
      TheModel全局唯一，职责如下：
•    负责应用所有定制事件的订阅/分发；
•    负责持有工具条和系统菜单属性；
•    负责持有剪贴板，实现各个画板之间的节点拷贝/剪切。

六、    ProcessDesigner与ProcessEditor
ProcessDesigner负责整个应用的布局，目前由三部分组成，系统菜单、工具条和TabNavigator（TabBar管理器），TabBar管理器负责添加和删除Tab，由Tab加载画板，这样实现对多流程定义同时编辑的支持（即多Tab）。

ProcessEditor是应用的入口，它持有ProcessDesigner，实现了IGraphicalEditor接口。目前其对graphicViewer（）方法的实现是返回当前激活状态Tab的画板。

同时，ProcessEditor负责统一监听工具条/键盘事件，并将这些事件处理委派给当前处于激活状态的Tab画板处理。

七、    Xml框架
位于org.jbpmside.xml下，使用E4X，使用binding对各种类型的节点进行解析，不集中在一个文件完成解析和转换，一个节点类型对应一个binding。使用代码如下：


测试代码位于test目录下，是目前唯一可以进行单元测试的部分。

八、    还需要完成的工作
1、    xml框架还需要大量的解析工作完成（以支持jpdl4）
2、    第一个版本为本地应用，需要增加对本地文件操作的支持
3、    模型迁移至org.jbpmside.model.common
4、    工具条使用flexlib重写，新的16位图标,节点属性弹出框
5、    Command目前只实现了对undo的支持，需要实现对redo的支持