BPEL 及其发展历程 -SOA-火龙果软件工程

捐助

BPEL 及其发展历程

作者：turkeyzhou 来源：oracle 发布于 2015-9-17

3209 次浏览

14.1 BPEL 及其发展历程

作为SOA 的关键技术，SDO 和SCA 分别为SOA 提供了数据模型和服务组件模型的定义标准。那么到目前为止，SOA 是否能解决用户所面临的所有业务问题呢？让我们先来看看下面的例子。

一个企业将提供一个订单处理服务。这个订单处理服务在接收到订单后，调用其内部的订单审核服务，而后调用银行提供的支付服务以支付货款，最后调用物流公司提供的送货服务将货物送给客户。这里用户所要做的就是调用订单处理服务下订单，而后他就可以坐等货物的到来了。他不需知道这个订单处理服务的内部都干了些什么。图14-1 描述了这一场景。

图14-1 订单处理场景

目前有三个现存的服务：企业内部的订单审核服务，银行提供的支付服务，以及物流公司提供的送货服务。在SOA 中，我们可以将它们封装成三个SCA 组件，而用户输入的订单数据可以用SDO 来建模。现在我们需要解决的问题是，如何将这三个SCA 组件以想要的顺序进行调用，而这一调用过程对用户来说又是透明的呢？

通过前面SCA 的相关章节，我们知道SCA 规范定义了SCA 组件的封装标准以及如何将多个SCA 组件进行连接（wire）。SCA 组件之间的连接表明了这两个SCA 组件之间有服务的调用的关系，即一个SCA组件的实现调用了另外一个SCA组件的服务。我们这个场景中的三个SCA组件是相互独立的，它们之间并没有服务的调用关系。我们无法用SCA组件的连接来达到目的。看来我们还需要提供另外一个SCA组件，这个SCA组件的实现将分别调用订单审核、支付服务以及送货服务这三个SCA组件。实际上，这个SCA组件的实现就是一个业务流程逻辑，它将按照业务需求，以一定的顺序调用现存的服务。也就是说，这个SCA组件实现了对其他SCA组件的编排。而用户只需要调用这个SCA组件就可以获得所需的流程服务。图14-2说明了这一场景。

图14-2 SCA组件化的订单处理场景

可以看到，订单处理SCA将按照顺序调用订单审核SCA，支付SCA以及送货SCA。我们该如何实现这个订单处理SCA呢？订单处理SCA是按照预定的业务逻辑调用现有的SCA组件，从而形成了一个业务流程，但它本身并不涉及任何具体服务的实现。我们可以选择C++，Java 等编程语言来实现这样的调用逻辑，但这将面临以下问题：

无法以图形化的方式将业务流程逻辑展现给用户。在流程的设计上，我们将不得不借助于图形工具来直观地表现流程逻辑，而后再由编程人员根据这个流程逻辑进行编程实现。业务流程设计人员与IT的设计人员将使用不同的表达方式进行各自的设计，他们之间将存在沟壑并带来理解上的差异。表达方式的不一致最终可能导致系统的实现与最初的业务需求不能吻合，同时这也与SOA的业务与IT对齐的思想相违背。

维护上的困难。企业经常会根据实际需求不断调整流程逻辑。一旦流程出现任何改变，我们将不得不相应修改代码，重新编译部署。这样必将付出较大代价。

无法抽象出组件化的流程语义。纷繁复杂的业务流程也蕴涵着某些共性的逻辑，我们可以把它们抽取出来以便重用。比如刚才的订单处理流程以串行的方式调用了一系列的服务，因此我们可以抽象出串行组件来为流程的建模使用。同样，实际的流程还可能有并行处理的组件，循环调用的组件等。代码实现的流程逻辑很难进行这种流程级别的粗粒度的抽象。即使能够将相应的实现封装成类库来重用实现逻辑，这也只能是企业内部或局部范围的代码级别的重用，而无法形成统一的标准和语义。

看来我们还需要一种标准，它能按照业务需求完成多个SCA组件的调用与编排，从而形成业务流程服务。具体来说，这个标准应具备以下特点：
完全支持SCA组件的调用；

只是定义服务的调用逻辑与规则，不应涉及具体的服务实现；

能够支持将SDO定义的业务对象定义为流程的接收参数，服务的调用参数以及流程的中间变量；

这个标准定义的业务流程本身也能够被封装为SCA服务组件对外提供服务。

我们知道，SCA的服务调用以及接口描述都基于Web服务，而SDO的建模则基于XML Schema。对这两者都能进行很好支持的WS-BPEL标准自然成为合适的选择。

BPEL（Business Process Execution Language）即业务流程执行语言，是业界在以XML、Web服务为基础的诸多规范之上提出的一种新型的业务流程定义语言。它以业务流程及其参与者的交互为基础定义了业务流程的描述语法，用于业务流程建模。其中，业务流程及其参与者的交互用Web服务接口标准加以描述。因此BPEL流程可直接调用符合Web 服务规范的服务。BPEL用来描述多个服务交互的协作与协调，从而对外提供流程服务，以达到某种商业价值。

BPEL标准的早期版本称为BPEL4WS（Business Process Execution Language For Web Service），后改名为WS-BPEL（Web Service Business Process Execution Language），可简称为BPEL。

BPEL的前身是IBM的WSFL和Microsoft的XLANG。WSFL即Web Service Flow Language，是一种基于图的流程模型，具有直观性和灵活性的特点。XLANG是以过程代数为基础的工作流程描述语言，在结构化构造方面具有优势。随着Web服务标准的广泛流行，应用程序将以粗粒度的功能为单位，用Web服务规范封装，对外提供一致的服务。这时，迫切需要一种开放的标准，能够对现存的以及新创建的服务以某种规则进行调度与协调，最终形成具有某种商业价值的业务流程。BPEL标准就是在这种需求下应运而生。

2002年7月，基于WSFL和XLANG，IBM，BEA 和Microsoft提出了BPEL4WS 1.0版本。该标准得到了SAP和 Siebel的支持，并在2003.5进行了修正，形成了1.1版本。BPEL融合了这两种标准的长处，继承了图模型的直观性和灵活性，同时又对异常处理进行了很好的支持。2003年4月，OASIS WS-BPEL技术委员会成立（WS-BPEL TC），专门负责BPEL标准的升级与支持。BPEL标准随后被更新为WSBPEL2.0。WSBPEL2.0已于2007年4月被OASIS正式批准为 BPEL的最新标准。

