BPEL4WS 允许定义使用 Web 服务的业务流程，也允许定义把业务流程的功能具体化为 Web 服务的业务流程。这篇短文使用一个简单的示例来介绍 BPEL4WS 的基本语言元素。此外还将简要说明语言中的概念：建立双边伙伴关系、使消息和流程关联、定义业务流程的活动的顺序、处理长期运行的事务的异常。我们还要介绍 BPEL4WS 所导致的编程模型以及在纯粹的 B2B 情景中 BPEL4WS 的使用。

介绍
Web 服务是独立的模块化的业务流程应用程序，它基于这些行业标准技术：（用于描述的）WSDL、（用于做广告和联合的）UDDI 以及（用于通信的）SOAP。（请参阅后面的参考资料部分，其中有一些链接）。它们使用户能够以平台独立和语言独立的方式连接不同的组件，在连接时甚至可以跨越组织边界。

但是，这些标准都不能定义 Web 服务的业务语义。所以，目前的 Web 服务是孤立的不透明的。打破孤立就是要把 Web 服务连接起来并指定怎样共同使用一组组 Web 服务来实现更复杂的功能 — 业务流程就是一个典型的例子。

业务流程指定了一组 Web 服务的操作的可能执行顺序、这些 Web 服务间共享的数据、业务流程涉及哪些伙伴以及这些伙伴在业务流程中扮演什么角色、一组组 Web 服务的共同异常处理以及关于多个服务和组织是怎样参与的其它问题。特别是它允许指定 Web 服务间长期运行的事务，提高 Web 服务应用程序的一致性和可靠性。打破 Web 服务的不透明性就是要指定一些约束，这些约束将限制怎样使用一组 Web 服务的操作和它们共同的行为 — 其结果是这和指定业务流程也很相似。

Web 服务的业务流程执行语言（Business Process Execution Language For Web Services，缩写为 BPEL4WS 或 BPEL；请参阅参考资料中的一个链接）允许指定业务流程以及它们和 Web 服务的关系。其中指定了业务流程是怎样使用 Web 服务来达到它的目的，还指定了由业务流程提供的 Web 服务。用 BPEL 指定的业务流程是完全可执行的，且在符合 BPEL 的环境间是可移植的。无论实现 BPEL 业务流程的伙伴的 Web 服务是否基于 BPEL，BPEL 业务流程都能和这些 Web 服务互操作。最后，BPEL 支持伙伴之间的业务协议规范和复杂内部业务流程的视图。

BPEL 结合了 IBM 的 Web 服务流程语言（Web Services Flow Language）和 Microsoft 的 XLANG 规范（请参阅参考资料，其中有这两个规范的链接）并取代了这两个规范。本文简要介绍 BPEL 的主要概念。

初识 BPEL
为了了解 BPEL 是怎样工作的，下面我们来看一个简单的流程情景。在这个应用中，一个旅行社需得到客户的旅程，到航空公司购买机票，再把机票亲手递给客户。

清单 1 包含一个显示 BPEL 基本元素的简化示例。图 1 显示了这个业务流程中的活动的流程图。旅行代理人指定了一个叫 ticketOrder（第 1 行）的业务流程。这个简单的业务流程的目的在于让代理人从客户那里拿到旅程（第 20 至 23 行），再把这个旅程传递给航空公司并要求购买相应的机票（第 26 和 29 行），最后从航空公司接收这些机票（第 33 至 36 行）。为了使这个示例简单点，我们假定客户将亲自来拿机票。

图 1：业务流程中的活动的流程图

第 2 至 10 行定义了和代理人的流程交互的伙伴集：第 3 至 5 行引入了伙伴 customer（客户），第 6 至 9 行引入了伙伴 airline（航空公司）。伙伴的定义包括指定分别被伙伴或流程互相使用的 Web 服务（欲知详情，请看下一节“伙伴”）。

