工作流模型分析.docx

工作流模型分析.docx

《工作流模型分析.docx》由会员分享，可在线阅读，更多相关《工作流模型分析.docx（13页珍藏版）》请在冰豆网上搜索。

工作流模型分析

第0章前言

第1章流程的起点模型

1.1单起点（SingleStartNode）

1.2多起点

1.2.1多起点方式一

1.2.2多起点方式二

1.2.3多起点方式三

第2章流程的激活模型

2.1人工激活

2.2定时或限时激活

2.3外界消息激活

第3章流程的运转模型

3.1基本运转模型

3.1.1串行（Sequence）

3.1.2自循环

3.2发散运转模型

3.2.1并行（Parallel）

3.2.2独占式选择（ExclusiveChoice）

3.2.3鉴别式选择（DiscriminatorChoice）

3.2.4抄送模型

3.2.5发散模型

3.3聚合运转模型

3.3.1同步聚合（synchronizemerge）

3.3.2简单聚合（SimpleMerge）

3.3.3多重聚合（MultipleMerge）

3.3.4鉴别式聚合（DiscriminatorMerge）

第4章流程组合嵌套模型

4.1内嵌模型

4.1.1主流程等待方式

4.1.2主流程也运行方式

4.2外嵌模型

第5章流程整合模型

第0章前言

有关“什么是工作流”和工作流的概念，就不在这里介绍了。

大家有兴趣的可以到WFMC上看看。

这里先说说个人的看法：

一个工作流包括一组任务（Task）及它们的相互顺序关系，还包括流程及任务的启动和终止条件，以及对每个任务的描述。

其实这是摘自上一段话有关工作流的描述。

只是原文叫“活动”，我改为任务（Task），可能更好理解一些。

其实，现在已经跳出了单工作流的圈子，越来越倾向于多工作流之间的嵌套或整合，在本文后面的第4、5节会简要的介绍。

在进入各个模型说明前，需要说明一些有关本篇文章中，出现的一些图形含义。

既然是流程图，就免不了用图形表示，用图标代替一些流程节点的含义。

如下图所示：

有关各个图标的含义，在后续文章中会说明。

第1章流程的起点模型

任何事物都有头有尾，一个流程也不例外，那么现在我们就从流程的“头”——流程起点说起。

首先，需要说明的是，起点也是一种任务节点（TaskNode）。

1.1单起点（SingleStartNode）

单起点估计大家都比较容易理解，现实中工作流应用的也是最为普遍。

如下图（1-1）所示，其就是单起点的模型。

在接下来的所有图像中，一个绿色方框代表一个起点。

图（1-1）

1.2多起点

多起点的工作流，在现实应用多不是太多。

其主要表达的是，在同一流程中，存在多个起点。

说到这里，有必要重新申明一下：

起点也是一种任务节点，也就说起点不是独立于工作流任务的，在流程启动的时候，其也需要完成某种特定的任务，以激活整个工作流的运转。

多起点的工作流模型，基本上有如下三种方式。

1.2.1多起点方式一

请参考图（1-2），起点A和起点B，它们都可以激活流程的运行，而且激活后，流程都会共同指向TaskA。

所以，对于TaskB来说，其不关心流程是如何激活的，其只关系从TaskA是否正确的传递来正确的流程数据。

图（1-2）

1.2.2多起点方式二

在方式二（如下图（1-3））中，起点A激活工作流后，导致流程沿着TaskA——TaskB——TaskC方向流转。

而从起点B激活工作流后，TaskA则被跳过。

这种方式，在现实中是极为少见的。

如果将StartB——TaskB这条流程段与StartA——TaskB这条流程段，分开来看。

则可以近似看作的两个“子流程”的选择性汇总（两选一，或多选一）的情况。

图（1-3）

1.2.3多起点方式三

方式三（如下图（1-4）），虽然也存在多个起点，但是基本是按照一个统一流程方向运行的。

这是与方式二最大的区别所在。