BPEL标准发布后，由于其以Web服务为基础，与具体的实现无关，具有平台无关性和松耦合性。特别是随着SOA即面向服务的体系结构概念的出现，所有的软件资源与应用都将封装成服务，服务将是基本的操作单位。业务流程在SOA中既是服务的消费者又是服务的提供者。它居于SOA上层，将SOA系统中的孤立服务按照预定的规则进行调度与协调，从而提供有价值的流程服务。BPEL规范的特点使得其在SOA架构中具有固有的优势，被众多的厂商所采用，将 BPEL实现作为SOA产品中的一部分提供业务流程服务。

下面列举了BPEL规范的设计原则：

BPEL所定义的流程实质上是对一系列单个无状态服务的调用与编排，使得这些服务调用按照既定的规则进行。因此BPEL所定义的流程必然涉及与外部服务的交互。其交互接口由WSDL所描述的Web服务接口所定义。从简单性和可重用性考虑，其接口定义应是抽象的，不应涉及服务绑定、服务质量定义等实现相关的细节问题。这些实现相关的定义可在BPEL流程部署时加以确定。

BPEL流程本身也以由WSDL所描述的接口声明为Web服务。在这里，BPEL实际上作为Web服务的一种实现向外界提供服务调用，实现了与Web服务的无缝兼容，同时也为子流程或嵌套流程的定义提供了解决方案。

BPEL是一种基于XML的标准，只描述业务流程本身，而并不关注业务流程的图形化表示，也不涉及业务流程的设计方法学。不同的厂商可以基于BPEL规范在流程建模工具中提供自己的图形化界面来表示BPEL流程。

BPEL的前身是XLANG和WSFL。XLANG是一种由专门的控制构件构成的结构化的流程建模语言，而WSFL是一种基于加入（join）和转换（transition）条件的、图形化的建模语言。WSFL可以根据流程模式进行图形化的建模，具有很强的直观性，易于图形化建模工具的支持。这两种建模语言都有很大的用户群，因此BPEL的目的是要融和两者的优点，争取最多的用户群，提供一个易于直观的图形化建模，同时又可以不加修改的部署到运行环境上的业务流程语言。因此它的建模视图和执行视图应该是一致的，基于同样的概念集，不需任何转换。

BPEL是以流程规则的定义为中心的，并不是一般意义上的数据操作语言，因此BPEL的数据操作支持应以保证流程建模的需要为基础，提供相对简单的数据操作，比如消息的构建，变量的提取与赋值，简单的数据表达式等。而复杂的数据操作和数据存取功能则应交给BPEL过程所调用的服务来完成，而将结果返回给BPEL过程。

任何流程在执行过程中都可能有异常和错误情况发生。因此BPEL必须将错误和异常情况的处理放在与业务流程本身同等重要的地位。业务流程可能是长期运行的流程并跨越多个事务边界，一旦某个环节发生异常，不可能将整个流程执行中所发生的结果都进行回滚。因此BPEL应提供可定制的错误处理和补偿机制，可在定义流程的同时，根据流程自身的特点、异常类型以及实际需求，定义相应的错误恢复或补偿操作，以应对相应的异常情况。

BPEL定义了流程的模板。在BPEL流程的执行环境中，同一个流程模板可以生成多个BPEL流程实例。同时BPEL的服务调用是松耦合的，它所调用的服务不会保留BPEL的实例信息。在BPEL流程与一个服务进行异步交互时，如何将属于同一交互的消息路由到正确的流程实例，是BPEL必须面对的问题。因此BPEL提供了消息与流程实例的关联机制以解决该问题。为了保持Web服务的实现无关性，这种关联机制必须依赖于业务数据，也就是消息中所携带的业务数据，而不是实现相关的数据，如流程实例的标示符。为此BPEL规范定义了关联集合（correlation set）的概念用于消息和流程实例的关联。用户将一组业务属性定义为关联集合，关联集合必须唯一确定一个BPEL流程实例。BPEL运行环境将消息路由到与该关联集相匹配的流程实例。而且，对于流程中不同的接口，用户可以定义不同的关联集合，以适应不同的业务需求。

由于BPEL本身可以作为Web服务的实现向外界提供服务调用。Web服务是一种无状态的服务描述，而BPEL作为多个服务的协调服务可以看做一种有状态的服务。对外的无状态性以及自身的有状态性，决定了对BPEL实例的生命周期管理必须是隐含性的。生命周期的隐含性意味着流程实例的创建和销毁是由 BPEL运行环境根据到来的消息自动进行的，不需人工干预。因此BPEL服务的调用者也就不能通过Web服务调用直接对BPEL的实例进行管理，如实例的创建，运行实例的挂起与继续，实例的销毁等。这些高级的BPEL生命周期的管理功能将留待今后的版本予以增强。
总的说来，BPEL规范具有以下特点：

基于开放的Web服务标准，易于实现跨系统、跨部门、跨企业的互操作。BPEL的调用对象是Web服务，本身也可以作为Web服务向外提供服务，因此与现有的Web 服务标准相融合。由于Web 服务是开放标准，已被众多的企业所采用，BPEL使建立跨企业的业务流程成为可能。

高度的松耦合性。BPEL可看作是对多个服务的调度与协调。BPEL本身只定义流程相关的逻辑，具体的功能则由它所调用的服务来实现，与BPEL无关。由于BPEL调用的对象都是一致的Web服务接口，BPEL定义本身只需指定相应的接口即可，不需要指定实现该接口的服务。相应的实现服务完全可以在部署甚至运行时确定。同时，流程与所调用的服务之间以XML形式传递消息，不直接与服务的实现打交道。因此BPEL流程和所调用的服务之间是松耦合的，他们可以独立地进行替换或修改，而不对另一方产生影响。

服务的重用性。由于BPEL流程的调用对象是服务。一个服务在被一个流程调用的同时也可向其他流程，其他客户提供服务。同时BPEL流程本身也可以封装成流程向客户提供服务或是作为子流程为其他流程所重用。这种服务的可重用性为企业的流程管理减少了开发成本，同时也提高了维护效率。

