WS-BPEL是为组合Web服务而制定的一项规范。它的前身是由IBM、Microsoft共同推出的Web服务业务流程执行语言BPEL4WS，2003年4月6日交由OASIS组织审查，正式公布1.0版本，并且成立BPEL4WS技术委员会，决定未来规范的发展方向。该委员会致力于产生一种用于编写Web服务控制逻辑的、独立于平台的、基于XML的编程语言。2003年5月3日，由BEA、IBM、Microsoft、SAP及Siebel Systems五家公司完成BPEL4WS 1.1版本。BPEL4WS 1.1版本推出后，技术委员会又对BPEL4WS 1.1做了大量修改工作，使之得到全面提高。随后，推出Web服务业务流程执行语言2.0规范草案，把BPEL4WS语言改称为WS-BPEL（Web Services Business Process Execution Language），除此之外还增加了对人员任务（WS-BPEL Extension for People）、Java语言（BPELJ）和子业务流程（WS-BPEL 2.0:Extensions for Sub-Processes）等的扩展支持。虽然除BPEL之外还有其他业务流程规范，但是到目前为止，BPEL是最为成熟和被广泛支持的技术。

　　WS-BPEL是IBM的WSFL和Microsoft的XLANG相结合的产物。WSFL和XLANG分别基于Petri网和Pi-calculus，因此BPEL吸收和借鉴Petri网和Pi-calculus的优点，是一种高级的、抽象的、可执行建模语言，它不仅实现Web服务间的交互和流程编排，也将流程自身暴露为Web服务。

　　BEPL产生的动机源于以下三个方面：

　　1. 面向业务的整合

　　企业内部的整合（Enterprise Application Integration）
　　合作伙伴间的集成（Business-to-Business Integration）
　　企业间跨行业整合（Syndication）

　　2. Web Services到面向服务的计算（Service-Oriented Computing）的演进

　　应用被看作服务（Service）
　　松耦合（Loosely Coupled），动态交互
　　异构平台（Heterogeneous Platforms）

　　3. 服务组合

　　域中服务如何组合？

　　WS-BPEL的技术特征

　　作为当前基于流程的Web服务编排（Service Choreography）最常使用的技术，BPEL提供了一个描述基于流程及其合作伙伴之间Web服务交互的业务流程行为模型。使用BPEL可以实现两种不同类型的流程：可执行流程和抽象流程。可执行流程描述了服务的内部实现，抽象流程则定义了服务的外部行为。

　　服务编排是BPEL设计的核心概念。BPEL提供序列和规则来描述Partner Services被调用的顺序。这种功能我们可以使用Java、C或C#等语言，通过在应用中硬编码的方式来实现，但却牺牲了业务和应用变更的灵活性，也造成整个体系结构的紧耦合。通过BPEL来描述服务之间的关系，我们可以实现非常轻便的松耦合架构，来配合企业业务的灵活变更。WS-BPEL相当于服务间的粘合剂，帮我们轻松实现服务间的编排（如图1所示）。

　　图1

　　WS-BPEL依赖于下列基于XML的规范：WSDL 1.1、XML Schema 1.0、XPath 1.0、XSLT 1.0和Infoset。其中，WSDL对WS-BPEL的影响最大。WS-BPEL的流程模型位于WSDL 1.1定义的服务模型的顶层（如图2所示）。

　　图2

　　在WSDL中，不仅定义了服务允许的各种传输消息类型和操作，还通过定义服务链接类型描述服务间的依赖关系。图3显示了BPEL在WS-*协议族中的位置。BPEL定义了WSDL操作如何被编排在一起以满足业务流程，BPEL还明确规定了在支持长运行异步（long-running asynchronous）流程方面对WSDL的扩展。在BPEL中，直接引用WSDL中定义的操作，并通过Web服务接口提供流程实例。相对于其伙伴和资源行为及交互的描述，流程和其相关的合作伙伴都被暴露成WSDL服务。业务流程定义了一个流程实例和它的partners之间该怎样协同交互。由此，WS-BPEL流程定义提供或使用一个或多个WSDL服务。更准确地说，WS-BPEL被用来描述在交互中一个有着明确角色流程的消息交换。

