从亨利福特开始通过装配线生产福特汽车，直到今日，我们一直都在想办法来更好地、更快地、更可靠地、更经济地完成工作。业务流程是一种非常好的方法。业务流程可以被定义为一个具有各种不同功能的活动相连的一组有相互关系的任务。如何将分布的Web服务组合实现业务流程，对企业实现全球化和虚拟化具有重要意义。BPEL（Business Process Execution Language，业务流程执行语言）是业界认可的标准，也是SOA实现组合服务和服务编排的重要技术基础。这是《SOA：原理方法实践》的第10章。本章将重点介绍BPEL的基本特性和使用模式。

　　引言

　　《SOA：原理方法实践》是一本全面探讨SOA理念、SOA方法学、设计模式和案例分析的书籍。这本书由IBM新技术研究院Web 2.0首席架构师毛新生领衔执笔，汇集了IBM软件开发中心众多SOA专家们的经验和智慧。

　　本书首先从作者的实际经验出发，分析SOA产生的根源，然后分析SOA的相关开发技术，最后结合实例讲述完整SOA项目的开发过程。我们将陆续推出此书的第1、4、10章。

　　第10章：业务流程简述

　　业务流程可以被定义为一个由各种不同功能的活动相连的一组有相互关系的任务，它们依照一定的业务逻辑和顺序依次执行。业务流程有起点和终点，而且它们都是可重复的。业务流程是企业实现商务目标的方法。对于企业而言，业务流程是企业重要的知识资产，是企业的核心竞争力的体现，一个精心设计和执行的业务流程能够为企业创造价值并节约成本。

　　在著名作家佛里德曼的获奖作品《世界是扁平的：21世纪简史》（THE WORLD IS FLAT: A Brief History of the Twenty-first Century）一书中，对经济全球化有着精彩的论述。它描绘了一个由互联网、通信基础设施和新型软件搭建的全球舞台；在这个舞台上，人们能够以多种方式分享知识、劳动、娱乐和发现，并且创造新的商业机会。佛里德曼举例说：”如今沃尔玛是美国最大的公司，然而它什么也不生产，只是建立了这个非凡的供应环节，从世界各地进口非常便宜的商品……并把世界各地的产品送到消费者手里。它是一个全球组装线。”

　　在经济全球化的过程中，企业的边界变得模糊，企业会将任务分解为一系列的子任务，企业只关注于自己的核心竞争力所在，并将其他工作分包给最合适的人来完成。企业需要通过业务流程将这些片断有机地组织在一起。在这里我们可以深刻地认识到业务流程对企业的重要性。

　　定义业务流程并对其做出文档所花费的时间和努力是完全值得的。在一个反映中国传统医学的电视剧中，当配置药剂的时候，掌柜把自己反锁在药房里，只有他会根据”秘方”将不同的药材调配成救死扶伤的灵药。然而只有他一人掌握这个过程是非常危险的。对于现代企业来说这更是不可能的，我们不可能只让配件制造主任了解企业的配件制造知识，然后让他每晚独自装配所有的零件。只要定义了配件制造业务流程，配件制造工人可以随时来去，而且任何配件制造工人都可以随时取代另一个人的工作，这是因为工厂里的所有配件制造工人都理解并遵循业务流程。我们可以学习、改变、评估，然后再次改变配件制造业务流程，因为该流程对于每个人都是可见的，而非局限于配件制造主任。

　　现代业务流程管理系统的历史可以追溯到工作流系统。简单地来讲，工作流定义了业务流程中的参与者（Who）、所执行的工作（What）及何时执行（When）。在企业IT环境中，工作流软件通常与企业应用集成（Enterprise Application Integration，EAI）系统结合在一起，成为企业应用的”黏合剂”，实现业务流程的自动化和流水线化。

　　传统工作流系统的最大缺陷就是：它们大多采用了专有技术。这使得业务流程与企业应用的结合变得非常复杂，通常需要很长时间进行部署和实施，而与企业外部系统进行集成则更加困难，无法适应全球化浪潮和互联网时代对企业灵活、无缝集成的需求。人们开始考虑利用Web服务的开放性和标准化，来解决业务流程与企业应用之间的互操作性问题。

　　10.1 BPEL简史

　　2002年7月，IBM、微软、BEA提交了Business Process Execution Language for Web Services（BPEL4WS）1.0的规范。业务流程执行语言基于XML和Web服务技术，它融合了早期的IBM的Web Services Flow Language（WSFL）及微软的XLANG规范的很多特点。随后许多主要供货商如SAP和Siebel（已被Oracle并购）等公司陆续加入规范的制定，并催生了多项修改和改进，并于2003年3月发布了1.1版。2003年4月，BPEL被提交结构化信息标准促进组织（OASIS）以实现标准化，并组建了Web服务业务流程执行语言技术委员会（WSBPEL TC），该努力使BPEL在业界获得更为广泛的认可。目前该技术委员会正在致力于下一代规范的制定工作，并将该规范重命名为WS-BPEL 2.0。