由流程保持其持久性的消息名叫 containers（第 11 至 14 行）。容器是发送给伙伴或从伙伴那里接收到的 WSDL 消息（欲知详情，请参阅标题为“容器、属性和相关性”的一节）。例如，流程把 itineraryMessage 存储为 itinerary 容器。当客户使用代理人的旅程端口的 sendItinerary 操作时（第 21 至 22 行），从 customer 那里接收到 itineraryMessage（第 20 行）。当这个消息被接收到后被存储在 itinerary 容器（第 23 行）。 接着该流程通过使用 ticketOrder 端口的 requestTicketairline 操作（第 27 至 28 行）把 itinerar 消息传给 airline（第 26 行）；这个消息是 itinerary container 的副本（第 29 行）。

在业务流程中操作的使用被称为活动（欲知详情，请参阅标题为“活动”的一节）。为了定义必须以怎样的顺序执行活动，ticketOrder 流程把它的活动组成一个 flow（第 15 行）。flow 是一个有向图，活动被表示为节点，所谓的 links 被表示为连接活动的边。第 16 至 19 行指定了定义 ticketOrder 流程的活动之间的流程所需要的 links。活动指定了 links 的源（source）或目标（target）。例如，第 20 行的 receive 活动是 order-to-airline link 的 source（第 24 行）。而这个 link 把第 26 行的 invoke 活动作为 target（第 30 行）。

 1 <process name="ticketOrder">

 

 2   <partners>

 3      <partner name="customer" 

 4              serviceLinkType="agentLink"

 5              myRole="agentService"/>

 6      <partner name="airline" 

 7              serviceLinkType="buyerLink"

 8              myRole="ticketRequester"

 9              partnerRole="ticketService"/>

10   </partners>



11   <containers>

12     <container name="itinerary" messageType="itineraryMessage"/>

13     <container name="tickets" messageType="ticketsMessage"/>

14   </containers>



15   <flow>

16      <links>

17         <link name="order-to-airline"/>

18         <link name="airline-to-agent"/>

19      </links>



20      <receive partner="customer" 

21               portType="itineraryPT" 

22               operation="sendItinerary" 

23               container="itinerary" 

24           <source linkName"order-to-airline"/>

25      </receive>



26      <invoke  partner="airline" 

27               portType="ticketOrderPT" 

28               operation="requestTickets"

29               inputContainer="itinerary" 

30           <target linkName"order-to-airline"/>

31           <source linkName"airline-to-agent"/>

32      </invoke>



33      <receive  partner="airline" 

34               portType="itineraryPT" 

35               operation="sendTickets"

36               container="tickets" 

37           <target linkName"airline-to-agent"/>

38      </receive>

39   </flow>



40 </process>

伙伴
涉及 Web 服务的业务流程常常要和不同的伙伴交互。伙伴通过被称为服务链接类型（service link type）的双边方式被连接到流程。服务链接类型指定了两组由两个连接的伙伴互相提供和要求的 Web 服务。这一组组 Web 服务被称为角色（role）。清单 2 中有一个服务链接类型定义的示例。

1 <serviceLinkType name="buyerLink">

2   <role name="ticketRequester">

3     <portType name="itineraryPT"/>

4   </role>

5   <role name="ticketService">

6     <portType name="ticketOrderPT"/>

7   </role>

8 </serviceLinkType>

服务链接类型 buyerLink 由两个角色组成。角色 ticketRequester（第 2 至 4 行）提供端口类型 itineraryPT（第 3 行），角色 ticketService（第 5 至 7 行）提供端口类型 ticketOrderPT（第 6 行）。端口类型本身被定义在其它地方。

在业务流程中定义伙伴时将引用服务链接类型，这个服务链接类型位于相应的流程和伙伴间的双边关系之下（清单 1 中的第 4 行和第 7 行）。例如，清单 1 中的 airline 伙伴引用定义在这节中的 buyerLink。伙伴定义进一步指定流程本身接受下层服务链接类型的哪个角色（myRole）以及伙伴必须接受哪个角色（partnerRole）。接受角色意味着承担提供相应的 Web 服务的责任 — 也就是说，提供角色的端口类型的实现。partnerRole 属性能引用流程期望从伙伴那里得到的 Web 服务（例如清单 1 中的第 9 行），myRole 属性能引用流程提供的且伙伴可以依赖和使用的 Web 服务（例如清单 1 中的第 8 行）。

通过 myRole 构造，流程定义了对外部世界代表 Web 服务本身的 Web 服务集。partnerRole 构造允许指定业务流程对外界提供的 Web 服务的依赖性 — 也就是说，业务流程要求的并将使用的 Web 服务。