高度的敏捷性。现代企业的业务需求随时都在改变以适应千变万化的市场。这种需求的快速改变也相应对企业的IT基础设施提出了更高的要求。在企业的业务需求改变时，相应的IT设施必须能够快速调整为新的业务需求提供支持。从业务流程的角度来说，相应的业务流程必须能够容易的、快速的甚至是动态的改变才能满足这一要求。正是由于BPEL具有高度的松耦合性和可重用性，才使其具有敏捷性的特点。

14.2 BPEL相关技术

BPEL作为业务流程的建模语言，基于一系列的开放标准。图14-3是BPEL及其相关标准的示意图。我们可以看到，在这个类似栈结构的图中，BPEL处于所有标准的顶端。

图14-3 BPEL相关技术示意图

XML是所有标准的基础，它为定义标准提供了表述的形式。XPATH则针对XML文档提供了定位某一数据的手段。 XML Schema是定义标准的标准。 XML Schema由XML进行描述，提供了定义标准的语法。SOAP，WSDL以及BPEL均使用XML Schema进行定义。在BPEL中，XML Schema还被用来定义业务流程的输入输出变量以及中间变量。SOAP为服务调用过程中的消息交换提供了消息的封装标准。WSDL是BPEL流程及其参与者交互时的接口描述语言，同时BPEL流程本身也以WSDL为接口标准对外提供自己的服务。由于BPEL是一种实现无关的标准，其运行环境及其他相关工具可用J2EE、.NET等作为实现平台。Web Service的运行环境则为BPEL流程提供了服务的发布，查询，调用等功能。BPEL则关注于定义流程逻辑，实例关联，错误处理，事件处理，变量定义等与业务流程本身相关的标准。

BPEL起源于Web服务，这里有必要对Web服务作简要介绍。

Web服务是Web时代的产物，它可以使得任何信息或服务，无论其原始的实现如何，都封装成统一的形式。用户不需要知道其功能是如何实现的，只要拿到它的接口描述便可以直接访问该服务，如图14-4所示。

图14-4 Web服务场景示意图

Web服务屏蔽了客户与服务提供者之间的系统差异，使得客户可以很容易访问或调用所需服务。Web服务提供以功能为单位的调用标准，目的是对功能的实现进行基于标准的封装，对服务的调用者展现统一的调用接口，而屏蔽服务的实现细节。它是一种无状态的功能调用。而当用户需要以某种定制的次序或规则调用多个功能或服务时，Web服务标准本身就显得无能为力了。而这恰恰是BPEL所关注的焦点。因此，BPEL关注于相对独立的服务或功能的组织和协调，从而在整体上形成具有业务价值的业务流程，而所形成的流程作为整体又可以以服务（service）的形式提供给客户。因此，说BPEL是基于Web服务的，是指它的标准特别是服务的调用以及自己向用户提供服务的标准以Web服务为基础，尽量不定义新的标准。BPEL标准所定义的是多个服务调用的协作以及流程的规则，而服务的提供与调用与Web服务相兼容。

WSDL即Web服务描述语言，用于定义在一个Web服务交互中所需的消息，接口类型，接口参数以及绑定等。下面的XML文档说明了一个WSDL的一般结构。

<wsdl:definitions xmlns:wsdl="http://schemas.xmlsoap.org/wsdl"
 targetNamespace="the WSDL namespace"
 xmlns:tns="the WSDL namespace"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap">
 <wsdl:types>
<xs:schema targetNamespace="schema namespace"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 <!-- Define types and elements here -->
</schema>
 </wsdl:types>

<wsdl:message name="message name">

</wsdl:message>
<wsdl:message name="message name">

</wsdl:message>

<wsdl:portType name="port type name">

</wsdl:portType>

<wsdl:binding name="binding name" type="tns:port type name above">

</wsdl:binding>

<wsdl:service>

</wsdl:service>
</wsdl:definitions>

在定义一个WSDL接口文档时，一般先定义该WSDL所需要的数据类型（type）。当然，数据类型也可以用import元素直接从外部定义文件引入。然后定义消息（message），这些消息将被接口操作定义引用，作为操作的输入输出参数或错误消息定义。定义消息所需要的数据类型应该已经定义或引入。端口类型（port type）实际上就是WSDL的接口定义，其内部定义了该接口所拥有的操作（operation）。操作的输入输出参数将引用消息的定义。绑定（binding）定义了调用Web服务时，输入输出消息采用什么样的协议进行传输。而服务（service）则定义了访问该服务的URL，也就是指出了用户如何才能调用接口提供的服务。可以看出，绑定和服务的定义是与实现相关的定义。而消息及接口的定义则是与实现无关的定义。

假设一个网上商店提供网上直接下订单的Web服务。用户提交订单信息，系统处理订单后返回订单处理结果。消息的传递将采用soap document的方式进行绑定，服务的访问地址是http://virtualwebshop.com/OrderProcess。相应的WSDL文档如下所示：

<?xml version="1.0" encoding="UTF-8" ?>
<wsdl:definitions name="OrderProcess"
　 targetNamespace="http://virtualwebshop.com/ OrderProcess.wsdl"
 xmlns:tns= "http://virtualwebshop.com/ OrderProcess.wsdl"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
　 xmlns:xsd1="http://virtualwebshop.com/ OrderProcess.xsd "
　 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"　
　 xmlns="http://schemas.xmlsoap.org/wsdl/">

<wsdl:types>
<xsd:schema targetNamespace="http://virtualwebshop.com /OrderProcess.xsd">

<xsd:element name="inputOrder" type="Order"/>

<xsd:complexType name="Order">
< xsd:sequence>
< xsd:element name="orderId" type="string"/>
< xsd:element name="productId" type="string"/>
< xsd:element name="price" type="string"/>
</sequence>
</xsd:complexType>

<xsd:element name="response" type="Result"/>

<xsd:complexType name="Result">
<xsd:sequence>
<xsd:element name="orderId" type="string"/>
<xsd:element name="result" type="string"/>
</xsd:sequence>
</xsd:complexType>
</xsd:schema>
</wsdl:types>

