流程模型分析（2）
——起点模型和激活模型
一、流程的起点模型
任何事物都有由头有尾，一个流程也不例外，那么现在我们就从流程的“头”——流程起点说起。
首先，需要说明的是，起点也是一种任务节点（Task Node）。
1.1 单起点（Single Start Node）
单起点估计大家都比较容易理解，现实中工作流应用的也是最为普遍。如下图（1-1）所示，其就是单起点的模型。在接下来的所有图像中，一个绿色方框代表一个起点。
图（1-1）
1.2 多起点
多起点的工作流，在现实应用多不是太多。其主要表达的是，在同一流程中，存在多个起点。说到这里，有必要重新申明一下：起点也是一种任务节点，也就说起点不是独立于工作流任务的，在流程启动的时候，其也需要完成某种特定的任务，以激活整个工作流的运转。
多起点的工作流模型，基本上有如下三种方式。
多起点方式一
请参考图（1-2），起点A和起点B，它们都可以激活流程的运行，而且激活后，流程都会共同指向Task A。所以，对于Task B来说，其不关心流程是如何激活的，其只关系从Task A是否正确的传递来正确的流程数据。
图（1-2）
多起点方式二
在方式二（如下图（1-3））中，起点A激活工作流后，导致流程沿着Task A——Task B——Task C方向流转。而从起点B激活工作流后，Task A则被跳过。
这种方式，在现实中是极为少见的。如果将Start B——Task B这条流程段 与 Start A——Task B 这条流程段，分开来看。则可以近似看作的两个“子流程”的选择性汇总（两选一，或多选一）的情况。
图（1-3）
多起点方式三
方式三（如下图（1-4）），虽然也存在多个起点，但是基本是按照一个统一流程方向运行的。这是与方式二最大的区别所在。在此，须要再此申明：一个起点（Start Node）同时也是一个任务节点（Task Node）。参看图中的Task B/Start B节点。
此种方式，在现实中，还是有一定应用性的。特别是在多个流程之间信息交互的时候，流程A发送消息数据，激活流程B的运行。但是未必是从流程B的默认激活点激活，可能是从流程B的中途某个任务激活。比如图中的Task B/Start B任务节点（同时也时流程起点）
图（1-4）
二、流程的激活模型
上面我们看了工作流的起点模型。也知道任何流程，都必须有起点，或者相对的起点。一个流程被激活后，会从起点开始沿着预定的流程路线，有序或无序的往下进行（注意，我这里提到了“无序”二字，我将在后续讲解“无序”状态）。
所以，起点就是这个流程被激活的源头。下面让我们来看看，一个流程被激活的方式，或者说一个起点，被激活的方式：
从起点的激活方式，有如下两种方式：
2.1 人工激活
大多数的流程激活，都是因为人为的信息数据输入或产生。比如一个订单处理流程，客户提交了订单信息（订单信息数据产生），则激活了订单处理流程的开始。
2.2 定时或限时激活
在一个特定的时间，因为特定的情况，符合特定的条件，激活某个特定的流程（或任务）。
这种激活方式，在现实中很少单独出现，大多数情况，都因为在某一个流程中，因为在限定的时间内，因某项任务未达到预期的状态，而激活另外的任务或新的处理流程。也就说，这种方式，是受外来因素影响的，而且大多与一些流程任务（或流程模式）一起出现。
举个定时激活的实例：比如，订单处理流程，限定5天内发货，那么定义在第三天的时候，如果没有接到发货通知，则激活一个催办信息（催办任务）。这样流程系统，会在第三天的时候自动发出催办信息。
2.3 外界消息激活
这种方式，大多是在多流程信息交互（或大小流程嵌套）应用中。现在比较流行的业务流程整合/管理（BPM），基本上都涉及到这方面内容。
如下图所示，流程A，在结束的时候（在以下的所有图中，将采用红色框图，表示结束节点），会向流程B发送Message，以激活流程B的运行。至于这个消息是Soap消息，还是通过消息中间件转发的Message，这就是不同的应用方式了。
一般现实应用中，都需要考虑JMS或WebService的应用接口。从个人目前所实施过的工作流应用来说，大多还是采用Message Query方式居多。虽然软件的发展，逐渐SOA（面向服务）化，但是WebService的安全性或数据正确性，还有待进一步的发展，从这一方面说，比起消息中间件的高度安全性和消息正确性，WebService目前还是稍逊一筹。其实，安全性和信息正确性，是很多应用客户非常关心的焦点。
但是，SOA化的发展是未来的趋势。所以现在大多的应用都会提供JMS和WebService接口，或其他类似接口。
图（2-1）