　　图3 WS-BPEL in the WS-* Stack

　　WS-BPEL业务流程的定义遵循WSDL的分离（Separation of Concerns）模型，即把业务流程使用的抽象消息内容与部署信息（消息和端口类型<port type>通过绑定<binding>和地址信息<address information>）分离。具体地说，WS-BPEL流程用抽象WSDL接口<port types>和操作来表示所有的合作伙伴以及与这些合作伙伴的交互，它并不引用流程实例使用的实际服务。WS-BPEL不做关于WSDL binding的任何假设。

　　WS-BPEL 2.0的语法构造

　　WS-BPEL支持的业务流程能够指定一组Web Services操作这些Web Service间共享的数据、业务流程涉及哪些伙伴和他们扮演的角色、一组Web Service的共同异常处理，以及关于多样参与的其它问题。为了实现这些功能，WS-BPEL引入了活动<Activity>、伙伴<Partner>、伙伴链接<PartnerLinks>、关联集合<Correlation Sets>、变量<Variables>、事件处理<Event Handlers>、错误处理<Fault Handlers>、作用域<Scope>和消息属性等关键元素（如图4所示）。

　　图4 BPEL流程定义

　　流程（Process）由一系列活动<Activity>组成。流程通过伙伴链接<Partner Link>来定义与流程交互的其他服务。服务中可以定义一些变量（Variables，在BPEL4WS中被称为Container）。流程可以是有状态的长时间运行流程（long-running process）。流程引擎可以通过关联集合<Correlation Set>将消息关联到特定的流程实例。

　　图5 BPEL流程的主要组成元素

　　1. Partner和Partner Links

　　在BPEL中，与流程交互的任何实体都被称为伙伴（Partner）。它可以是一个业务伙伴，也可以是一个Web Service，或者是一个内部服务，比如EJB或简单Java类型。Partner也可以是启动流程的一个应用（Application）。由于在流程执行过程中，一个流程可能会调用多个伙伴的服务，又可能接收多个伙伴的请求，因此为了消除在通信过程中的多义性，我们需要明确服务和流程所扮演的角色。

　　合作伙伴链接（PartnerLinks）是流程定义的一部分，可以把它看作一个partner的替代表示符（placeholder）。在BPEL中，这种流程与伙伴的合作关系是通过<partnerLink>元素来定义的。这样，如果在流程的活动中需要指定与特定伙伴的交互，只需要引用partnerLink的名称即可。而且，通过partner links的抽象，在流程建模时，我们不必指定具体的服务端点，而将流程与具体服务的绑定推迟到组装或运行时来完成。

　　partnerLink通过引用partnerLinkType来定义流程与伙伴服务之间的通信接口（实际上是WSDL中的Port Type）。伙伴链接类型声明了两个（或多个）服务之间的关系。服务链接类型定义了一组角色，其中每个角色指明一组Port Type，即明确了该角色所提供的服务接口。partnerLinkType通常被定义在WSDL文档中，被BPEL流程所引用。通常Partner Link Type指定了服务间交互的类型。一个业务流程如果想使用partner link type就必须实现在Partner Link Type中定义的Port Type。引用过程如图6所示。我们定义一个订单服务（Purchase Order），它实现了左边的Port Type。在图5的右侧显示了一个发票服务（Invoice Service）及其相关的Port Type。这两个服务共有一个Partner Link Type定义（图中绿色域），使用这个partner link和其它服务进行通话。

　　图6

　　除此以外，我们所关注的业务伙伴间的长运行流程和有状态交互，都需要使用PartnerLinks来实现。每次当你希望流程从相关服务发送或接受消息，也都需要引用与之相关的partner link。
    
　　2. Variables