<wsdl:message name="InputMessage">
　 <wsdl:part name="OrderInfo" type="xsd1:inputOrder"/>
</wsdl:message>

<wsdl:message name="OutputMessage">
　 <wsdl:part name="Result" type="xsd1:response"/>
</wsdl:message>

<wsdl:portType name="OrderProcess">
　 <wsdl:operation name="orderProcess">
　　 <wsdl:input message="tns:InputMessage"/>
　　 <wsdl:output message="tns:OutputMessage"/>
　 </wsdl:operation>
</wsdl:portType>

<wsdl:binding name="orderProcessSOAPBinding " type= "tns:OrderProcess">
　 <soap:binding style="document"
transport="http://schemas.xmlsoap.org/soap/http"/>

<wsdl:operation name="orderProcess">
<soap:operation
soapAction="http://virtualwebshop.com/OrderProcess /orderProcess"/>
<wsdl:input>
<soap:body use="literal"/>
</wsdl:input>

<wsdl:output>
<soap:body use="literal"/>
</wsdl:output>
</wsdl:operation>
</wsdl:binding>
<wsdl:service name="OrderProcessService">
<wsdl:port binding="orderProcessSOAPBinding" name= "orderProcessPort">
<soap:address location=" http://virtualwebshop.com /OrderProcess"/>
</wsdl:port>
</wsdl:service>
</wsdl:definitions>

BPEL规范位于Web服务标准之上，它能够直接基于WSDL接口对Web服务进行调用。图14-5是BPEL规范与Web服务标准的关系图。

图14-5 BPEL与Web服务示意图

BPEL使用WSDL作为服务调用的接口定义标准。实际上，BPEL通常使用WSDL定义以下信息：

服务的端口类型（port type）定义；

BPEL流程的伙伴链接类型（partner link type）定义。伙伴链接类型是WSDL对BPEL的扩展；

BPEL流程的属性（property）及属性别名（property alias）定义。属性及属性别名也是WSDL对BPEL的扩展。

服务的端口类型描述了服务将要调用的接口和对外提供的接口以及它们所包含的操作和操作所用到的参数定义。在SOA中，参数通常是符合SDO标准的业务对象，由XML Schema文件定义。WSDL接口定义将引入业务对象的定义，并将其指定为某个操作的输入输出参数。

BPEL的伙伴链接类型是为了描述BPEL流程及其参与者的交互以及它们在交互中的作用。伙伴连接类型会引用端口类型定义以指出本交互需要调用的接口，同时还定义了交互的角色（role），以指出本流程在这个交互中是服务的提供者，还是服务的调用者。第15 章对伙伴链接类型进行了详细的描述。

属性别名则是将某个变量属性或消息部分（part）映射为另一属性名，这样就可以将多个不同消息的部分映射为同一属性名，从而认为它们实际上是同一属性，只是属于不同消息而已。下面的代码实例分别将InputMessage中的orderId和 OutputMessage中的orderId映射到了属性OrderNumber上。BPEL流程的关联集合（correlation set）可以引用这一属性将不同消息关联到同一个流程实例。第15章对关联集合的定义和使用进行了详细的描述。

<wsdl:definitions …>
 <bpws:property name="OrderNumber" type="xsd:string"/>
 
 <bpws:propertyAlias messageType="wsdl1:InputMessage" part="OrderInfo" 
 propertyName="tns:OrderNumber">
 <bpws:query><![CDATA[/OrderInfo/orderId]]></bpws:query>
 </bpws:propertyAlias>
 
 <bpws:propertyAlias messageType="wsdl1:OutputMessage" part="Result" 
 propertyName="tns:OrderNumber">
 <bpws:query><![CDATA[/payresult/orderId]]></bpws:query>
 </bpws:propertyAlias>
</wsdl:definitions>

14.3 初识BPEL

上一节我们介绍了BPEL规范的相关技术，特别是BPEL规范与Web服务标准之间的关系。本节我们介绍一下BPEL业务流程都包括哪些元素，以及它是如何对Web服务进行调用和编排的。图14-6是BPEL流程的构成示意图，它说明了一个BPEL流程包含哪些主要元素。

图14-6 BPEL流程构成示意图

伙伴链接在BPEL流程中引用WSDL定义文件中的伙伴链接类型定义，它是BPEL与所调用的服务的桥梁，BPEL流程的任何服务调用都将通过伙伴链接进行。同时BPEL流程本身对外提供的服务接口也由伙伴链接描述。

变量在BPEL流程中表示流程的中间状态，也用做服务调用时的输入参数以及接收服务返回的结果。BPEL中的变量既可以是WSDL中的消息定义也可以是XML Schema所定义的复杂类型或元素。

关联集合实际上是一组属性的集合。在WSDL定义中，通过将多个属性别名定义引用到同一属性上而获得不同消息部分的关联。关联集合用来确定到来的消息将路由到哪个流程实例。

活动是BPEL业务流程的基本构成单位。BPEL规范将活动分为基本活动和结构化活动。基本活动执行变量分配，服务调用等基本任务，它对BPEL流程来说是不可再分的执行单元。而结构化活动是基本活动和结构化活动的容器，它对其内部的活动按照一定的规则执行，如串行执行活动对其内部的活动以串行的方式进行执行，而并行活动则对其内部的活动以并行的方式执行等待。可以看出，活动将构成业务流程的逻辑框架。

在业务流程的执行过程中可能发生错误或异常情况，如网络通信错误，服务调用失败等，BPEL规范定义了错误和补偿处理机制。错误处理和补偿与正常的流程逻辑分开，在流程发生错误时，可以对相应的错误进行处理并对已执行生效的操作通过补偿操作的方式进行定制的撤销。

事件处理器为BPEL流程提供了接收并处理随机事件的能力。这里的事件可以是消息事件，即外部服务向本流程发送的消息，也可以是时钟事件，即某个预定的时刻到达或预定的时间长度得到满足而发生的事件。

图14-7说明了BPEL是如何进行服务调用并形成业务流程的。

此图表明，BPEL的活动是通过伙伴链接调用外部服务的，同时BPEL流程也通过伙伴链接向外界提供服务。BPEL活动还可能引用已经定义的变量作为输入输出参数以及引用关联集合进行消息与流程实例的关联。在必要时，错误处理器可以定义在流程以及活动级别上处理错误发生的情况。