在此，须要再此申明：

一个起点（StartNode）同时也是一个任务节点（TaskNode）。

参看图中的TaskB/StartB节点。

此种方式，在现实中，还是有一定应用性的。

特别是在多个流程之间信息交互的时候，流程A发送消息数据，激活流程B的运行。

但是未必是从流程B的默认激活点激活，可能是从流程B的中途某个任务激活。

比如图中的TaskB/StartB任务节点（同时也时流程起点）

图（1-4）

第2章流程的激活模型

上面我们看了工作流的起点模型。

也知道任何流程，都必须有起点，或者相对的起点。

一个流程被激活后，会从起点开始沿着预定的流程路线，有序或无序的往下进行（注意，我这里提到了“无序”二字，我将在后续讲解“无序”状态）。

所以，起点就是这个流程被激活的源头。

下面让我们来看看，一个流程被激活的方式，或者说一个起点，被激活的方式：

从起点的激活方式，有如下两种方式：

2.1人工激活

大多数的流程激活，都是因为人为的信息数据输入或产生。

比如一个订单处理流程，客户提交了订单信息（订单信息数据产生），则激活了订单处理流程的开始。

2.2定时或限时激活

在一个特定的时间，因为特定的情况，符合特定的条件，激活某个特定的流程（或任务）。

这种激活方式，在现实中很少单独出现，大多数情况，都因为在某一个流程中，因为在限定的时间内，因某项任务未达到预期的状态，而激活另外的任务或新的处理流程。

也就说，这种方式，是受外来因素影响的，而且大多与一些流程任务（或流程模式）一起出现。

举个定时激活的实例：

比如，订单处理流程，限定5天内发货，那么定义在第三天的时候，如果没有接到发货通知，则激活一个催办信息（催办任务）。

这样流程系统，会在第三天的时候自动发出催办信息。

2.3外界消息激活

这种方式，大多是在多流程信息交互（或大小流程嵌套）应用中。

现在比较流行的业务流程整合/管理（BPM），基本上都涉及到这方面内容。

如下图所示，流程A，在结束的时候（在以下的所有图中，将采用红色框图，表示结束节点），会向流程B发送Message，以激活流程B的运行。

至于这个消息是Soap消息，还是通过消息中间件转发的Message，这就是不同的应用方式了。

一般现实应用中，都需要考虑JMS或WebService的应用接口。

从个人目前所实施过的工作流应用来说，大多还是采用MessageQuery方式居多。

虽然软件的发展，逐渐SOA（面向服务）化，但是WebService的安全性或数据正确性，还有待进一步的发展，从这一方面说，比起消息中间件的高度安全性和消息正确性，WebService目前还是稍逊一筹。

其实，安全性和信息正确性，是很多应用客户非常关心的焦点。

但是，SOA化的发展是未来的趋势。

所以现在大多的应用都会提供JMS和WebService接口，或其他类似接口。

图（2-1）

第3章流程的运转模型

这里将是本文最为核心的地方了，什么是工作流，也将在其运转模型中体现。

任何事物都是循序渐进的，由简单到复杂。

我们先来看看最为基本的集中运转模型。

3.1基本运转模型

3.1.1串行（Sequence）

串行，是最为简单，也最为容易理解的模型。

按照预定的任务列表（TaskA,TaskB,TaskC），有序的执行，如下图（3-1）所示。

图（3-1）

3.1.2自循环

自循环的模型，主要用于表示：

同一个任务节点，重复的执行多次。

图（3-2-1）

图（3-2-2）

如图中所显示。

“模式2”比“模式1”多了一个鉴别节点（DiscriminatorNode）。

这两种模式，在现实中应用的都较为广泛，其中“模式1”更多的偏向人为的选择，也就是说，在任务执行后，由人为的决定是否继续重复的执行这次任务；而“模式2”则更多的倾向于一个既定的规则，按照原有的规则，决定是否重复执行。