容器、属性和相关性
通过 BPEL 指定的业务流程规定了 Web 服务之间的消息交换。这些消息是端口类型的操作的 WSDL 消息，这些端口类型参与了流程和它的伙伴间建立的服务链接的角色。某些交换的消息可被包括在业务流程的所谓的业务上下文中；该上下文是一组 WSDL 消息，被称为容器，它表示的数据对正确执行业务流程很重要，例如，作出路由决定，构造将被发送的消息。

例如，清单 1 的第 23 行指定通过流程的 itineraryPT 端口的 sendItinerary 操作从 customer 那里接收的消息必须被复制到 itinerary 容器中。第 29 行指定作为 requestTickets 操作的输入被发送到 airline 的 ticketOrderPT 端口的消息来自于 itinerary 容器。

为了避免业务上下文的丢失，业务上下文常常必须被持久地存储，从而确保即使遇上计划的或意外的系统失败，业务流程也能正确执行。因为这种失败的可能性随着业务流程的运行时间的增加而增加，而且业务流程通常运行很长时间，所以比较好的作法是使上下文持久。

当消息在业务伙伴间交换时，它们通常携带用来使消息与合适的业务流程相关起来的一些数据。例如，ticketsMessage 所携带的 orderNumber 可被旅行代理人和航空公司用来识别所买的机票是针对哪个客户提交的路线。在 BPEL 中，这种相关性数据被称为属性。相同的属性常常被用于不同消息中，作为用于相关性的数据。为了这个目的，BPEL 支持把属性定义为分开的实体。以下代码把 orderNumber 定义为属性：

9 <property name="orderNumber" type="xsd:int"/>

由于属性被不同的消息用来定义相关性数据，所以需要一种机制来允许指向表示这个属性的消息的专用字段。在 BPEL 中，这种机制被称为别名（aliasing）。清单 3 显示了怎样把 orderNumber 属性（第 10 行）定义为 ticketsMessage 的 orderInfo 部件的 orderID 字段。

10 <propertyAlias propertyName="orderNumber" 

11                messageType="ticketsMessage"

12                part="orderInfo"

13                query="/orderID"/>

活动
活动（activity）是业务流程中被执行的操作。在我们的第一个示例中，您已看到了一些业务流程中可以使用的活动。

业务流程中的一个重要操作是等待从伙伴那里接收到消息。这种操作是通过 <receive> 活动来指定。它指定了消息是从哪个伙伴那里接收到的，还指定了被伙伴用来传递消息的流程所提供的端口和操作（下面的清单 4 中的第 14 至 16 行）。

一个更强大的机制是 <pick> 活动的使用。这种活动指定了所有可从相同或不同的伙伴那里接收的消息。当指定的消息之一被接收到后，<pick> 活动就完成了，业务流程的处理将继续进行。此外，您可以指定如果在给定的时间内没接收到消息，那么处理将继续进行。

业务流程的启动活动必须是 <receive> 或 <pick> 活动。若把它们标志为 createInstance="yes"（清单 4 中的第 18 至 23 行），则表示应该创建指定的业务流程的实例（如果还不存在）。清单 4 阐明了这种行为，所用的示例是需要接受来自不同伙伴的请求的业务流程。消息到达的顺序并不清楚。

14 <receive partner="hotel", 

15          portType="roomPT",

16          operation="sendBooking",

17          container="stayInfo"

18          createInstance="yes"/>

19

20 <receive partner="rentalCar",

21         portType="carPT",

22         operation="sendBooking",

23         container="rentalInfo"

24         createInstance="yes"/>

无论哪个消息最先到达都将创建一个流程实例。在初始消息收到后，业务流程等待第二个消息。例如，如果第一个消息是来自 hotel 伙伴，那么流程实例被创建，然后业务流程等待来自 rentalCar 伙伴的消息的到达。

有了这种方法就不需要显式的生命周期命令（例如创建流程实例的命令）。由于没有显式的生命周期命令，对于请求代表业务流程的 Web 服务的请求者来说，就轻松了很多：无需知道流程实例是否已被创建。结果，请求者可以和代表业务流程的 Web 服务进行交互，就象与任何其它 Web 服务进行交互一样。