图14-7 BPEL流程服务调用示意图

14.4 BPEL引擎

BPEL文件是一个XML文档，它可以用文本或XML编辑软件手工编写，但手工编写BPEL文件效率低，易出错，而且还要求BPEL文件的编写者对 BPEL标准非常熟悉。因此有专门的BPEL设计工具来完成BPEL文件的生成工作。BPEL设计工具提供图形化的用户界面，BPEL标准的所有组件在 BPEL工具中都有图形化的表示。流程设计人员只需要了解所设计流程的业务需求就可以使用BPEL设计工具的图形界面来设计自己的流程。BPEL设计工具将根据用户流程的图形设计自动生成符合BPEL标准的BPEL定义文件。生成的BPEL定义文件将作为输入，由BPEL引擎执行。BPEL引擎中的流程实例的运行情况将由BPEL管理工具进行监控和管理。图14-8是BPEL设计工具、BPEL引擎以及BPEL管理工具的关系图。

图中的BPEL模板定义文件由BPEL设计工具输出。BPEL引擎将根据BPEL模板定义文件的流程定义，生成相应的流程实例。一般来说流程实例由符合BPEL流程定义中的消息接收活动相应条件的消息激发而生成。因此一个BPEL定义模板可能生成多个流程实例。由于业务流程实例在BPEL引擎中可能是长期运行的，BPEL引擎可能使用数据库等持久化机制来存储流程实例的中间状态信息以及流程的管理控制信息。BPEL引擎可以基于任何平台开发和运行，如J2EE，.NET平台等。

图14-8 BPEL工具及引擎关系图

BPEL引擎负责BPEL定义的解析和执行，为BPEL流程提供运行环境。图14-9是BPEL引擎的典型模块图。

图14-9 BPEL引擎结构图

图中的BPEL引擎利用Web服务处理器接收Web服务消息，如果需要生成新的流程实例，BPEL引擎将根据消息类型与消息内容，从文件系统或数据库得到相应的BPEL定义模板生成BPEL流程实例。如果消息需要发送给现存的流程实例，消息将由消息路由器关联到相应的BPEL流程实例。当流程实例需要调用Web服务时，该调用将由BPEL引擎中的服务调用处理器借助Web服务处理器调用伙伴服务提供者所关联的服务。事件处理器将对流程执行中所发生的事件进行处理，如特定消息到来事件，时钟超时事件等。

另一类业务流程引擎并不是直接对BPEL进行支持，而是将BPEL定义映射为其他的流程定义语言。引擎内核通过解释这种流程定义语言来达到执行流程的目的。下面列举了几种典型的支持BPEL的业务流程产品。

开源的业务流程引擎——jBPM。jBPM是JBoss公司的开源业务流程产品，是一个纯Java实现的引擎，其核心基于一种有向图，叫做活动图（Activity Diagram），并在引擎构建上融入了有限状态机和PetriNet思想。当前jBPM原生支持的过程语言是JPDL（jBPM Process Definition Language），这是一个强有力的引擎扩展。在这个核心引擎的基础之上可以构建对其他过程语言标准的支持，如 BPEL，BPELJ，BPML，ebXML的BPSS，WSCI（Web Service Choreography Interface）以及工作流关联联盟（Workflow Management Coalition，WfMC）的XPDL（XML Process Definition Language）。jBPM目前支持的过程语言只有JPDL和BPEL。

微软的BizTalk Server。微软的BizTalk Server 2006提供两大核心功能：消息通信能力以及业务流程的编排和驱动能力。BizTalk Server2006通过消息适配器来支持通过各种不同的协议来接收和发送消息。收到消息后，BizTalk Server将用“编排”来处理消息，“编排”是业务流程逻辑的载体，并可以预定消息，收到相应的消息，业务流程便被激发。流程开发人员可以利用 Orchestration Designer以图形化的方式开发业务流程。创建好的编排将被转换为.NET框架下公共运行语言（Common Language Runtime，CLR）所用的微软中间语言（Microsoft Intermediate Language ，MSIL）。BizTalk Server 2006提供了Web适配器，利用它，编排可以调用封装好的Web服务。反过来，BizTalk Server 2006还提供了Web服务发布向导，可以将编排中一个或者多个动作作为Web服务导出。BizTalk Server 2006支持导入和导出BPEL，目前支持1.1和2.0版本的BPEL。

BEA的WebLogic Integration和AquaLogic。BEA WebLogic Integration的目标是提供稳健的功能架构，帮助企业实现业务流程自动化，访问各种企业资源，并迅速调整信息系统以适应不断变化的业务需求。其功能结构可以分为三层：动态集成服务层，企业资源访问层以及业务流程管理层。动态集成服务层为系统与现有系统的集成提供了支持；企业资源访问层则提供了业务用户、企业应用以及业务伙伴的快速集成；业务流程管理层则提供了快速进行流程建模、流程自动执行以及业务流程分析的环境。尽管BEA WebLogic Integration可以被用来在业务过程中集成现有的Web服务，以及将实现的业务过程作为Web服务导出，但是它在产品定位上主要还是作为企业内业务集成的产品套件。在跨企业边界的集成领域，特别是SOA架构下的集成，BEA对应的产品套件是AquaLogic，而其中提供BPM（Business Process Management）支持的产品叫作BEA AquaLogic BPM套件，这是BEA收购Fuego公司之后充实到其AquaLogic产品线中的。BEA AquaLogic BPM Suite是一个完整的产品套件，用于创建、执行和优化业务流程。这个套件支持业务与IT之间的协作，以便自动化和优化业务流程。这可以提高效率和灵活性，降低成本，并改进服务的一致性和质量。BEA AquaLogic BPM Suite不仅适合那些正在部署SOA的企业，也可以支持那些没有部署SOA的企业，但是它更多的还是用于前者。