　　在BPEL中，我们可以使用变量来保存和传递流程的状态信息。所保存的消息往往是已从伙伴那里接收到的消息或将被发送给伙伴的消息。变量的数据类型由WSDL定义，既可以是XML Schema内置的简单类型，又可以是自定义的复杂数据类型。变量可被指定为Invoke、Receive和Reply等活动的输入变量或输出变量，保存在服务间流动的数据消息。在流程开始的时候，所有的变量都未被初始化，可以通过赋值<Assign>活动或<Receive>活动接收消息来初始化变量。在业务流程执行过程中，一般通过赋值活动来实现数据在不同变量间的流转。变量在BPEL4WS 1.0中被称为容器（Container）。

　　BPEL变量和Java变量的不同在于它们的类型系统。BPEL变量被WSDL消息类型所定义，由此一个变量可以有非常复杂的结构，也可以是一个简单的String类型（如图7所示）。

　　图7

　　3. Correlation Sets

　　Correlation Sets（关联集合）定义了BPEL业务流中各业务交互的相关集，以指定服务实例中相关联的操作组。在业务流程实例的生命期中，它通常与涉及它工作的伙伴进行一次或多次对话。对话可基于成熟的传输基础结构，这种基础结构通过使用某种形式的对话标识使对话中的消息相关，并把它们自动地路由到正确的服务实例而无需在业务流程中注释。但是，在许多情况下，相关对话涉及的参与者不止两个，或使用轻量级传输基础结构（即把相关标记直接嵌套在被交换的应用程序数据中），在这种情况下，常常有必要提供另外的应用程序级机制，以使消息和对话被匹配到预定的业务流程实例。为了处理相关性情况，BPEL提供了声明性机制，以指定服务实例中操作的被相关组。一组相关标记可被定义为被相关的组中被所有消息共享的一组属性。这样的一组属性被称为关联集合。

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

　　在实际应用中，我们必须保证在两个服务间一个长运行交互中交换的每个消息都找到与之相关的相同服务实例。Correlation Sets可以提供这种机制保障，一个Correlation Sets有助于唯一识别一个流程实例，并且将消息关联到特点的流程实例（如图8所示）。

　　图8

　　当定义一个CorrelationSet时，必须声明Correlation Sets、属性和属性别名。与此同时，也需要明确知晓与之相关实例或交互服务的消息的WSDL消息类型。实例如下，消息类型为：

　　newInvoiceMsg是匹配Invoice业务流程的第一个消息，这意味着当消息到达流程时流程仍然不保留数据。事实上，这个消息初始化Invoice业务流程，由此，我们可以将newInvoiceMsg消息关联到Invoice流程。

　　首先，需要识别消息中唯一标识流程的identifier。在上面的例子中，InvoiceNumber就是Invoice流程的唯一标识，因此我们定义一个单一属性：

　　定义属性：InvoiceNumber=xsd:String。这个属性被定义在WSDL文件中。

　　属性定义好后，定义Correlation Set。Correlation Set作为BPEL流程的一个元素。

　　定义Correlation Set：InvoiceKey=InvoiceNumber。

　　最后，需要建立一个newInvoiceMsg和Correlation Set的连接。这个连接定义就是属性别名。

　　属性别名可以看作消息部分和关联属性的一个简单映射。服务间的交互可以进一步细化为图9所示.

　　图9

　
　　4. FaultHandlers

　　活动执行过程中发生异常，业务流程必须对错误进行处理。与Java等语言类似，BPEL提供了异常处理机制。用户可以在业务流程中添加FaultHandlers来捕获并处理相应的异常。FaultHandlers与特定的Scope关联，用于捕获Scope内产生的异常。当异常发生时，BPEL正常执行流结束，控制流转入FaultHandlers内执行。

　　FaultHandlers类似于try-catch结构，它包含多个catch元素，每个都提供活动为特定类型的错误条件进行异常处理。故障会通过接收WSDL定义的故障消息来生成，或者它们可以通过使用throw元素被明确触发。FaultHandlers结构可以由catchAll元素构成（或终止）以提供默认的错误处理活动：
　　
　<faultHandlers>
   <catch faultName=”QName”?
      faultVariable=”BPELVariableName”?
      ( faultMessageType=”QName” | faultElement=”QName” )? >*
      activity
   </catch>
   <catchAll>?
      activity
   </catchAll>
　　</faultHandlers>