　　虽然除BPEL之外还有一些业务流程规范，但是到目前为止，BPEL是最为成熟和被广泛支持的技术。WebSphere Process Server 6.0提供了BPEL4WS1.1规范兼容实现，并支持制定中的WS-BPEL 2.0草案。除此之外还增加了对人员任务（WS-BPEL Extension for People）和Java语言（BPELJ）等扩展的支持。在下文中，我们将利用WebSphere Integration Developer 6.0和WebSphere Process Server 6.0来演示如何创建和运行BPEL流程。

　　关于本文涉及的 BPEL规范，可以从下面网址获得：业务流程执行语言（1.1 版）

　　10.2 BPEL的基本特性

　　相对于对象组装技术，服务组装更为复杂。人们必须面对SOA环境中异构的、松耦合的、自主的服务。它们间的交互关系是动态的、按需发生的，而且缺少中央控制。因此，BPEL提供的服务组装模型提供了下列特性。

　　（1）灵活性：服务组装模型应该具有丰富的表现能力，能够描述复杂的交互场景，而且能够快速地适应变化。

　　（2）嵌套组装：一个业务流程可以表现为一个标准的Web服务，并被组装到其他流程或服务中，构成更粗粒度的服务，提高了服务的可伸缩性和重用性。

　　（3）关注点分离：BPEL只关注与服务组装的业务逻辑；其他关注点，比如服务质量（QoS，Quality of Service），事务处理等，可被作为附加扩展，由具体实现平台进行处理。

　　（4）会话状态和生命周期管理：与无状态的Web服务不同，一个业务流程通常具有明确的生命周期模型。BPEL提供了对长时间运行的、有状态交互的支持。

　　（5）可恢复性：这对于业务流程（尤其对长时间运行的流程）是非常重要的。BPEL提供了内置的失败处理和补偿机制，对于可预测的错误进行必要的处理。

　　10.3 BPEL模型

　　BPEL模型可以帮助我们更好地理解如何使用BPEL描述的业务流程，如图10-1所示。流程（Process）由一系列活动（Activity）组成；流程通过伙伴链接（Partner Link）来定义与流程交互的其他服务；服务中可以定义一些变量（Variable，在BPEL4WS中被称为Container）；流程可以是有状态的长时间运行过程，流程引擎可以通过关联集合（Correlation Set）将一条消息关联到特定的流程实例。

　　图10-1 BPEL模型示意
 
　　1．伙伴（Partner）

　　在BPEL中，一个流程可以调用其他服务，也可以响应来自客户端的请求。也就是说BEPL流程实例既可以作为服务的请求者，也可以扮演服务的提供者。BPEL把与流程交互的其他服务称为伙伴（partner）。在异步通信环境中，流程与伙伴之间的会话可能是双向的，这在复杂的商务流程中非常常见。

　　在流程与伙伴的通信过程中，它们会扮演不同的角色。比如当订单流程被外部服务调用的时候，它作为”PurchaseOrderProcess”角色来提供服务，然而当它请求发货服务的时候，它则扮演”InvoicecClient”角色，如图10-2所示。由于在流程执行过程中，一个流程可能会调用多个伙伴服务，又可能接收多个伙伴的请求，因此为了消除在通信过程中的多义性，我们需要明确服务和流程所扮演的角色。

　　图10-2 订单流程示意
 
　　在BPEL中，这种流程与伙伴的合作关系是通过<partnerLink>元素来定义的。这样如果在流程的活动中需要指定与特定伙伴的交互，只需要引用partnerLink的名称即可。而且通过partner links的抽象，在流程建模时，我们不必指定具体的服务端点，而将流程与具体服务的绑定推迟到组装或运行时来完成。这种动态伙伴关系为流程带来了极大的灵活性，也增强了流程的可复用性。比如，我们在开发环境中使用的伪服务实现，在生产环境中无需须修改流程就可以将服务端点替换为主机应用。

　　在<partnerLink>元素中，可以通过”myRole”和”partnerRole”属性来定义流程和伙伴的角色。如果流程作为服务的提供者，需要使用myRole属性，而当流程作为服务的请求者时，则使用partnerRole属性。

　　partnerLink通过引用partnerLinkType来定义流程与伙伴服务之间的通信接口（实际上是WSDL文档中的Port Type）。伙伴链接类型声明了两个（也可能是多个）服务之间的关系。服务链接类型定义了一组角色，其中每个角色指明一组Port Type，即明确了该角色所提供的服务接口。partnerLinkType通常被定义在WSDL文档中，被BPEL流程所引用。

　　下面的代码片段显示了如何利用partnerLink和partnerLinkType定义流程与伙伴的合作关系。我们实现了一个股票购买流程，在这个流程中需要通过伙伴StockQuote获取当前股票信息：

　　<bpws:partnerLinks>
　　  <bpws:partnerLink myRole=”StockServiceRole” name=”StockService”
　　  partnerLinkType =”ns:StockServicePLT”/>
　　  <bpws:partnerLink name=”StockQuote” partnerLinkType=”ns:PartnerPLT”
　　  partnerRole =”partnerRole”/>
　　  …
　　</bpws:partnerLinks>
 
　　我们还需要在流程对应的WSDL文档中定义partnerLinkType：