IBM的WehSphere Process Server。IBM的WehSphere Process Server 简称WPS是完全基于SOA的业务流程服务器。它基于IBM的应用服务器（WehSphere Application Server，简称WAS）所提供的强大功能，如J2EE架构、资源管理、高可用性、公共事件管理，安全管理，事务管理等特性，提供组件化的业务流程运行环境。WPS可用于企业内以及企业间的业务流程集成，对应用集成以及人工流程都能很好地支持。它和IBM的业务流程其他产品如WebSphere Business Modeler、WebSphere Integration Developer以及WebSphere Business Monitor一起覆盖了业务流程管理的建模、集成、部属、管理等所有阶段，为用户提供了全面的解决方案。

14.5 BPEL与SOA

让我们先来回顾一下SOA都有哪些显著的特点：

现有资源的重用性。现有资源不加修改就可加入现有的业务系统。

服务的组件性。将业务系统中的功能实现以功能或业务需求为基础，粗粒度地包装成相对独立地单元对外界提供无状态地服务。

组件的松耦合性。SOA系统中的组件之间应该是松耦合的。组件服务的调用者只能看到该组件所提供的服务描述（服务接口），而与组件的实现无关。

服务的随需应变性。随着企业业务需求的变化，其所提供的服务也会随之改变。SOA系统应该具有很强的敏捷性，快速适应业务需求的变化，对软件系统只做很少的调整就能适应新业务的需求。

让我们再来回顾以下SOA的这些特点是如何获得的？大家也许还记得所谓的SOA铁三角，它说明了SOA所致力于解决的三大问题，以及采用了什么样的技术来解决的，如图14-10所示。

SOA架构需要一种基于开放的，与后端数据源无关的，能够清晰表达业务数据的数据模型。SDO很好地解决了这一问题。它基于中立的XML Schema，将业务数据封装成业务对象，系统可以采用离线的方式对其进行访问和更新，而不用考虑任何与数据源和实现相关的问题。这使得业务数据能够建模为数据对象而成为相对独立的实体存在于系统之中并可以在系统的各组件之间进行传递。而SCA标准则解决了服务的封装和调用问题。SOA的特点决定了SOA 不可能是集中式的管理，服务是SOA的基本单位，任何服务在SOA中都是平等的。对服务的调用者看来，任何服务的调用都应该是一致的方式，不应该因服务的实现是Java程序还是C++程序而不同。SCA实现了服务的组件化，每一个服务不论其提供的功能和实现的方式，在SOA系统中都被看做服务组件，它们之间的调用都是松耦合的。

图14-10 SOA技术铁三角

SOA就好像搭积木，SDO和SCA为我们准备好了所需的积木，只是它们还现在处于一种无序状态，一两块“积木”的简单组合显然无法满足企业复杂的业务需求。BPEL的作用就是将这些积木“搭”起来从而形成我们想要的东西。

BPEL支持将XML Schema定义的元素或数据类型作为BPEL的变量进行操作，因此可以直接将SDO定义引入而作为BPEL流程的变量进行操作。同时，BPEL以Web 服务为服务的包装标准，其服务提供和服务调用均由WSDL文件来描述，这与SCA的服务描述相一致。BPEL可以直接引入SCA组件的WSDL描述而对 SCA组件进行调用。BPEL流程本身也可以作为SCA的一种实现，像其他SCA组件一样对外提供服务。图14-11描述了BPEL与SDO和SCA相结合提供流程服务的情形。

图14-11 BPEL与SCA、SDO相结合提供流程服务

图中有四个SCA组件，它们在系统中的地位都是平等的。每个SCA组件均对外暴露接口及引用。接口表明了这个组件将提供什么样的服务，而引用表明这个SCA组件将调用什么样的服务。这些都是SCA组件规范的内容，与SCA的实现无关。在这里SCA组件1中提供了BPEL的流程实现，将对SCA组件 2，3，4按照一定的顺序进行调用。这时，SCA组件1暴露的接口将是BPEL流程的入口所定义的接口，而它暴露的引用恰恰是BPEL进行服务调用时的伙伴链接所引用的接口。由于BPEL和SCA的接口描述都基于WSDL标准，因此它们可以直接被SCA组件暴露，或者说BPEL流程和SCA组件可以共享相同的接口定义。现在SCA组件1已经准备好了“搭积木”的“蓝图”，剩下的工作就是根据SCA规范找到合适的积木把它们搭起来。图中的实线表示，只要通过配置文件的属性设置，就可以将合适的SCA组件与BPEL流程所在的组件“对接”。实际上，这种“对接”就是SCA规范中的wire定义。我们可以看到，BPEL和SCA的结合，使得BPEL的服务调用具有很好的“插拔”性。只要SCA组件的接口和BPEL所暴露出的引用相匹配，我们就可以随意替换 SCA组件，这样既做到了流程逻辑的可重用，又获得了被调用服务的可重用。

我们再来看看BPEL流程是怎样与SDO结合的。由于BPEL支持将XML Schema定义的数据类型直接定义为BPEL的流程变量，因此在SOA系统中，BPEL和业务对象可以共享相同的SDO定义。图中的虚线表示了在SOA 系统中，业务对象是如何在BPEL流程中使用的。BPEL流程服务的使用者调用SCA组件1将业务对象BO1传人SCA组件1，业务对象BO1会被 BPEL流程接收，并启动新的BPEL流程实例。BPEL流程根据所调用的SCA接口定义，生成BO2，BO3和BO4，并用它们分别传递给SCA组件 2，3和4，从而实现这些SCA组件按照预定的次序执行。我们看到业务对象在SCA中以及BPEL流程中始终采用一致的定义模型，并不需要进行任何转换。

因此，BPEL与SDO的很好结合使得BPEL在数据层面上融入了SOA，而BPEL与SCA的很好结合使得BPEL在服务层面上融入了SOA体系结构。BPEL与SDO和SCA一起构成了SOA的基石。图14-12用层次化的结构说明了BPEL在SOA中的地位和作用。

图14-12 SOA体系结构

图中服务组件层将以服务组件为单位提供单个服务的封装，对外隐藏了服务的实现细节，SCA规范可作为这一层等的实现技术。服务层则是单个的服务或是多个服务组件的简单连接。用户可以直接访问这一层而获取所需的服务。但这一层的服务多是单个服务组件或多个服务组件的简单组合所提供的服务。但是复杂的业务流程需要对多个服务组件按照预定逻辑进行组织和编排，这就是业务过程层所起的作用。BPEL规范是实现业务过程层的合适技术。因此，一般来说BPEL流程位于SOA的上层，是与企业的业务逻辑关系最为密切的一层。