清单 1 中的第一个示例没有向客户返回响应；但是在多数实际情况下必须返回响应。如清单 5 所示，<reply> 活动被用来指定对相应的 <receive> 活动的请求的同步响应。

25 <receive partner="customer", 

26          portType="itineraryPT",

27          operation="sendItinerary",

28          container="itinerary"

29          createInstance="yes"/>

30

31 <reply   partner="customer",

32          portType="travelPT",

33          operation="sendTickets",

34          container="tickets"/>

在清单 5 中，该流程提供了一个进出操作：该操作的输入消息被 <receive> 活动所消费，该操作的输出消息是通过 <reply> 活动来产生的。

如果对原始请求的响应被异步地发送，那么将通过请求者提供的 Web 服务的调用来传递响应。因此，<invoke> 活动被用于产生异步响应的流程中。原始请求者将使用 <receive> 活动来消费由 <invoke> 活动传递的响应。

此外，<invoke> 活动可被用于流程中，以同步调用由伙伴提供的 Web 服务的进出操作。

以上讨论的所有活动（除了 <pick>）都被称为简单活动（simple activity），这表示它们没有结构且不能包括其它活动。其它简单活动有：<wait>，它表示业务流程应该等待指定的时间周期或等到指定的时刻已过去；<empty>，它不和任何操作关联，它被用来指定不做任何事或在流程中使并行处理同步；<terminate>，它表示业务流程应该立即被终止；<throw>，它发出发生错误的信号；<assign>，它把容器的字段复制到其它容器中；<compensate>，它能撤销已完成的活动的效果（请参阅下面一节，其标题是“故障处理”）。

清单 1 中的第一个示例演示了 <flow> 的使用，flow 是两个最重要的结构化的活动之一。它允许定义可通过 link 串起来的活动集（包括其它 flow 活动），使 flow 的各部分的并行执行成为可能。每个 link 可与一个转变条件相关联，这个条件是使用流程的不同容器中的值的布尔表达式。当业务流程被执行时，如果关联的转变条件被判断为真的，那么将使用某个链接。

另一个重要的结构化的活动是 <scope>，它允许构建一组组活动（被称为 作用域（scope））并把某些特征分配给这组活动。其中一个是故障处理程序概念，当错误在作用域中发生时，故障处理程序自动地被调用；另一个是补偿处理程序概念，补偿处理程序可以撤销在作用域中作出的更改（请参阅“故障处理”）。

其它结构化的活动有：<sequence>，它使所包括的活动按它们被列出的顺序被执行；<switch>，它从多条路径中选择一条路径，选择的方法是使用引用容器中的值的选择条件；<while>，它使所包括的活动被执行，只要与 while 活动有关的条件被判断为真的。

故障处理
BPEL 流程和 WSDL 端口交互，这些端口可能向流程发回故障消息。此外，流程本身可能检测到导致内部故障的错误状况。BPEL 提供了一些机制，用于支持从这种故障状况恢复过来的尝试。

这些机制的核心是所谓的故障处理程序（fault handler），故障处理程序可以捕获并处理故障。在下面的清单 6 中，故障处理程序通过相应的一组 <catch> 元素（第 36 行）定义了它试图处理的故障集。在这个元素中，任何种类的活动（简单的或结构化的）可以被嵌套。当相应的故障发生时将进行这个活动。在清单 6 中，故障处理程序能捕获航空公司伙伴返回的 noSeatsAvailable 故障。当这种故障发生时，相应的拒绝消息通过嵌套的 <invoke> 活动（第 37 至 40 行）被发送给客户。

35 <faultHandlers>

36    <catch  faultName="noSeatsAvailable">

37       <invoke  partner="customer"

38                portType="travelPT" 

39                operation="sendRejection"

40                inputContainer="rejection"/>

41    </catch>

42 </faultHandlers>

在通常情况下，对异常状况（例如故障）的反应取决于流程的实际进展情况或流程所处的状态。在 BPEL 中，这可以通过所谓的作用域（scope）来指定。作用域是允许活动分组的结构化的活动（请参阅前面一节，标题是“活动”）。此外，它允许为相应的一组活动定义公共的执行上下文，例如，当包括在作用域中的活动之一在进行时能捕获故障的故障处理程序。