　　当异常在特定的Scope内产生时，如果被Scope内定义的FaultHandler捕获，则该Scope状态被置位为Failed。当异常被处理后，外部Scope继续执行。如果异常无法被此Scope内FaultHandler捕获或无FaultHandler定义，则该Scope状态被置为Failed，并且将异常抛出到外部Scope继续处理，直到异常被处理为止。

　　5. Activities

　　BPEL中的活动包括基本活动（Basic activities）和结构化活动（Structured activities）。基本活动负责实现一定的原子功能，如赋值（Assign）、调用Web服务（Invoke）等。结构化活动对控制流逻辑进行编码，利用循环（While）、分支（Pick）等元素对基本活动进行组装整合，以实现系统所需的逻辑功能。

　　每个活动都有两个可选的标准属性：

　　name。name用来提供活动的机器可处理名称。
　　suppressJoinFailure。表示在激活该活动失败时是否报错。
    name=”NCName”?
    suppressJoinFailure=”yes|no”?

　　每个活动都有两个可选的标准元素：<source>和<targets>，这些元素用来建立链接间的同步关系。<source>子元素指的是从该行为有哪些<link>元素被发出，<target>是指该行为被哪些<link>所指向。一个行为内允许有多个<source>和多个<target>元素。这两个子元素可以用standard-elements代替。
　　
　<targets>?
   <joinCondition expressionLanguage=”anyURI”?>?
      bool-expr
   </joinCondition>
   <target linkName=”NCName” />+
</targets>
<sources>?
   <source linkName=”NCName”>+
      <transitionCondition expressionLanguage=”anyURI”?>?
         bool-expr
      </transitionCondition>
   </source>
</sources>

　　（1）基础活动

　　Invoke

　　<invoke>活动被用来调用服务提供者提供的Web Services。调用可以是同步的（请求－响应），也可以是异步的（单向）。Invoke活动使用”partnerLink”来引用伙伴服务，通过”portType”和”operation”指定相应的WSDL接口和操作。以下是请求－响应操作的例子。
　　
　<invoke partnerLink=”NCName”
   portType=”QName”?
   operation=”NCName”
   inputVariable=”BPELVariableName”?
   outputVariable=”BPELVariableName”?
   standard-attributes>
   standard-elements
   <correlations>?
      <correlation set=”NCName” initiate=”yes|join|no”?
         pattern=”request|response|request-response”? />+
   </correlations>
   <catch faultName=”QName”?
      faultVariable=”BPELVariableName”?
      faultMessageType=”QName”?
      faultElement=”QName”?>*
      activity
   </catch>
   <catchAll>?
      activity
   </catchAll>
   <compensationHandler>?
      activity
   </compensationHandler>
   <toParts>?
      <toPart part=”NCName” fromVariable=”BPELVariableName” />+
   </toParts>
   <fromParts>?
      <fromPart part=”NCName” toVariable=”BPELVariableName” />+
   </fromParts>
</invoke>

　　Receive and Reply

　　业务流程通过<receive>活动和相应的<reply>活动把服务提供给它的伙伴。<receive>活动指定了它期望从哪个伙伴那里接收，还指定了它期望伙伴调用的端口类型和操作。<reply>活动被用来发送对先前通过<receive>活动被接受的请求的响应。<receive>和<reply>活动中都通过”partnerLink”来引用预定义伙伴关系，而且需要设置”portType”和”operation”属性来声明流程实现的WSDL portType和操作。实例如下。
　　
<receive partnerLink=”NCName”
   portType=”QName”?
   operation=”NCName”
   variable=”BPELVariableName”?
   createInstance=”yes|no”?
   messageExchange=”NCName”?
   standard-attributes>
   standard-elements
   <correlations>?
      <correlation set=”NCName” initiate=”yes|join|no”? />+
   </correlations>
   <fromParts>?
      <fromPart part=”NCName” toVariable=”BPELVariableName” />+
   </fromParts>
</receive>

　　Assign