14.6 BPEL与业务过程管理

业务过程（也可称为业务流程）是为了达到某一业务目的而执行的一系列活动及其执行规则的集合，业务过程的输出是符合商业价值的产品或者服务。

传统的企业管理模式通常是制订出部门级的或是跨部门级的业务流程，再下发给相关的执行者。执行者按照业务流程的要求做出相应的行为。早期，驱动流程执行的是报表或图纸，流程中每一步骤的执行者会根据报表或图纸的数据执行自己的操作，并输出自己的数据，进而驱动流程继续进行。这种传统管理模式的弊端是显而易见的：

效率低下。报表和图纸等材料都需要人工传递，而且在传递的过程中还有可能出现各种错误，影响流程的执行。

理解上的差异。流程的执行者可能对手中的流程规则有不同的理解，从而可能导致流程的执行和制订流程的初衷相背离。

流程规则易被人为改变。流程的正确执行有赖于流程的执行者，某一环节有可能被执行者有意违背而不被限制或不被察觉。

数据的保存极为困难。企业对众多的流程规则以及相应的数据档案的保存和管理都需要付出很大代价。

很难对流程进行监控和管理。在这种模式下，企业的管理者很难及时了解到某一流程的执行情况并对其采取相应的措施。

随着IT技术的不断发展，特别是工作流技术，ERP系统等的发展，业务流程的执行和管理进入了自动化的模式。业务流程在制定好后便可以由工作流系统自动执行，相应的报表、图纸的数据也可以在计算机网络中自动传递，数据可以被系统自动保存，流程规则也很难在执行过程中被人为改变。企业的某些资源在一定程度上被整合起来。但这时的业务流程也面临着诸多问题：

流程的自动执行还只局限在部门内部或企业内部。由于流程的建模和执行语言大都采用系统定义的私有语言，不同的系统之间很难进行互操作。企业的不同部门之间以及企业之间的流程还不能进行互相调用。

流程系统很难与现有的系统进行集成。由于工作流系统还是相对封闭的系统，大都采用私有的协议或紧耦合方式进行数据的传输或接口的调用，这使得它很难与企业现有的应用系统进行集成，从而使得工作流系统与企业的现有业务处于一种分离状态，不能对企业现有资源进行全面的整合以及真正的实现流程的自动化。如果对现有应用系统进行全新的改造，又必将付出巨大代价。

流程模型不具有通用性。当时业界缺乏统一的流程建模语言，即使工作流管理联盟（workflow management coalition，WfMC）制定了相关的推荐标准，但并没有获得各大厂商的广泛支持，各大流程厂商纷纷定义自己的流程建模语言并与自己的流程产品绑定，某一产品输出的流程模型几乎不可能用于其他产品，这使得企业将不得不依赖于一个厂商。

随着企业管理模式向以流程为核心的方向转化，业务流程将成为企业最重要的资产。业务流程是否合理、高效将直接影响企业的核心竞争力。现有的工作流系统已经不能满足企业的实际需求，企业对业务流程的管理提出了更高的要求，同时业界也提出了业务过程管理的概念。

业务过程管理（Business Process Management，BPM）将企业业务与现代信息技术相结合，尽量缩小它们之间的差距，目的是从业务过程的角度对企业进行全方位的管理，为企业内及企业间的各种业务过程提供一个统一的建模、集成、部署和管理的环境，同时支持业务过程的持续优化和改进，从而大大提高企业的运行效率，增强企业的市场竞争力。业务过程管理系统BPMS 为实现BPM的功能提供软件环境。一般来说，业务过程管理系统具有以下特点：

最大限度的利用企业现有的资源。企业的业务过程管理涉及企业的众多资源，包括数据，应用程序，ERP软件，供应链，人员等，如果要对企业现有的资源进行全新的改造，必然要付出昂贵的代价，而且以前的投资也将付之东流。因此业务过程管理应有能力对现有资源进行整合，最大限度的利用现有资源，对它们进行很少的改造或根本不用修改就能将它们容易地集成到业务过程管理系统中来。

过程逻辑和功能实现的分离。过程逻辑定义了一系列相关逻辑单元的执行顺序和规则。一方面过程逻辑的分离能够使业务过程的定制和变更不依赖于活动的实现，另一方面，过程逻辑将可以独立出来作为企业重要的资产单独保存。

快速适应市场变化的能力。市场的变化必然对企业的业务需求提出新的要求，企业的业务过程也将随之发生变化，这就要求企业的业务过程管理系统必须能快速的做出响应，适应新的需求，即随需应变。

与外部企业或机构的互操作能力。随着经济全球化的发展，现代企业的业务过程往往不会在一个企业内部完成，越来越多的需要与其他的企业协作完成。比如许多企业将自己的非核心业务如财务管理，供应链管理等外包给其他专业的公司来完成，而企业本身则专注于自己的核心业务。这样一个业务流程往往要求多个公司共同参与，而以往公司内部的工作流系统很难满足这样的要求。而业务过程管理模型应是并行，分布，协同，松耦合的过程并基于开放的标准。

根据业务过程的功能，我们可以将业务过程划分为以下两类：

集成为中心的业务过程（Integration－centric processes）

人工为中心的业务过程（human-centric processes）

以集成为中心的业务过程通常是将多个异构系统按照业务需求进行集成，以便某一系统进行业务数据的更新，其他系统也能自动得到通知并进行相应的操作从而保证所有系统的一致性。图14-13是一个业务集成的示意图。

图14-13 业务集成示意图

图中表示一个企业的三个部门的业务分别由SAP，ORACLE以及DB2系统管理。若其中的一个部门的业务数据发生变化，ORACLE以及DB2系统也应得到变化的业务数据并进行相应的操作。这一过程根据具体的业务需要通常也是比较复杂的流程，如根据某一业务数据的值进行一系列的数据处理后再提交其他系统。目前这一任务将由专门的业务集成中间件完成。业务集成中间件将根据业务需求定制详细的流程模板，一旦收到业务数据，将按照预定的流程对业务数据进行处理，最终达到业务集成的目的。IBM的WebSphere Interchange Server是典型的业务集成中间件。以集成为中心的业务过程的特点是业务流程自动进行，一般情况下不需人工干预，因而能够在较短的时间内运行完毕。