当故障在作用域中发生时，作用域中的正常处理被中断，发出的故障被传给捕获故障的处理程序。嵌套在这个故障处理程序中的活动试图纠正这种状况，以使正常处理可在作用域外继续或使用其它方法来完成流程。

所有这些可能需要撤销在作用域中已完成的操作。例如，如果无法获得旅行所需的机票，那么就必须取消已经完成的对宾馆房间或租用汽车的预定。撤销已完成活动的所需操作被称为补偿处理程序（compensation handler）。作用域的故障处理程序可能使用补偿处理程序来撤销这个作用域中进行的操作。如果异常状况无法被纠正，故障处理程序将再次抛出这个故障或发出发生另一故障的信号，这些故障将最终被包括这个作用域的另一个作用域的故障处理程序所捕获。

所以，通过作用域机制，BPEL 允许定义可在错误情况下一起被撤销的活动集。这样的活动集是一些工作单元和一些事务。在作用域中进行的活动要么已全部完成，要么全部被补偿。与之形成对比的是，众所周知的传统事务（例如数据库事务）是基于锁实现的，在事务的持续时间里把资源分配给某个事务。这种实现假定事务是短期的工作单元，所以锁可以很快被释放。因为在通常情况下，BPEL 的作用域是长期运行的，所以在实际应用中锁定资源是不可行的；您不得不改用补偿操作。它允许在包括的活动完成后释放锁，但您必须运行补偿逻辑来撤销已完成的操作。所导致的工作单元（或者说事务）被称为长期运行的事务。

BPEL 中的长期运行的事务被集中在作用域上而作用域是可嵌套的。在作用域和它的父作用域之间有一个同意协议（agreement protocol），可用于确定作用域所代表的长期运行的事务的结果。WS-Transaction 中已描述了相应的协议。目前的 BPEL 长期运行的事务假定作用域和它所嵌套的所有作用域被包含在单个流程中并由单个 BPEL 引擎来管理，但是 WS-Transaction 中的同意协议并没有作这个假定。所以，未来的 BPEL 扩展可能支持分布于流程间甚至跨 BPEL 引擎的长期运行的事务。

WS-Transaction 还指定了用于协调分布式原子事务的协议。未来的 BPEL 扩展可能支持由单个流程或多个不同流程的活动所组成的分布式原子事务。

图 2 概括了涉及的标准间的一般关系。BPEL 是 WSDL 上的一层 — 也就是说，它使用 WSDL 来指定应该在业务流程中进行的操作并描述业务流程提供的 Web 服务。WS-Transaction 指定的协议可用于 BPEL 中定义的长期运行的事务模型和一般的 Web 服务间的原子事务。

图 2. 所讨论的标准间的关系

基于流程的应用程序
用 BPEL 创建的应用程序被称为基于流程的应用程序（请参阅参考资料中的一个相关链接）。这种应用程序结构把应用程序分割成严格分开的两层：上层的业务流程是用 BPEL 编写的，它表示应用程序的流程逻辑；下层的 Web 服务表示应用程序的功能逻辑。

和传统的方法相比，这种结构有几个优点。首先，在修改下层的业务流程和调用的 Web 服务时不会影响应用程序中的其它 Web 服务或业务流程所代表的 Web 服务。此外，应用程序的开发和测试可分为两个阶段：业务流程的开发和测试与个别 Web 服务的开发和测试是分开的。在修改应用程序时，这种方法提供了很大的灵活性。

和传统的方法相比，用 BPEL 编写的应用程序的另一重要优点是它们允许以不触及应用程序本身的方式调整已就绪的应用程序，以适应某个环境的需要和情况。实现的方法是把业务流程处理的伙伴的定义和实际涉及的伙伴的特征分开。在 BPEL 中，您仅指定不同伙伴将提供的端口类型和操作。

当这样的业务流程在执行时，需要有所选的具体伙伴提供的实际端口和 Web 服务的信息。在 BPEL 中，关于 Web 服务或端口的信息被一起包含在服务引用（service reference）这个概念中。在 BPEL 中，为不同伙伴提供服务引用的具体机制被有意排除在规范外（除了几个异常）。其中一个异常处理请求者为提供者提供它自己的服务引用时的情况，以使提供者可以响应请求者。