　　 <assign>活动用来创建或修改variable内的数据。在业务流程中，经常需要变量variable间复制数据，比如用表达式构造和插入新数据。<assign>还可把endpoint references复制到partnerLinks，或把partnerLinks复制到endpoint references。语法格式如下所示。
　　
　<assign validate=”yes|no”? standard-attributes>
   standard-elements
   (
   <copy keepSrcElementName=”yes|no”? ignoreMissingFromData=”yes|no”?>
      from-spec to-spec
   </copy>
   |
   <extensionAssignOperation>
      assign-element-of-other-namespace
   </extensionAssignOperation>
   )+
</assign>

　　Throw

　　当业务流程需要显式地发出内部故障信号时可以使用<throw>活动。每个故障要有一个全局唯一的QName。<throw>活动必须为故障提供这样的名称，还可以可选地提供数据的变量，该变量提供有关故障的更多信息。故障处理程序可以使用这种数据，以分析和处理该故障，并添加进需要被发送到其它服务的所有故障消息。语法格式如下。
　　
　<throw faultName=”QName” faultVariable=”BPELVariableName”?
   standard-attributes>
   standard-elements
</throw>

　　Wait

　　<wait>活动允许业务流程指定延迟时间的长短或到某个截止期限。实例如下。
　　
<sequence>
   <wait>
      <until>’2002-12-24T18:00+01:00′</until>
   </wait>
   <invoke partnerLink=”CallServer” portType=”AutomaticPhoneCall”
      operation=”TextToSpeech” inputVariable=”seasonalGreeting” />
</sequence>

　　Empty

　　在流程中，有时也会需要使用一些不执行任何任务的活动。比如在故障需要被捕获和取消时，<empty>活动被用于这个目的。<empty>的另一个用途是在一个<flow>中提供同步点。语法如下。
　　
<empty standard-attributes>
   standard-elements
</empty>

　ExtensionActivity
    BPEL流程定义能够包含之前规范未定义的新活动，通过<extensionActivity>声明，这个新活动被作为一个扩展活动。语法如下。
　　
<extensionActivity>
   <anyElementQName standard-attributes>
      standard-elements
   </anyElementQName>
</extensionActivity>

　　Exit

　　<exit>活动被用来立即终止活动实例，但所终止的运行活动不包含termination handling、fault handling或compensation behavior。语法如下。
　　
<exit standard-attributes>
   standard-elements
</exit>

　　Rethrow

　　<rethrow>活动被用在fault handler中重捕获已采集的故障信息，比如故障名、发生位置、故障数据等。它只能在fault handler(<catch>－<catchAll>)内部被使用。对故障数据的更改必须被<rethrow>忽略。例如，如果fault handler中的逻辑修改了故障数据，这时原始的故障数据可以通过调用<rethrow>被重新抛出，被修改的故障数据则是异于原始数据的。语法如下。
　　
　<rethrow standard-attributes>
   standard-elements
　</rethrow>

　　（2）结构化活动

　　结构化活动（Structured activities）规定活动集合中的执行顺序。结构化活动描述了业务流程是如何被创建的。通过组合基础活动，结构化活动用来执行定义的结构，如相关的控制模式、故障和外部事件处理，以及流程实例间消息交换的协调。

　　WS-BPEL定义了几种不同的控制流模式的结构化活动：

　　按顺序执行的有<sequence>、<if>、<while>、<repeatUntil>和<forEach>。

　　表示并发和同步的有<flow>。
　　被外部和内部事件延迟选择控制的，使用<pick>。

　　Sequence

　　 <sqeuence>活动包含一个或多个按顺序执行的活动，执行顺序是这些活动在<sequence>元素中被列出的先后顺序，即词法顺序。当<sequence>中的最后一个活动完成后，该sequence活动也就完成。示例如下。
　　
　<sequence>
   <flow>…</flow>
   <scope>…</scope>
   <pick>…</pick>
　</sequence>

　　If

　　<if>活动提供条件选择。条件分支可以被<if>、<elseif>和<else>元素定义，类似编程语言的if/else语义。语法格式如下。
　　
　<if standard-attributes>
   standard-elements
   <condition expressionLanguage=”anyURI”?>bool-expr</condition>
   activity
   <elseif>*
      <condition expressionLanguage=”anyURI”?>bool-expr</condition>
      activity
   </elseif>
   <else>?
      activity
   </else>
