BPMN的流程模型

我们使用业务流程建模来交流信息，正如在上一节里所述，根据不同模型的用户（客户、业务人员、分析人员、开发人员），建模有着不同的风格。BPMN被设计用来涵盖各种风格的流程模型（以满足不同角色人员交流的需要）和创建端到端的业务流程，它支持三种基本类型的流程模型：

流程编制（Process Orchestration），包含：

• 私有的不可执行的（内部的）业务流程；
• 私有的可执行（内部的）业务流程；
• 公开流程。

编排（Choreography）

协作（Collaborations），包含流程与/或编排。

• 具有会话视图（Conversation）。

私有的（内部的）业务流程

私有的业务流程是指某一组织的内部工作流程，我们通常称之为称为工作流，在WEB服务领域，我们也称之为服务的编制（Orchestration）。存在两种类型的私有业务流程：可执行的和不可执行的。可执行的私有业务流程以被计算机执行为建模目的，由相应的BPMS系统来自动化流程的执行，它包含了足够的执行细节，这些细节包括执行规则、条件表达式等计算机解释执行所需要的技术信息，该模型最直接的用户是开发人员。不可执行的私有业务流程则以文档化为建模的目的，它缺少执行细节，但是包括足够的交流信息，该模型的用户包括了业务人员与分析人员。

作为一个例子，我们一起来看看我在公安局户籍科为儿子办理户口的流程，如下图所示：

图1公安局户籍科上户口的流程

当我来到户籍科，递上足够的资料，然后就开始等待。我能看到共有四个工作人员，第一个工作人员负责接收资料，查看资料是否完备，接下来，她将所有的资料传递到下一个工作人员，第二个工作人员对资料进行审核，在计算机上查看我们的户口信息是否正确，接下来，如果资料无误，他将资料传递到第三个工作人员，第三个工作人员负责在计算机上为我的儿子录入新的户口，最后打印出一张户口页，第四个工作人员是职位最大的警员，她负责盖章，然后将儿子的户口页传递给在窗口外等待的我。

根据上面对私有业务流程的定义，我们很容易的判断出这个流程是个不可执行的私有业务流程，因为该流程是户籍科的内部工作流程，作为该流程服务对象的我，我根本不用关心户籍科内部是如何对我的申请进行处理的，所以它是私有业务流程。该流程是由规章或制度所规定的，由工作人员来驱动，并非通过计算机协调，所以这是个不可执行的私有业务流程。

因为私有业务流程是内部流程，所以它只能存在于一个池（pool，池代表一个参与者）里，如下图所示，我们可以将私有业务流程建模在一个池里，但通常这样做没有太大的意义，更经常的情况是，我们选择将池忽略。

图2公安局户籍科私有业务流程的另一种建模形式

公开流程

公开流程表现一个私有业务流程与其他流程或参与者之间的交互。

还是以户口办理作为例子，作为户口申请人，我来到公安局户籍科，我心揣揣，我不知道我该做些什么，于是我看到大厅里如下图所示的流程，于是我立刻就明白了，我只需要将资料交给办事人员，然后等待取新的户口页即可。

注意下图所示的公开流程与图1所示的私有流程有哪些不同。第一是图中出现了多个参与者，参与者间通过消息流连接（图中虚线箭头连线）；第二是户籍科的办理流程被缩减到只剩两个与外部参与者交互的活动，两个原有的内部活动被忽略了。这两点不同即是公开流程的特点：表现与外部参与者、流程间的交互，忽略内部活动。联想到我们实际的编程，总结成一句话，就是隐藏内部实现细节，仅仅展现对外接口，表现流程的外部行为。

图3公安局户籍科办理户口的公开流程

协作

协作描绘两个或多个业务实体间的交互。一个协作通常包含两个或多个池，每个池代表一个参与者（业务实体）。参与者之间的消息交换通过连接两个池（或池中的对象）的消息流表现。协作可以表现为两个或多个公开流程之间的交互，在上一节里，我们提到，与对应的私有流程相比，公开流程隐藏了内部细节活动。池也可以是黑盒，即里面什么对象都没有。

那么，这里有一个问题，公开流程与协作有什么区别？区别在于表现的范围，公开流程只是表现一个私有流程与外部的交互，而协作则能表现多个流程/参与者之间的交互。

还是看户口办理的例子，在前面的例子中，我们看到了公安局户籍科办理户口的私有流程和公开流程，似乎办理户口是一件很简单的事情，但这仅仅只是办理户口中的一步而已。在此之前，我先要去医院办理小孩出生证明，接下来，我要去居委会登记小孩信息，再接下来，我要去计生办办理符合计划生育政策的证明，最后，我才来到户籍科。下图是整个户口办理的协作图，作为简化，这里将除申请人和户籍科之外的池都黑盒了：

图4户口办理协作图

编排

同样是表现多个参与者之间的交互，编排做的更为纯粹，它取消掉了池的概念，改由编排活动直接表现多个参与者之间的消息交互，为协作模型提供了一种基于流程图的视图。户口办理的编排图如下图所示，其中每个活动都能看到上下的方形区域有参与者信息，这表明这个活动的参与者，浅色部分为活动的发起者，深色部分为活动的响应者，我们会在接下来的BPMN元素小节里详细描述这一活动类型：

图5户口办理编排图

与协作图相比，编排图省略掉了更多的细节，例如与各个参与者具体的交互过程，它关心谁和谁产生了交互，至于如何交互，分几步交互，它并不关心。例如办理户口这个活动，实际上我是分别和两个警官进行了交互，一个是负责接受资料的年轻女警官，一个是负责盖章复核的领导警官，在协作图中，我可以通过公开流程展现出这一点，但是在编排图中，这并不是要表现的重点。

协作图表现出参与者之间的交互，并包含交互的细节信息（交互的接口、如何交互）；编排图则以流程图的形式表现出参与者之间的交互，它关心的是某个任务需要哪些参与者发生交互，交互的细节不是其表现的重点。

编制与编排的区别

在上文中，我们提到了服务的编制（Orchestration），这里，我们又提到了编排（Choreography），这两者是有很大区别的。

WS-BPEL将SOA中的服务按照一定的顺序灵活组装在一起的流程就是编制（Orchestration）。编制后的WS-BPEL流，通常代表了某个特定的业务中的服务的执行流。而编排（Choreography）则是描述参与者之间交互关系的流程。与编制不同的是，编排并不需要一个执行引擎，它只是描述关系。编制代表的是一个可执行流程，它必须通过执行引擎来执行。而编排实质上是代表一种描述，即参与者之间如何互相协调来完成一个目标。

John Reynolds在其博客中是这样描述编制和编排的区别[1]：

编制 == 可执行过程

Web服务编制与执行特定的业务流程相关。WS-BPEL是一种用来定义可以在一个编制引擎中执行的流程语言。

编排 == 多方合作

因此编制必须对应一个执行引擎，而编排由于涉及到多方合作，所以它是不能被直接部署的。

协作的会话视图

会话视图为协作图提供了另外一种非正式的表现形式，与编排图一样，它的目标同样在于表现参与者之间的关系，它将一系列相关的信息交互定义为一次会话。户口办理的会话图如下图所示，图中只存在池与会话（Communication）元素，会话元素由图中的六边形代表，它代表两个或多个参与者之间一系列相关的信息交互，我们可以看到，办理户口需要申请人与四个组织发生四次会话：

图6户口办理会话图

会话视图的作用之一是能够有效减少模型中消息流的数量，便于我们理解。

图7会话视图简化交互模型