提供服务引用的典型方法是在业务流程以部署描述符的形式被安装（或部署）的时候提供这些信息。把服务引用分配给伙伴的方法有许多种。最简单的方法是把包含固定信息的服务引用分配给伙伴。在业务流程被执行时，这个固定服务引用可用来调用 Web 服务。在最复杂的情况下，部署信息可以只是指向某种机制；在业务流程在被执行时，这种机制可确定合适的服务引用，也可能马上调用所选择的 Web 服务。例如，这种机制可访问 UDDI，获取潜在的服务供应商的所有详细信息，然后根据这些信息选择最合适的服务供应商。

基于 BPEL 创建的应用程序在支持 BPEL 和 Web 服务的环境间是可移植的：任何 BPEL 引擎可以执行 BPEL 流程，在执行期间，BPEL 引擎将根据部署信息和所发现的 Web 服务交互。

业务协议
BPEL 并不是只能用来指定可执行流程；您还可以用它来指定业务协议。业务协议指定了某一个伙伴为了达到业务目的和它的其它伙伴交换消息的可能的顺序。换句话说，业务协议根据实际业务上下文定义了某个伙伴发送消息和等待它的伙伴的消息的顺序。RosettaNet PIP 就是业务协议的一个示例（请参阅参考资料中的一个链接）。

一般来说，在内部业务流程中进行活动导致消息的交换。所以，业务协议可被看作私有业务流程的视图；在这个视图中，内部详细信息（例如对后端系统的访问、组成上下文的消息的完整结构、复杂数据处理步骤、决定分支选择的业务规则等）被省略。

在 BPEL 中，指定业务协议的语言是用于指定可执行流程的语言的子集。这使得您可以在同一种语言中指定内部可执行流程以及它的视图。它支持从视图开始并把它扩展到内部流程的由外到里的过程，也支持从内部流程投影到它的视图的由里向外的过程。

一般地说，业务协议（或视图）是不可执行的。例如，组成上下文的消息可以是真正的内部上下文消息的简单投影；可能没有完全指定被发送到伙伴的消息是怎样构造的，组成业务协议的可见的上下文的数据并没有准确地定义分支条件。这是由于业务协议有意隐藏内部细节和复杂性。

由于业务协议可能是既不可执行也不确定但仍可表示为一个流程，所以 BPEL 把它称之为抽象流程。它去掉了内部可执行流程的复杂细节。在这个意义上，抽象流程可被看作是简单的或易于理解的流程。虽然不能保证抽象流程是可执行的，但是可以以某种方式容易地指定抽象流程以至于它实际上是可执行的！这使得您可以从流程的简单变体开始，反复地改良它们，使它们最终成为复杂的业务流程。

最后，抽象流程可用来容易地指定对一组端口类型的使用形式的约束。被约束的端口类型是由抽象流程提供的端口类型，被约束的操作是用在抽象流程的活动中。

总结
BPEL 支持各种业务流程的指定，从使用较简单的业务协议的完全可执行的复杂业务流程到 Web 服务的使用约束。它提供的长期运行的事务的模型提高了 Web 服务应用程序的一致性和可靠性。它支持的相关性机制可以根据业务属性来识别业务流程的多状态实例。伙伴和 Web 服务可依据服务引用被动态绑定。

参考资料

• 请单击文章顶部或底部的讨论参加关于本文的讨论论坛。
• 请访问 W3C 的 WSDL 页面。
• 在 UDDI.org 站点，您可以找到关于 UDDI 的更多信息。
• W3C 还有关于 SOAP 的信息。
• 请看 BPEL4WS 规范。
• IBM 还有关于 WSFL 的更多信息（PDF 格式）。
• 请参阅关于 XLANG 的更多信息。
• 如果您想了解有关基于流程的应用程序的更多信息，请参阅“Workflow-Based Applications”，作者是 F. Leymann 和 D. Roller（IBM Systems Journal，1997 年）。
• 您可以到 RosettaNet 的 Web 站点找到关于 RosettaNet PIP 的更多信息。