业务流程建模

      业务流程建模（BPM, Business Process Modeling）是对业务流程进行表述的方式，它是过程分析与重组的重要基础。在跨组织业务流程重组的前提下，流程建模的主要目的就是提供一个有效的跨组织流程模型并辅助相关人员进行跨流程的分析与优化。目前有大量的流程建模技术能够支持业务流程的重组，但同时这也给相关人员带来困惑：面对如此众多的技术，他们很难选择一种合适的技术或工具。同时，目前对流程建模技术的研究大多集中于建模技术的提出与应用，缺乏对现有技术的整理与分类以及技术之间的横向对比，这也就加深了建模技术选择的复杂性。

      “以方框与箭头表现出来的大笔财富……”一个业务分析家站在白色书写板前，用箭头连起来的盒子勾画出一个业务流程图，并要求软件开发小组实现它（向莎士比亚道歉）。(编辑注：此处作者引用了一句双关语: "The boxes and arrows of outrageous fortune ...."，应是源于莎翁之句，译者译为“暴虐命运的雪箭霜盒……”但从本段含意来看，编辑认为，最好按字面翻译，可以体现出作者在英文环境下的双关韵味）业务流程建模（BMP, Business Process Modeling）——也被称作业务流程管理(Business Process Management)——此时就可以帮上忙了。BPM是一套设计、执行、管理及监控业务流程的技术和标准。一个业务流程是指为了实现某种业务目的行为（盒子）——每个盒子代表一个人的操作、一个内部系统、或一个合作公司的流程——的流程或一系列动作。

      这么多年来业务流程和BPM的范围已经被扩展。就在几年前，BMP——那时叫“工作流”(workflow)——用来管理和驱动在公司部门内大型人性化和纸制流程的组件。例如，处理一个申请（保险申请），将扫描的纸制申请表格作为输入，电子化地从一个索赔受理者的电子邮箱（或者worklist）传到另一个那里。这相当于模仿各办公室邮件在办公桌之间传递的传统动作。现在BM是一种企业集成技术，作为对面向服务系统架构（Service-Oriented Architecture (SOA)）、企业应用集成(Enterprise Application Integration（EAI）)、企业服务总线（Enterprise Service Bus（ESB））的补充。当代的流程成功地处理了复杂系统的交互，其本身作为一种服务依照良好定义的技术契约可以与以他公司的流程交互、交流。例如，零售商处理购买订单的流程运用Xml消息与基于服务的顾客和仓库流程交互。

      BPM 是一个不完整的规则，其中有许多不同的形式、表示法和资源。另一种常用的技术是定义表示概念性流程流的事件驱动流程链，正如 Barker 和 Longman 所定义的。这第二种技术使用了不同于 UML 的表示法。

      此外，还有许多专用方法（如 BPM 技术）可能被咨询公司和企业资源规划（Enterprise Resource Planning，ERP）软件包厂商视为具有竞争优势。ARIS Implementation Platform 就是这样的产品的一个例子。其他的方法包括：Line of Visibility Enterprise Modeling (LOVEM) 和 IBM 的组件业务建模（Component Business Modeling，CBM）战略。

      最近的趋势是定义表示可执行流模型（如用于 Web 服务的业务流程执行语言（Business Process Execution Language for Web Services，BPEL））的标准方法。BPEL 将流程的范围从分析扩展到实现。这样的可执行模型引发了一系列的新问题，其中包括：

·哪些方面应该用 BPEL 描述，哪些方面应该用 WSDL 描述？流程模型和传统的编程模型之间的区别在什么地方？
·如何将非功能性要求和服务质量特征这样的方面加入模型之中？
·同更传统的编码（例如在 J2EE 中）相比，在 BPEL 引擎的编程语言扩展中执行多少逻辑？
·如何评定可执行流程模型的质量，其应用的最佳实践是什么？
·什么工作角色进行 BPEL 流管理；是业务专家（分析人员），还是开发角色（软件架构师）？

      必须利用所有现有的 BPM 方法作为 SOAD 的起点；然而，必须使用流程模型中用于驱动候选服务和它们的操作的附加技术来对其加以补充。此外，SOAD 中的流程建模必须与设计层用况建模保持同步，并且必须给出与 BPEL 有关的问题的答案。

理想的BPM体系结构

      我即将出版的一本书《业务流程建模本质》（Essential Business Process Modeling）探究了BMP的概念、设计和标准。当今的BMP相当于一个沼泽，我的书与许多被误解、被误用和被过分吹嘘的厂商和标准争论。在对BMP前景的调查中，我的书强调标准高于厂商，因为标准是更好的概念源头，且使这个主题更清晰。已通过的BMP标准乍眼望去像一盘黑糊糊的字母形花片汤（见表1），但是将其中最好的恰当地组合后，他们会形成一个非常易于理解的体系结构，见图1。

表 1. BPM 标准

图1. BPM 体系

      在这个体系结构的核心部位是一个执行流程的运行时引擎，其流程的源码是由基于XML的BPEL语言写成，BPEL是当今最著名、广泛应用的BPM标准，及最优秀的BPM执行语言。这些流程是由业务和技术分析家使用支持可视化流程图语言BPMN——最好的BMP图形语言——的图形编辑器设计出来的。此编辑器包括一个导出器，可以从BPMN图生成BPEL代码(之后部署到引擎)。(在当前许多Java开发工具中，BPMN到BPEL的流程与UML到Java的流程相类似。)

      人和计算机的交互驱动引擎里流程的执行。人这个参与者使用一个图形化工作列表应用程序浏览并执行未执行完毕的手工工作（在流程运行的引擎里）。依附于公司网络的但在引擎地址空间外的内部IT系统，被储如web服务，j2EE，或COM的集成技术，通过XML作为选用的消息格式所访问；用编成语言如java、C#写出的内部交互可以是更轻便的内嵌代码片断。外部交互是典型的基于web服务的通信，由编排控制，例如那些用新兴的XML语言——WS-CDL 这个领先的编排语言所创作出的外部交互。虽然编排描述了多个参与者流程交互（在business-to-business电子商务里很典型）的整体、引人注意的视图，但是编排工具包可以用来生成一个基本的BPMN模型，其可以捕捉某个特定参与者流程所要求的通信，同时这个工具还可以验证一个给定的流程是否满足编排的要求。（WS-CDL文献建议由WS-CDL生成BPEL而不是BPMN。但是在现在的体系结构中，BPMN作为一种设计语言是一个必要的间接层。）

      BPM系统管理员里利用一个图形化的监视控制台来维护和跟踪引擎流程的状态。控制台使用一种管理语言与引擎衔接。实时引擎将流程状态持久化到数据库，控制台直接与数据库碰面，而不是用管理语言来沟通。运行时引擎将流程状态持久化到数据库，控制台直接与数据库碰面而不是使用管理语言来专门执行流程的请求。监控构造也支持业务活动监控（Business Activity Monitoring (BAM)）或者仪表板式的业务监控。

      在这个平台上的开发过程如下：

1.从一个WS-CDL choreography生成一个初始的BPMN模型。如果流程并不是从一个编排衍生而来则越过此步。
2.设计BPMN模型
3.从BPMN模型生成BPEL
4.开发必要的人和系统(内部和外部)的接口
5.部署BPEL代码和其必要的接口到引擎
6.使用管理和监控接口跟踪正在运行的流程。

      这个体系结构的全貌（由WFMC——众多BPM标准组织中最成熟的一家——的参考模型激发而成）类似许多集成厂商（如，IBM、BEA,、Oracle、Tibco,、SeeBeyond和Vitria ）所提供的平台。使这个体系结构特别的地方是其标准的选择。BPEL、BPMN和 WS-CDL都被包含进来，因为他们分别是执行、设计和编排的最好解决方案，BPM最重要的三个部分。
（如图2所示未来可能包括新兴标准BPQL——用于监控，BPSM和BPDM——用于元模型建模，BPRI——用于运行时接口，BPXL——用于BPEL扩展）。事实上，很多厂商支持或正在实现支持BPEL。但是BPMN的支持非常少（大多数厂商提供各自的方案），WS-CDL的支持几乎没有。BPEL并不够。这个体系很理想化，需要实际的实现。

图2. 在理想体系中的BPM 标准

让这个零售流程运行起来

      这个体系结构也许还没有任何实现，但是就零售商处理一个购买订单为例，我们近似描述这个指定的开发周期并建立一个实际的流程。我们从编排开始。一个零售商流程并不是在孤立的环境中运作，而是须同顾客和仓库的流程合作来接收、填写订单。这个编排可以用下面的文字描述：
      1.顾客将向零售商发送订单。
      2.零售商向顾客发送订单已收的确认
      3.零售商将订单转发给仓库并将顾客emai地址也传过去。仓库将用这个地址通知用户什么时候订单完成。
      4.仓库如接受了订单，就发送一个肯定的确认给零售商；如拒绝了订单则发送一个否定的确认。在这个两种情况里，零售商都将仓库的返回结果转发给顾客。
      5.假设仓库接受了顾客的订单。仓库当完成了处理并准备发货的时候，就直接通知给客户发通知。

      WS-CDL的好处就是可以将这些步骤用XML语言形式上编成代码。开始两个步骤的文字描述用WS-CDL编成代码如下：

例子1. WS-CDL 顾客-零售商交互

12 operation="handlePO" initiate="true">
3 4fromRole="tns:Consumer" toRole="tns:Retailer"/>
5 action="request">
6
7
8 
9 action="respond">
10
11
12 
13

      这段代码描述了两个交换之间的交互：在第一个(5-8行)里，顾客发送(action="request")
购买订单(informationType="tns:PO")给零售商，第二个（9-12行）里零售商以订单确认回应(action="response")顾客(informationType="tns:POAck").

      建立零售商流程的第一步是创建一个BPMN图，以满足编排中零售商的所需身份。今天，此步骤需要手工完成；当前的WS-CDL工具还没有一个能生成BPMN(www.pi4ech.com提供了关于一个或两个当前WS-CDL的实现)。这种手工方案，需要看着编排，遵照角色要求画一个流程；图3显示的BPMN图，代表零售商在编排中是个参与者。

图 3：满足编排的零售商流程（BPMN表示）

      这个流程的逻辑很直观。流程从收到客户购买订单（PO）的消息开始（来自客户的PO）。然后接着发送给客户一个确认凭据（发送确认凭据给客户）；将PO转发给仓库（发送PO给仓库）；等待仓库回应。符号清晰直观：盒子扮演“活动”的角色，附有信件的圆圈表示等待“事件”，最后以一个空圆圈表示流程的结束点。

图4. 完全的零售商流程—单击查看大图

      图4展示了附加私有步骤（也就是不是为编排而是内部需求所要求的步骤）的流程。这些步骤以斜体表示：“将PO写入数据库”，当购买订单从顾客发出时将其持久化到内部的零售数据库；“更新PO在数据库的状态”，依照仓库回应状态（也就是接受会拒绝）更新数据库记录；“销售跟进”是一项人工任务，在其被仓库拒绝了的情况下，分配给销售代表去帮助客户重新提交订单。（图中的菱形是异或门(XOR Gateway)。他们被结合起来用的时，形成一个功能类似if语句的代码结构。在《业务流程建模本质》中有对门(Gateway)的详细论述。

      这些图是用ITpearl的流程建模器画出的。ITpearls的流程建模器是Microsoft Visio里一套BPMN模板。流程建模器现在还不是羽翼丰满的开发工具，仅仅是一个画图应用而已。例如它不能生成BPEL代码，这一步须人工生成。无论如何，这些图对设计文档还是有价值的，就像不能生成实际Java或C#代码的UML画图工具一样仍可以辅助软件设计师整理应用的对象和组件，所以流程建模器可以协助业务分析家或设计师将流程描述为一个标准的流程表现形式。

      事实说明，到BPEL的映射非常直观：BPMN流程的“事件”(例如，“等待仓库回应”)是BPEL“接收”(receive)活动(或等待事件发生的活动)；像”发送PO给仓库”的活动是BPEL的“调用”(invoke)活动（或是调用服务的活动）；条件选择结构包含的”销售跟进”是一个BPEL“转换”活动。整个流程是顺序活动图。例2是相应的BPEL代码，其中这些由BPMN派生出来的八个步骤每个都有注释（例如第12行注释为第一步）。

12 targetNamespace="http://acm.org/samples" suppressJoinFailure="yes"
3 xmlns:tns="http://acm.org/samples" 
4 xmlns="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
5 xmlns:bpws="http://schemas.xmlsoap.org/ws/2003/03/
business-process/">
6
7 
10 
11
12
13portType="tns:Retailer" 
14 createInstance="yes" operation="sendPO" variable="po">
15 
16 
17
18 
19
20
21
2223 portType="tns:RetailerCallback"operation="poReceipt" 
24 inputVariable="po"/>
25
26
27portType="tns:RetailerDB" 
28 operation="createPO" inputVariable="po"/>
29
30
31portType="tns:Warehouse" 
32 operation="sendPO" inputVariable="po"/>
33
34
35partnerLink="warehouse" 
36 portType="tns:WarehouseCallback" operation="onResult" 
37 variable="poResponse">
38 
39 
40
41 
42
43
44
4546 portType="tns:RetailerCallback"
47 operation="poResult" inputVariable="poResponse"/>
48
49
50portType="tns:RetailerDB" 
51 operation="updatePO" inputVariable="poResponse"/>
52
53
54
55 
57 59"/tns:POMsg/tns:action") = "reject"">
60
61 
64 65portType="tns:WorkflowTaskManager"
66operation="create" inputVariable="task"/>
67
68 
69 
70
71 
72

      在BPEL代码中"partner links"（以XML属性partnerLink标示，例如13行的partnerLink="consumer"）用来识别流程与谁交互。
consumer，表示客户流程，用在步骤1，2，6中
warehouse，表示仓库流程，用在步骤1、5
retailerDB，作为一个零售数据库的web服务接口，用在步骤3、7
taskMsg，人工作流web服务接口，用在步骤8

      这三种流程的交互表现为：consumer与warehouse是外部系统的交互，retailerDB是一个内部系统交互，taskMgr是 人的交互。所有的交互多是基于web服务的。它们的partner都有WSDL来描述其接口。有趣的是，零售流程本身是一个web服务，它的”接收”活动是web服务操作，写在一个处理负责发布至其他服务的WSDL中。

      与BPMN和ws-CDL不同的是，BPEL有很多好的工具，例如Oracle的BPEL Process Manager，在《业务流程建模本质》中它已被用来开发两个真实的BPEL例子

结论
      由业务分析家在白板上画出的这些粗略流程图的实现需要一个建造在最好的BPM标准上（
BPEL, BPMN, 和WS-CDL）的体系结构。可惜的是，当今没有一个这种体系结构的实际厂商实现。但是真如零售流程的例子所示，一个有用地近似实现是可以盛行的。