</if>

　　While

　　<while>活动支持指定的迭代活动的重复执行，执行一直继续到指定的布尔条件<condition>为真为止。语法如下。
　　
　<while standard-attributes>
   standard-elements
   <condition expressionLanguage=”anyURI”?>bool-expr</condition>
   activity
　</while>

　　RepeatUntil

　　<repeatUntil>活动支持确定条件活动的重复执行，执行一直继续到指定的布尔条件<condition>为真为止。<repeatUntil>与<while>不同在于<repeatUntil>循环至少执行包含的条件活动一次。语法如下。
　　
　<repeatUntil standard-attributes>
   standard-elements
   activity
   <condition expressionLanguage=”anyURI”?>bool-expr</condition>
　</repeatUntil>

　　Pick

　　<pick>活动会等待一组相互排斥事件中的一个事件发生，然后执行与发生的事件相关联的活动。它会阻塞业务流程执行，以等待某一特定事件发生，比如接收一个合适的消息或超时警报响起。当其中任何一个事件被触发后，业务流程就会继续执行，pick也随即完成，不会再等待其他事件的发生。每个<pick>活动必须至少包括一个onMessage事件。onMessage事件的语义等同于有关变量属性的可选类型的receive活动。pick活动还可以定义onAlarm事件用于指定超时警报。

　　<pick>活动可以作为业务流程的起始点，指定流程可以接收多种不同的消息，并让流程在接收到特定消息后创建新的流程实例来处理消息。这里与<receive>活动类似，我们需要将<pick>活动的createInstance属性设置为”yes”。语法格式如下。
　　
　<pick createInstance=”yes|no”? standard-attributes>
   standard-elements

   <onMessage partnerLink=”NCName”
      portType=”QName”?
      operation=”NCName”
      variable=”BPELVariableName”?
      messageExchange=”NCName”?>+
      <correlations>?
         <correlation set=”NCName” initiate=”yes|join|no”? />+
      </correlations>
      <fromParts>?
         <fromPart part=”NCName” toVariable=”BPELVariableName” />+
      </fromParts>
      activity
   </onMessage>
   <onAlarm>*
      (
      <for expressionLanguage=”anyURI”?>duration-expr</for>
      |
      <until expressionLanguage=”anyURI”?>deadline-expr</until>
      )
      activity
   </onAlarm>
</pick>

　　Flow

　　<flow>活动提供并发性和同步性。<flow>能进一步表达直接或间接嵌套在其中的活动之间的同步相关性，link用来表达这种同步相关性。

　　<flow>活动出现的所有link必须在<flow>活动中分开定义，并通过名称进行标识。<flow>活动中嵌套的活动需要通过source或target属性来标明该活动为哪个链接的源或目标活动。在<flow>活动中，对于每一个link必须有且仅有一个活动作为它的源活动，同样有且仅有一个活动作为它的目标活动。目标活动会在源活动完成之后执行。这样<flow>内部的活动就可以通过活动构成一个有向图。语法格式如下。
　　
　<flow standard-attributes>
   standard-elements
   <links>?
      <link name=”NCName”>+
   </links>
   activity+
</flow>

　　ForEach

　　<forEach>活动执行它包含的<scope>活动N+1次，N等于<finalCounterValue>减去<startCounterValue>的差值。语法格式如下。
　　
<forEach counterName=”BPELVariableName” parallel=”yes|no”
   standard-attributes>
   standard-elements
   <startCounterValue expressionLanguage=”anyURI”?>
      unsigned-integer-expression
   </startCounterValue>
   <finalCounterValue expressionLanguage=”anyURI”?>
      unsigned-integer-expression
   </finalCounterValue>
   <completionCondition>?
      <branches expressionLanguage=”anyURI”?
         successfulBranchesOnly=”yes|no”?>?
         unsigned-integer-expression
      </branches>
   </completionCondition>
   <scope …>…</scope>
</forEach>

　　6. Scopes

