工作流模式.docx
《工作流模式.docx》由会员分享，可在线阅读，更多相关《工作流模式.docx（26页珍藏版）》请在冰点文库上搜索。
工作流模式
工作流模式
一、模式概览
1、基本控制模式
∙顺序（Sequence）--顺序执行任务;；
∙并行分叉（ParallelSplit）--并行执行任务；
∙同步（Synchronization）--同步两个并行执行的线程；
∙排它选择（ExclusiveChoice）--从多个路径种选择一个执行；
∙简单合并（SimpleMerge）--合并两个可选执行路径。
2、高级分支和同步模式
∙多路选择（MultipleChoice）--从多个可选路径中选择几路执行；
∙多路合并（MultipleMerge）--无同步合并多个执行路径；
∙路径鉴别（Discriminator）--无同步合并多个执行路径，然并发任务仅执行一次；
∙M并N（N-out-of-MJoin）--合并多个执行路径，实现部分同步，并发任务仅执行一次。
∙同步连接（SynchronisingJoin）--合并多个执行路径，若多路执行则同步；若一路执行则简单合并（Simplemerge）。
3、结构化模式
∙任意循环（ArbitraryCycles）--执行工作流图时无任何环路限制；
∙绝对终止（ImplicitTermination）--若无事可做时则终止。
4、多实例调用模式
∙同一任务多实例在流程设计时已知实例数目；
∙同一任务的实例数目在运砖时某刻才能确定；
∙同一任务的实例数目无法确知；
∙同一任务多实例并要求同步。
5、基于状态的模式
∙延期选择（DeferredChoice）--执行两个可选进程之一，选择执行进程是隐含的；
∙交叉并行路由（InterleavedParallelRouting）--随机执行一个任务但不并行；
∙里程碑（Milestone）--直到达到某个里程碑方激活一个任务。
6、取消模式
∙取消任务（CancelActivity）--取消（或禁止）一个激活任务；
∙取消流程（CancelCase）--取消（或禁止）一个流程。
二、基本控制模式
1、顺序（Sequence）
顺序模式是最基本的工作流模式。
当两个或更多任务间存在依赖关系时需用顺序模式――在前一任务完成之前，本任务不能执行（调度）。
描述
在同一流程中，一个任务在另一任务完成后才能被激活。
同义词
顺序路由,串行路由。
示例
∙ 任务“发送账单”在任务“发送货物”之后才能执行。
∙在检索到客户端文件后才能计算保险索赔。
∙任务“累计航行里程”在任务“预订航班”后才能执行。
建议
顺序模式用于对工作流程中连贯的步骤建模，所有的工作流管理系统都支持该模式。
2、并行分叉（ParallelSplit）
当两个或更多任务需并行执行时需要并行分叉。
除不要求任何程度并行支持的系统外大多数工作流引擎都较易支持并行分叉。
描述
在流程中，需将单进程的某控制点分成可并行执行的多进程控制，于是允许任务同时执行或以任何顺序执行。
同义词
与分支，并行路由,分叉。
示例
⏹ 任务“付款”的执行，使得任务“装船”和“通知客户”同时执行能够。
⏹ 注册“保险索赔”后，两个并行子流程被触发：
一个是“校核顾客符合的条款”，另一是评估实际损害。
建议
所有的工作流引擎都可能支持并行任务。
可区分两种基本的方法：
显性与分叉和隐性与分叉。
支持显性与分叉结构的工作流引擎（诸如：
VisualWorkflo）可定义一激活即使能的有多个流出转移的路由选择节点。
支持隐性与分叉的工作流引擎（如MQSeries/Workflow）不提供特殊的路由选择结构――每个任务可有多于一个的流出转移，且每个转移都有相关条件。
为达到并行执行的目的，流程设计者须保证流出转移的多个相关条件为真（典型的方法是将条件置为空）。
3、同步（Synchronization）
当两个并行任务都完成后下一任务才能开始执行时需要同步。
描述
流程中，多个并行子流程/任务在某点汇聚成一个单进程，从而同步多个进程。
同义词
与结合，结合，同步。
示例
∙ 任务“存档”在“送票”和“收费”两个任务完成后才能使能。
∙ “保险索赔”在“核定条款”和“估算实际损伤”后才能计算。
问题
本模式极易为所有支持并行运行的工作流引擎所支持。
值得注意的是，对于某些实现，“与连接”的错误应用可能易于造成死锁。
建议
1. 所有可用的工作流引擎支持本模式。
典型的是具有可用的同步结构。
在某些罕见的情形下，通过对一个多入口的任务定义特殊的开始条件实现同步。
2. 当具有显性的同步结构时，典型的特征是同步器应具有多于一个入口，却只有一个出口。
例如，若任务C之前有一以任务A和任务B为输入的同步器，如果已有任务A的实例，当它执行完毕时，同步器将不作处理，而是等待任务B的实例的终止。
另一方法是，在等待任务B时，简单地明了任务A的“额外”实例的数目，然后用相应的任务B的实例匹配它们。
4、排它选择
描述
在流程的某一点，依据一个结果或流程控制数据,从多个分支路径中选定一个路径。
同义词
异或分叉,条件路径,开关,决议。
示例
任务“计算赔偿金”后继是两个任务“支付赔偿金”和“联系顾客”中的任一个。
建议
1. 类似于“并行分叉”，有两种基本策略――某些工作流引擎提供显性的结构以实现“排他选择”模式（譬如Staffware,VisualWorkFlo）,但是在其它工作流引擎（MQSeries/Workflow,Verve）中，流程设计者不得不选择转移条件仿效“排他选择”。
5、简单合并
欲将选择执行的路径合并成一个路径需用“合并”模式。
描述
在流程中某点，需将两个或更多可选分支聚合而不同步；换言之，“合并”在任一入口连接触发时被触发。
同义词
异或连接,，异步连接，合并。
示例
任务“存档索赔”在任务“支付赔偿金”和“联系顾客”任一之后使能。
三、高级分支和同步模式
1、多路选择（MultipleChoice）
排它模式采取的是只有一个可选项被选定并执行，亦即它对应于排它或。
有时，要用到从给定的一组选项中选定多项（而非一项）的结构，于是，引入（非排它）多重选择。
描述
在工作流过程的某点，依据判定或工作流控制数据，选择一个或多个分支。
同义词
条件路径,选择,或分叉。
示例
执行任务evaluate_damage之后任务contact_fire_department或contact_insurance_company被执行，至少其中之一被执行，但是，也可能两者都被执行。
问题
很多工作流管理斜体中，转移上可以定义条件。
这些系统中可直接实现OR-分叉，但是有几种工作流管理系统不能在转移上设置条件，仅提供纯粹的AND-split和XOR-split建模元素（例如Staffware）.。
建议
1. 正如所述，对于可在转移上设置条件的工作流管理系统（诸如Verve,MQSeries/Workflow,ForteConductor）实现多重选择是直截了当的,流程设计者只需简单地设定每一转移的条件即可。
值得注意的是多重选择是并行分叉和排它选择的泛化。
2. 多重选择的实现需要将并行分叉和排它选择二者结合起来。
每一可能的分支由一前置的异或分叉基于控制数据决定，或者激活该分支，或者跳过它。
所有异或分叉由一与分叉激活，该与分叉也可用于设置异或分支所用的控制数据。
3. 另一与上述方案类似的方案是颠倒与分叉和异或分叉的结构顺序。
每组可激活的并行分支，加入一与分叉。
所有与分叉由一前置的异或分叉激活适当的与分叉。
注意并非所有的分支组合可行的。
所以本方案将导致简单的工作流定义。
2、多路合并（MultipleMerge）
本模式旨在阐述简单合并模式中提及的问题,即当一个合并中有多于一条流入转移被激活时的情形。
描述
多路合并是指在流程中某点，两条或更多分支无同步再收敛。
若多于一个分支被激活,可能同时被激活,任务后的合并对于每条流入的激活分支都响应一次（亦即，在上图中，D将被实例化两次）。
示例
有时两个或更多并行的分支共享一个终点。
此类情况的翻版是（可能复杂的）流程中每一分支可用一个多路合并。
一个简单的例子是两个并行运行的任务audit_application及process_application，二者都后接任务close_case.。
问题
大多数工作流引擎（诸如Staffware,HPChangengine,I-Flow）若一个任务的第一个实例仍在运行时，将不产生第二个实例。
VerveWorflow和ForteConductor例外。
建议
如果多路合并不是循环（loop）的一部分,作为一个任务不能创建多于一个实例的语言的通用设计模式是在工作流模型中复制该任务。
如果多路合并是循环（loop）的一部分,典型的情况是多路合并其后所接的任务的数目在设计（建模）时未知。
关于这个问题的典型方案，见有关多实例模式。
3、路径鉴别器（Discriminator）
本模式可以看作多路合并模式的逆。
其语义实现是合并后仅一个任务应被实例化。
描述
路径鉴别器是指在流程的某点，激活后续任务之前等待许多流入分支的完成。
从它开始之时起，等待所有剩余分支的完成并“忽略”它们。
一旦所有的流入分支都被触发，它使自己复位，以便可被再次触发
示例
∙ 一篇论文需被送给外部审阅者。
如果两个评价皆为正，则论文被接受；如果第一个评价为负，应提示作者，不必等待第二个评价。
∙ 为缩短查询响应时间,一个复杂的查询通过internet被送往两个数据库。
第一个给出结果后流程将继续流转，第二个结果将被忽略。
问题
一些工作流引擎（如Staffware,HPChangeEngine,I-Flow），若任务的第一个实例仍在运行，则生成该任务的第二个实例。
然而，这不能提供一个路由鉴别解决方案，因为只要该任务的第一个实例完成，第二个实例将被创建。
建议
1. Verve中有一个特殊的结构实现路由鉴别语义。
2. 支持定制触发器的产品可实现路由鉴别功能（详见M中选N）
3. 所有其它的工作流引擎很难或无法实现路由鉴别功能。
通用的设计模式是采用取消任务模式。
只要路由鉴别后接任务的第一个实例被创建,仍未完成的流入分支的任务可被取消，如此第二个实例将不会被创建。
模式见下图。
本方案的问题是若任务B和C同时完成,任务D可能仍将执行两次。
此外,路由鉴别的原有语义是允许B和C都完成。
本方案任务B或C将被取消。
4、M中选N合并（N-out-of-MJoin）
下述模式可视作基本路由鉴别的泛化，意欲从M个流入转移中同步N个线程。
描述
M中选N合并是指流程的某点M条并行路径聚合到一点，只要其中N条路径完成则激活后续任务，所有其它剩余路径的完成应被忽略。
类似于路由鉴别,只要所有流入分支被触发,则该合并使自己复位，以便可被再次触发。
同意词
部分合并,鉴别器,定制合并。
示例
一篇论文需送往三个外部的审阅者。
收到两个评审后继续处理论文，第三个评审将被忽略。
问题
大多数工作流产品不提供结构以直接实现M中选N合并。
建议
1. 某些工作流引擎（如ForteConductor）提供对定制触发器的支持。
对于具有多于一个流入转移的任务可定义定制触发器，它定义条件，典型地使用某些内部脚本语言,当条件计算为真时，激活该任务。
这样的脚本很容易用于定义与M中选N等价的语义。
该方法的缺点是采用定制触发器语义的合并，不仔细检验触发器脚本是无法定义的，亦将导致模型的不当和难于理解。
2. 通过Bycomb融合路由鉴别模式和同步模式（Discriminator与Synchronisation），可达到同样目的，尽管工作流定义（或模型）会变得大而复杂。
下图所示为一3中选2合并的例子。
5、同步合并（SynchronisingJoin）
现代的工作流产品很容易处理多路选择模式。
不幸的是，对应于合并（Or－Join）结构的实现却极度困难。
OR-join应具有同步并发流及合并可选流的功能。
困难在于决定何时同步，何时合并。
同步可选流导致可能的死锁，合并并发流可能导致不期望的任务多重执行。
描述
流程中某点多条路径聚合成一个线程，若多于一条路径触发，则活动线程需同步；若仅有一条路径触发，则可选分支应再收敛，无需同步。
示例
拓展多重选择模式中的例子，任务contact_fire_department及contact_insurance_company任一或二者都完成后（取决于它们是否都不执行），任务submitreport需完成（仅一次）。
问题
本模式的主要困难在于决定何时同步，何时合并。
同步可选流导致可能的死锁，合并并发流可能导致不期望的紧接标准OR－join结构的任务的多重执行。
建议
1. 已知有两种工作流引擎MQSeries/Workflow和InConcert中直接实现了这个模式。
正如前面提及的，若一同步合并后接一OR-split，该OR-split可触发多于一条流出转移,不必等到运行时方知同步是否应该发生。
2. 在其它工作流引擎中未直接实现本模式。
通常的作发是避免明显地使用可能触发多条流出转移的OR-split，而代之以一个AND-splits和XOR-splits的联合。
该方法可轻易地使用AND-splits和XOR-splits结构同步相应分支。
四、结构化模式
1、任意循环（ArbitraryCycles）
在工作流分析/设计期间，人们不希望受各种各样工作流定义工具的语法约束，诸如循环仅有一个入口一个出口。
事实上,为正确抽象,工作流引擎应允许无约束模型的执行，也许更利于最终用户跟踪过程的执行。
描述
意指在流程中，一个或多个任务可被重复执行。
同意词
循环（loop）,叠代（iterate）,周期（cycle）。
示例
∙大多数原始的工作流模型在分析阶段包含任意循环（除非不含循环）.。
问题
某些工作流引擎不允许任意循环–仅支持结构化循环,或者借助分解结构（MQSeries/Workflow,InConcert），或者依靠特定的循环结构（VisualWorkFlo,SAPR/3）。
建议
任意循环可典型地转换成结构化循环，除非含有更高级模式之一，诸如多实例模式。
此类变换不是通过辅助变量，就是节点复制。
下图是一任意循环转换成结构化循环的例子。
2、绝对终止（ImplicitTermination）
另一类工作流引擎对模型加以限制的例子是模型中只能包含一个结束节点,若有多个结束节点,当第一个结束节点到达时，工作流模型终止。
其次，大多数业务模型不遵循本模式－－认为业务过程当无事可作时终止更自然。
描述
一给定的子流程当无事可作时应终止；换言之，流程中无活动任务，且无其它任务可被激活（同时，流程并非死锁）。
示例
这样的语法在分析阶段为每种工作流模型采用。
问题
大多数工作流引擎当流程到达一显性的Final节点时终止流程。
任何当前正在运行的任务在流程终止时将被取消，这可能干扰最终用户。
某些工作流引擎（Staffware,MQSeries/Workflow,InConcert）在子流程无任务时结束子流程。
建议
这类问题的典型解决方案是将模型转换成仅有一个终止节点的等价模型，其复杂性更多地取决于实际模型。
有时是容易的、直截了当的,具有代表性的作法是利用不同接合结构及任务复制的组合。
然而，有时较难甚至不可能实现。
一个包含多实例及绝对（或隐性）终止的模型很难转换成显性终止的模型。
五、多实例模式
1、多实例（设计时已知实例数目）
流程中的某个任务可能乐于创建多个实例，其数目在设计模型时已知。
描述
某种情形下，一个任务被激活多次，其指定任务在给定情况下实例的个数在设计时已知。
示例
危险材料的申请单要求三次不同的审批。
建议
若实例的个数在设计时已知，一个简单的处理方法是在模型中复制该任务，并结合使用并行执行模式。
2、多实例（运行时才知实例数目）
一个任务的实例个数是动态的，亦即在设计时未知，而在运行期间所有实例需被执行前的某点可获知其数目。
可以将本模式看作一初始化该任务的For循环。
描述
在某种情况下，任务可被激活多次，给定任务的实例数在指定情形下是一变量，取决于情况特征或资源的可用性,但在运行期的某些阶段才已知,即该任务的实例不得不被创建之前。
示例
● 在将科学论文提交杂志审阅的流程中，任务review_paper被实例化几次取决于论文的内容、受托人的可用性,以及作者的信任度。
● 对于多本书的订购过程,任务check_availability每本书都执行一次。
● 当预定旅行时,任务book_flight执行多次，若该旅程包含多个航程。
● 当申请审批包含多项，且每项需不同的人审批。
问题
只有少数工作流管理系统提供指定情况下一个任务的多次激活。
大多数系统不得不采取同一任务确定数目的并行实例，或者采用叠代（或重复）结构――其中任务串形处理。
建议
1. 可用任何适用的方案。
2. 若存在可能的最大实例数,则AND-split和XOR-split可用于获取期望的路径。
一XOR-split用于选择实例的数目，并触发几个AND-splits之一。
每一可能的实例数对应一个带有基数的AND-split。
本方法的缺点是使得模型变得庞大且复杂，另为可能的最大实例数所限。
3. 某些工作流引擎提供一特殊结构用于实例化一任务的给定数量的实例。
例如MQSeries/Workflow中的Bundle。
4. 正如很多情况下，期望的路由行为极易支持――使其更串形化。
简单地利用叠代（重复）串形地激活任务的实例。
假设任务A后接任务B的n个实例且后接任务C，首先执行A，然后执行B的第一个实例，每一B的实例后接一XOR-split来确定需要另一B的实例或者C为下一需执行的任务步。
本方法相当简单。
可是，B的n个实例是非并行执行的但以确定的次序，在很多情形下是无法接受的。
请思考论文审阅的例子，显然，第二个审阅者不得不等待第一个审阅者完成审阅后才能审阅是无法让人接受的，等等。
3、多实例（无预知）
实例的数目是动态的，亦即实例数设计时不知，在运行期间，所有这些实例需要被激活前的任何阶段都无法知道。
可将本模式看作是任务实例化的WHILE循环。
描述
某种情况下任务可激活多次，然实例数设计时不知，在运行期间，所有这些实例不得不被创建之前的任何阶段都无法预知。
示例
100台计算机的订单，然供货商数目未知。
每一供货商交付的计算机数量未知，因之，交付的综述事先未知。
每次交货后，通过比较已截止目前已交付的总数和需求数量来确定是否还有下次交易。
问题
大多数工作流引擎不允许同一任务多于一个实例同时激活。
建议
1. 本模式的最简单实现是利用循环和并行分叉结构，只要工作流引擎直接支持多实例。
在Forte和Verve中是可行的。
2. 某些工作流支持额外的结构使得设计器可创建子流程（subprocess或subflow），从主流程中分离且并行执行。
例如，VisualWorkFlo支持Release结构、I-Flow支持ChainedProcessNode.。
3. 若工作流支持特殊的结构――孵化子流程,那么可通过调用子流程――作为流程中任务的一部分。
4. 同样运行时已知实例数的多实例模式，期望的路径行为通过使其有序执行极易支持。
4、多实例（要求同步的多实例）
以上多实例模式未考虑多实例的同步问题。
例如，从主流程中孵化出一可变数量的子流程,如VisualWorkFlo和I-Flow中支持的那样,仅启动多实例未考虑同步问题；但是有时候要求所有实例完成后方可继续流程运转,可能不知道创建了多少实例。
描述
实例的数在设计时未知，任务的所有实例完成后另一任务才能启动（或开始）。
示例
∙ 预订旅行时,任务book_flight被执行多次――若形成设计多个航班。
只有所有预订完成,发票才能送往客户。
∙ 100台计算机的订单导致确定数量的交货，只有所有交货处理后，订单才能关闭。
问题
大多数工作流引擎不允许多实例。
而允许多实例的工作流语言（如Forte,Verve）未通过任何结构来处理多实例的同步。
支持Release结构的工作流语言（VisualWorkFlo,I-Flow）不提供任何结构允许同步孵化的子流程。
建议
1. 若实例数（或最大实例数）设计时已知,那么通过复制任务及使用基本的同步模式可实现多实例的同步。
2. 若工作流语言支持多实例与除非所有任务完成不终止流程的分解,那么多实例可实现同步――将流程中包含循环生成多实例的子流程放入分解块中，只有任务的所有实例完成后，才能继续执行块。
3. MQSeries/Workflow的Bundle结构可用于同步运行时实例数已知的所有实例。
4. 大多数工作流语言中不易实现本方法。
典型的的解决之道是采用外部触发器，只有该任务的每一实例完成,然后发送事件，主流程中应有另一任务等待发送的事件，此任务只有在收到每一实例的所有事件后才能完成。
六、基于状态的模式
1、延期选择（DeferredChoice）
在选择时刻，诸如由XOR-splits/OR-splits所支持的结构,工作流管理系统是自然的事情，亦即基于数据或通过判别任务获取。
这意味着选择是优先的,也就是说在一选定分支被实际执行之前先作选择。
有时这样的作法是不当的。
存在两个线程只能执行一个的情形（设一个线程激活任务A,另一线程激活任务B，而两个任务都在任务列表中），只要一个线程启动,另一线程应消失（亦即若任务A启动，则任务B应从工作列表中消失）。
描述
流程某点几个分支中之一被选中，相对于XOR-split的是,选择不是显性的（例如基于数据或判定）但有几个可选路径；然而，相对于AND-split,仅有一个可选路径被执行。
这意味着环境激活可选分支之一，其余分支忽略。
请注意，重要的是该选择延期到可选分支之一确实启动之时,亦即选择的时刻仅可能迟。
同义词
外部选择,隐性选择（implicitchoice.）
示例
∙ 接收产品时有两条途径将产品运往部门，选择是基于相应资源的可用性，因之，选择延期到一个资源可用。
∙ 考虑任务send_questionnaire,后接任务time_out和process_questionnaire，任务time_out要求一个时间触发器,任务process_questionnaire只在回复从接收方返回时执行（所以其执行需要一外部触发器）。
明显地,在任务process_questionnaire和time_o
升级会员 