以人工为中心的业务过程中的各流程步骤则是以人工任务为主。比如企业内部的业务审批流程则可能需要对某一文件进行逐级的审批。这一过程很可能也是一个复杂的流程逻辑，如多人会签，超时升级，否决回退等。以人工为中心的业务过程也有专门的产品，如IBM的MQ Workflow等。这种类型的业务过程的特点是以人的参与为主，因而流程实例很可能存在较长的时间。

实际上，以上两种类型的业务过程并非界限清晰。随着企业业务过程管理的不断发展，企业对业务的流程化越来越重视。业务集成过程也可能会包含人工流程的成分。比如在业务集成的过程中发生异常，或是在某些特殊的业务数据到来时也需要人工进行干预，或者由人工来决策如何继续进行业务集成。同时，人工流程在开始可能是纯粹的人工任务，但是随着流程的不断发展和优化，经常需要在流程的某些环节与现有的系统进行集成，以实现某种业务需求。可以看到，随着企业业务过程的不断发展，业务集成过程以及人工流程出现了逐渐融合走向统一的趋势。纯粹的业务集成软件或是纯粹的人工工作流软件越来越显得无路可走。市场迫切需要一种能将两者合二为一的，并且能够快速适应企业发展变化的新技术和新产品。

SOA恰恰能够很好地满足市场的这一需求。SOA提出的是一种新的编程模式，它并不排斥现有系统。现有系统可以通过适配器将业务数据转换为业务对象交由SCA服务组件进行处理。SCA组件的实现可能是由BPEL定义的流程来完成业务流程的逻辑。BPEL只关注于流程逻辑本身。在流程的执行中，它将调用其他的SCA组件以完成流程的每一步骤。这里的SCA组件既可以对应于其他系统的适配器，以调用现有系统提供的功能，完成对该系统的业务集成，也可以是人工任务的实现完成流程中人工任务的业务需求。

BPEL是SOA系统中业务流程的建模和执行语言，它基于开放的Web服务标准，只关注于业务流程本身，可以对任何基于Web服务的系统进行互操作。在SOA系统中，BPEL流程负责SCA组件的调度，直接定义业务流程规则。因而从业务过程管理的角度来看，BPEL作为SOA业务流程层的实现技术在整个系统中居于核心地位，它与业务逻辑关系最为密切。

图14-14说明了基于SOA的业务过程管理的生命周期。

图14-14 SOA的生命周期

建模（Model）阶段是通过理解业务需求而获得业务流程设计的过程。在设计的初期，可能由于对业务需求理解的还比较粗浅，业务流程的设计也会比较粗糙甚至存有歧义或错误，但随着对业务需求理解的逐步深入，业务流程的设计也会逐渐细化并走向正确。如何表达业务流程是这一阶段面临的问题。我们可以用自己定义的流程符号在纸张上画出流程的设计思想，也可以用现有的流程图绘制软件表达流程的设计思想，其目的都是希望别人特别是下一阶段的流程设计人员能够理解自己的设计意图。但这种方式只能局限于较简单的流程和较小的项目团队。实际上，这一阶段应有专门的工具以及标准的建模语言予以支持。参与这一阶段的人员通常是业务层面上的流程分析人员，他们具有精深的业务知识但并不一定具有丰富的IT知识，甚至连Web服务都一知半解。因此用BPEL进行建模并不合适。这一阶段的建模语言应该能够直观的表达流程逻辑，不需专门的IT知识，具有丰富的语义能够表达丰富的流程逻辑模式。当前具有代表性的是业务流程模型注解（Business Process Modeling Notation，BPMN）由业务流程模型互操作组织（Business Process Management Initiative，BPMI）定义，用于业务流程的建模并可以映射为BPEL定义。这一阶段的流程建模弥补了业务需求与IT技术之间的沟壑。除了提供业务流程的建模功能，这一阶段的建模工具还可提供业务流程分析，模拟仿真，关键绩效指标的定义等以便和以后的阶段一起对业务流程不断进行优化。

集成（Assemble）阶段，软件架构师将和业务分析师一起将建模阶段的业务设计转换成一系列的业务流程定义（将以BPEL定义）以及活动，并根据活动定义分析获得所需服务组件。服务组件应首先在现有的系统中寻找，有的组件可能会完全适合，有的则需作调整，有些则需要创建新的服务组件。所需服务组件具备后，就可以按照业务流程的定义将它们集成在一起，并进行调用绑定，安全设置，事务设置，资源依赖等的配置。这时业务流程已经是可执行的流程，项目已经准备好部署到运行环境中执行了。集成阶段的支持工具能够将建模阶段的输出导入，创建新的服务组件以及对现有的服务组件进行集成。此外集成工具还可对每个服务组件进行单元测试，以及集成测试，保证集成阶段业务流程的正确性。

部属（Deploy）阶段，集成阶段完成的项目将被部属到运行环境上从而实现业务上的需求。部属阶段应根据实际的业务需求，充分考虑运行环境的配置，如是否采用高可用性配置，是否需要负载均衡，数据库的配置，安全策略的配置，消息中间件的配置等。

管理（Manage）阶段，管理阶段将基于相应的软件工具和技术对运行环境中的服务和流程进行管理和监控，发现系统运行错误，恢复系统状态，获得关键性能指标，发现性能瓶颈。管理阶段所获得的业务流程的性能数据和运行统计数据还会反馈给建模阶段以对流程进行不断的优化。

可以看出业务流程的生命周期，建模、集成、部属、管理，是一个循环的过程，从而使企业的业务过程获得不断调整和优化，能够快速地适应市场变化。

业务流程是对现实世界的业务需求的抽象，我们可以抽取业务流程中的共性的逻辑形成模式以便流程建模时进行重用。业务流程的建模语言如BPEL也定义了专门的组件（在BPEL中称为结构化活动）来表达基本的流程模式，对于更为复杂的模式，我们可以用多个基本模式的组合来达到要求。下面我们列举一些常用的业务流程模式。

串行执行模式，如图14-15所示。