　　<scope>（作用域）提供影响其所包含活动的执行特性的上下文定义。这些上下文可以声明variables、partner links、message exchanges、correlation sets、event handlers、fault handlers、compensation handler和termination handler。当”root”的内容由<process>构造所提供时，上下文能够被嵌套分层。

　　尽管<process>和<scope>元素共享语法结构，有着相同的语义，但有如下不同：

　　<process>结构不是一个活动；因此<scope>的标准属性和元素不适用于<process>结构；
　　<process>结构中不包含compensation handler和termination handler；
　　isolated attribute（隔离属性）不适用于<process>结构。

　　每个<scope>都有一个定义了正常行为的主活动（primary activity）。这个主活动可以是一个有着任意深度的多嵌套结构的复杂活动。语法结构如下。
　　
　<scope isolated=”yes|no”? exitOnStandardFault=”yes|no”?
   standard-attributes>
   standard-elements
   <variables>?
      …
   </variables>
   <partnerLinks>?
      …
   </partnerLinks>
   <messageExchanges>?
      …
   </messageExchanges>
   <correlationSets>?
      …
   </correlationSets>
   <eventHandlers>?
      …
   </eventHandlers>
   <faultHandlers>?
      …
   </faultHandlers>
   <compensationHandler>?
      …
   </compensationHandler>
   <terminationHandler>?
      …
   </terminationHandler>
   activity
</scope>

　　BPEL还扩展了作用域的功能，具体体现在如下几个方面。

　　错误处理（Fault Handlers）

　　当一个行为出错的时候，会抛出一个错误消息。该消息首先会被自身的错误处理器所处理，<faultHandlers>与特定的<scope>关联，用于捕获<scope>内产生的异常。当异常发生时，BPEL正常执行流结束，控制流转入<faultHandlers>内执行。

　　<faultHandlers>类似于try-cache结构，它包含多个catch元素，每个都提供活动为特定类型的错误条件进行异常处理。故障会通过接收WSDL定义的故障消息来生成，或者它们可以通过使用throw元素被明确触发。<faultHandlers>结构可以由catchAll元素构成（或终止）以提供默认的错误处理活动。

　　事件处理（Event Handlers）

　　BPEL中定义了两类事件，一类是“消息事件”，即从外部传来的消息；另一类是由于达到用户定义的时间点而发出的警告。事件处理机制从作用域的一开始就激活，一直等待事件的到来而执行内部行为，也会随着作用域的结束而结束。

　　补偿处理（Compensation Handlers）

　　补偿处理是为了将流程的状态回滚，回到与进入作用域前一样。所需要做的就是将该作用域内已执行部分采用其他行为进行撤销，通常是调用一个效果相反的服务。（注：由于本文的篇幅限制补偿专题涉及内容不在此累述，请参考WS-BPEL2.0规范相关内容。）
　　
　　7. WS-BPEL Abstract Process

　　对Web Services来说，一个流程服务平台要能为服务通讯建模，同时还要克服WSDL“无状态”的天生缺陷，提供点对点的消息交互、支持同步和异步通信、支持状态的持久化、长运行流程，及支持多成员同时参与的模型。在BPEL中，服务相互之间进行消息通信，是为了公布自己的信息、获得其它成员的信息并调用其它服务，这些可以用“抽象流程”的概念来概括。抽象流程指定服务双方交互的消息交换序列，不公开服务内部行为；可执行流程是指可执行业务双方的实际交互。抽象流程隐藏了内部细节和复杂性，简单而易于理解，这使得通过改良抽象业务流程而得到完全可执行的复杂业务流程成为可能。BPEL支持使用抽象流程来描述业务抽象接口的功能，使得服务的动态绑定成为可能。在BPEL中，描述抽象流程的语言是用于描述可执行流程的语言的子集，从而可以在同一种流程语言中指定可执行流程及其抽象视图。

　　至此，已经基本介绍了WS-BPEL2.0的基础语法构造。鉴于篇幅限制，无法在本文中具体展开BPEL语言的每个细节，请参考OASIS的WS-BPEL2.0的规范和相关文档。

　　BPEL带来的好处