3.2发散运转模型

3.2.1并行（Parallel）

并行，就涉及到流程的分支概念。

就是说在流程运行过程中，因为不同的条件或情况，或者处理的业务需要多部门（多任务）分开处理，而产生了流程分支。

如下图所示：

图（3-3）

流程在执行完任务A后，因为需要，产生了两个并发执行的分支（A——B和A——C）。

这两个分支之间是对等的，也是并行执行的。

有关上面的流程图，可能在以后的一些文章/文档中，大家会看到下面类似的图形：

图（3-4）

虽然比上图多了一个And选择器，但实际上，两图，表示的是同一个含义或模型。

所以大家在应用或读书的时候，可以长个心眼哦，自己学会实质性的分析。

3.2.2独占式选择（ExclusiveChoice）

当一个任务处理完后，发现其后面可允许走多个分支流程，但只允许选择其中某一个分支运行。

这个选择是人为决策的，预先没有设点选择的规则。

图（3-5）

3.2.3鉴别式选择（DiscriminatorChoice）

这同前面的“独占式选择”很相似，唯一不同点，就是多了一个鉴别器（Discriminator）。

当任务达到这个鉴别器的时候，鉴别器会根据当前流程所处的状态，对比预先设定的一些选择规则，自动判别接下来流程的流向，也就是自动根据条件，选择一个满足条件的分支运行。

图（3-6）

鉴别器模式（有的可能叫选择器等等名字，表达的意思基本相同），在现实应用中较为广泛。

比如在订单申请流程中，设定一个依据数额判别流向的鉴别器，如果数额大于等于5000就走分支流程A，如果数额小于5000就走分支流程B。

3.2.4抄送模型

抄送模型，本身不是一个标准的工作流运转模型，但是在现实应用中，比比皆是。

它表达的意思是（请参考下图），存在主流程（A——C），在一个任务（A）执行完毕后，会继续执行主流程上下一个预定任务（C），但是同时也会激活另一任务（B）（或另外的流程）的执行，但是任务B以及任务B的后续流程，不会对主流程运转造成影响。

请注意图中的A——B流程沿线，用的是灰色虚线表示，而且任务B也同样采用灰色表示。

图（3-7）

来个举个电子办公系统中，经常遇到得例子说明一下：

比如一个发文，在交司局会签的时候，可能会抄送一份给另外的司局备案，这个过程就或额外的激活一个不影响主会签流程的“抄送任务”，比如图中TaskB。

3.2.5发散模型

说到这里，大家可再回过头参看一下并行模型（3.2.1节）。

发散和并行最大的区别就是，各个分支（branch）的流程状态（或流程数据）。

并行模型中，分支状态（A-B）与分支状态（A-C）是大多数情况下是不相等的。

由任务A执行后的状态进行一定条件下的“拆分”，形成了两个分支（或多个分支）流程。

这多个分支流程，在最终需要重新聚合成一个主流程，以确保流程信息的完整性（当然，实际运行中，可能存在因为超时等特定原因而最终抛弃某个子流程）。

而在发散模型中，分支状态（A-B）与分支状态（A-C）是绝对相等的。

因发散而产生的多个分支流程，在最终未必聚合（可能因为种种原因，聚合的时候会抛弃一个和多个分支流程）。

这里面说到了“聚合”概念，在后续的介绍上，将加以详细叙述。

图（3-8）

3.3聚合运转模型

下面我们就将进入聚合模型的介绍。

因为有了“发散”，在一个流程的后续运转中，才会出现“聚合”这个问题。

所以在后续讨论聚合模型的时候，大多情况下都会结合上面的发散运转模型。

3.3.1同步聚合（synchronizemerge）

由必要说明一下，同步聚合，可不是“同时聚合”噢。

图（3-9）

3.3.2简单聚合（SimpleMerge）

虽然名为简单聚合，不过在现实应用中，其理解度和应用度，都基本上比上面的“同步聚合”要难。

多分支