　　<definitions   … >
　　  <plnk:partnerLinkType name=”StockServicePLT”>
　　    <plnk:role name=”StockServiceRole”>
　　      <plnk:portType name=”wsdl0:StockService”/>
　　    </plnk:role>
　　  </plnk:partnerLinkType>
　　  <plnk:partnerLinkType name=”PartnerPLT”>
　　    <plnk:role name=”partnerRole”>
 　　     <plnk:portType name=”ns:net.xmethods.services.stockquote. StockQuotePortType”/>
　　    </plnk:role>
　　  </plnk:partnerLinkType>
　　<import location=”urn_xmethods-delayed-quotes.wsdl” namespace=
　　”http://www. themindelectric.com/wsdl/net.xmethods.services.stockquote. StockQuote/”/>
　　</definitions>
 
　　2．变量（variables）

　　在BPEL中，我们可以使用变量来保存和传递流程的状态信息。变量的数据类型由WSDL定义，既可以是XML Schema内置的简单类型，又可以是自定义的复杂数据类型：

　　<bpws:variables>
　　    <bpws:variable name=”symbol” type=”xsd:string”/>
　　    <bpws:variable name=”UserInfo” type=”ns1:UserInfoBO”/>
　　    …
　　<bpws:variables>
 
　　上面的代码，展示了如何在BPEL中使用<variable>元素来定义变量。值得注意的是，与常见的编程语言类似，BPEL中的变量是有作用域的；每个变量只有在定义它的作用域和所包含的作用域内才是可见的。在下面的章节中，我们将介绍如何使用BPEL来操纵和传递数据。

　　此外，WS-BPEL提供了一些内置的函数来支持变量内容的处理：

　　（1）getVariableProperty（variableName， propertyName）为获取变量属性函数：输入参数为变量名称和属性名称，结果为属性值。

　　（2）getVariableData（variableName， partName？， locationPath？）为获取变量数据函数：输入参数为变量名称、part名称，以及XPath表达式，其中partName，和locationPath为可选参数。输出结果为指定变量的全部或部分的数据内容。

　　3．活动（Activity）

　　BEPL流程是由一系列步骤所组成的，它们被称为活动。WS-BPEL定义了丰富的活动类型，一般来说可以把它们划分为两大类：基本活动和结构化活动。基本活动描述了流程内的一个具体步骤，比如接收请求、调用伙伴服务、变量赋值等。而结构化活动则描述了如何组织和管理流程的控制流。在下面的章节中，我们将对活动进行详细讲解。

　　4．关联集合（Correlation Set）

　　BPEL提供了声明性机制，以指定服务实例中相关联的操作组。一组相关标记可定义为相关联的组中所有消息共享的一组特性。这样的一组特性称为关联集合。每个关联集都在一个作用域中进行声明并属于该作用域。属于全局流程作用域的关联集称为全局关联集；属于局部作用域的关联集称为局部关联集。在流程开始时，全局关联集处于未初始化的状态。在其所属的作用域的执行开始时，局部关联集处于未初始化的状态。

　　相关集在其语义上类似于延迟绑定的常数。相关集的绑定由特别标记的消息发送或接收操作来触发。相关集在其所属的作用域的生存期中只能初始化一次。在初始化之后，它的值就可被认为是业务流程实例的标识别名。在多方业务协议中，相关集合非常有用。初始者流程发送启动会话的第一个消息，从而定义了标记该对话的相关集中的特性值。所有其他参与者通过接收提供相关集中的特性值的传入消息来绑定会话中的相关集。比如一个旅行社订票流程，当该流程启动之后，用户需要能够查询该流程状态，并能取消该流程，这就需要相关集的支持来确保后续的请求消息绑定到相同的流程实例中。

　　10.4 BPEL活动

　　我们将首先介绍常用的基本活动。

　　1．Receive（接收）/Reply（回答） 

　　<receive>活动从流程的外部伙伴那获取数据，并将其保存到流程变量。通常一个Receive是一个流程的初始点，它会阻塞执行直到匹配的消息的到达。

　　<reply>活动发送消息给伙伴来应答通过receive活动所接收到的消息。receive和reply的组合对应着WSDL portType上定义的一个请求-响应操作。如果receive活动对应着一个单向（one-way）操作，则不能在流程中定义对应的reply活动。

　　<bpws:receive createInstance=”yes” name=”Receive” operation=”buy”
partnerLink =”StockService” portType=”ns0:StockService” />
…
　　<bpws:reply name=”Reply” operation=”buy” partnerLink=”StockService”
portType=” ns0:StockService” />
 
　　上面就是BPEL中包含receive和reply活动的片段。值得注意的是，receive和reply活动中都是通过”partnerLink”来引用预定义伙伴关系的，而且需要设置”portType”和”operation”属性来声明流程实现的WSDL portType和操作。此外，如果将receive活动作为流程的起始点，则需要将receive活动的createInstance属性设置为”yes”，它指明了当流程接收到匹配的消息时会创建新的流程实例来处理该请求。在BPEL流程中我们还可以定义更为复杂的消息响应机制，可以将特定的消息关联到相应的流程实例中。CorrelationSet（关联集合）就是为了解决上述问题而出现的。