　　介绍了WS-BPEL的特性后，我们概括一下BEPL所带来的好处。

　　首先，BPEL是一种表示业务流程的工业标准语言，构建在开放的、基于标准的技术之上，通过组合消息传递、标准化的集成接口、XML及各种Web services标准来提供流程间的互操作性及流程可控性。同时，对于异步的长运行流程提供隐式和显示的补偿事务模型，具备良好的跨平台能力、移植性和厂商无关性。必须肯定的是，作为一种新技术，BPEL也有自身的缺陷和不足。但随着标准的不断完善和改进，WS-BPEL 2.0在很多领域有了大的进展，譬如安全等专业性能方面，支持XSLT用于可变数据的转换，支持XPath对可变数据的访问，定义了跨组织的纲领性流程，提供了许多新的构建服务的方法，提升了服务聚合效率。尤其是WS-BPEL作为第一个赢得多数厂商支持的标准化业务过程语言，已经有了许多成功的使用和产品。
　　
　　BPEL的合理使用

　　由于BPEL的技术要求、部署的复杂性和使用成本，在SOA项目中我们需要合理把握BPEL使用的度，避免BPEL被滥用。

　　我们必须遵循几个关键的SOA设计原则：

　　服务组件间是松耦合的
　　服务要保持适当的粒度级别
　　服务是虚拟的、可重用的
　　服务必须是可管控的，包括运营和维护

　　然后，我们还需要从以下几个方面考虑BPEL的使用成本，包括开发成本、性能、技能需求、运营维护、管控成本和最终的ROI。

　　对于流程的合理构建和使用详情，有兴趣的话请参考相关的BPEL Anti Patterns。
　　
　　WS-BPEL在IBM产品中的实现

　　我们来看一下IBM业务流程开发生命周期中涉及业务流程相关的软件产品（如图10所示）。

　　图10

　　IBM WebSphere Business Modeler——提供一种方法，通过公司最佳实践定义和修改模型，更好地了解部门之间如何交互操作，定义个人在企业内部承担的角色和职责。Business Modeler有助于自顶向下分析业务流程。
　　IBM WebSphere Integration Developer——用于基于图形的BPEL业务模型的组装、编排的开发工具。
　　IBM WebSphere Process Server——允许业务规则捕捉业务变量，针对不断变化的业务状况和市场状况提供灵活性和快速反应能力。确保用WebSphere Business Modeler或WebSphere Integration Developer设计的流程可以一致、可靠、安全地执行，具备事务完整性。建立在WebSphere ESB之上，并具备其功能。
　　IBM WebSphere Business Monitor——允许实时监视业务流程，采用可视化方法显示业务流程状态。WebSphere Business Monitor提醒并通知重要用户持续改进业务流程。此产品大大增强了IBM业务流程管理软件包，与WebSphere Business Modeler和WebSphere Process Server紧密集成在一起。

　　WebSphere Business Monitor有助制定并跟踪常见的业务监测目标：使用记分卡视图，对照目标或关键绩效指标测量业务性能；通知主要用户需要对哪些重要业务采取措施；就异常情况发出通知；跟踪业务流程；监视工作持续时间和过去时间等业务流程指标。

　　WebSphere Business Modeler和WebSphere Integration Developer（简称WID）用做业务流程的建模、仿真、组装、编排和测试。

　　流程在WebSphere Process Server（简称WPS）中执行。最后，通过WebSphere Business Monitor来监控流程的运行状况。

　　总结与展望

　　本文着重分析和讨论了Web服务组合WS-BPEL 2.0的功能和体系结构，分析了BPEL业务执行语言的优点和适用情况，最后介绍了BPEL在IBM软件产品中的应用情况。

　　Web服务的组合是当前SOA中发展非常迅速的技术之一，也是讨论和争议非常激烈的技术。当前很多规范和新技术还处在发展和开拓期，包括WS-BEPL 2.0也是新兴的、不断发展中的技术，在很多方面还存在不完善，需要进一步深化和改进。但是我们有理由相信，在业界广泛支持和推动的基础上，WS-BPEL一定会取得更大的发展和革新，让我们拭目以待。