对于想使用 Web 服务来集成他们所在的企业与其伙伴之间的业务流程的 IT 设计师和业务分析师来说，日子只是好过了一点点。在这个系列的第一篇文章中，我提到过“随着业界进一步开发决定如何协调 Web 服务间的流以及如何描述实现业务流程的 Web 服务间相关性的规范，对异步操作的支持将被简化。”那么，猜一下刚刚发生了什么事？8 月 9 日，IBM、Microsoft 和 BEA 发布了共同开发的一组用于向 Web 服务添加业务语义的规范。这三个规范被发布到了整个业界以进行进一步的开发，同时发布的还有一些逐条列出要满足的各项额外功能的计划，这些计划的目的是启动满足一组非常重要的客户流程和事务要求所需的标准化过程。这些规范是 Web 服务的业务流程执行语言（BPEL4WS 或 BPEL）、Web 服务协调（WS-Coordination 或 WS-C）和 Web 服务事务（WS-Transaction 或 WS-T）。这三个规范确实能使企业用一个全面的模型来描述他们的业务流程，并且还提供了一个用来执行该模型、协调业务活动和事务行为的实现框架。本文将概述一下 BPEL、WS-C 和 WS-T 规范如何简化对异步操作的支持。更重要的是，您还将了解这些规范如何描述和实现这样的企业业务交互，这些业务交互通常在涉及到两方或更多方的、长时间运行的有状态交互中进行一系列点对点消息交换的企业业务交互。

在本系列前面的文章中，我介绍了异步 Web 服务操作的一些概念，同时还介绍了用来实现双方之间各个异步操作的各种集成模式。这些模式本质上是被建模为无状态的、独立的交互。在这些模式中，我提出了参与应用程序或消息传递传输在将请求映射到响应时要创建和管理相关器的要求。同样，解决方案设计者也需要提供一种方法，通过这种方法把 回复地址（reply-to address）（响应将被发送到这个地址）提供给服务提供者；这样，当响应可用时，就可以在分开的执行线程上把它们发送到请求客户机。所有这些要求，以及其他更为重要的要求（比如协调一组有状态交互和将请求路由到有状态流程实例等要求）都将在新规范中得到满足。于是，我们就可以在 业务流程引擎（business process engine）内对复杂的、实际的企业流程进行建模和直接执行（更多时候是在引擎上立即执行）。

目前，Web 服务描述语言（Web Services Description Language，WSDL）规范的版本 1.1 自身（不包括扩展）只支持无状态的交互模型，按这种模型在两方之间交换同步消息或相互之间无关联的异步消息。这三个新规范的发布使得这样的企业业务流程有可能得到支持，这些企业业务流程要求涉及到在两方或更多方之间的有状态且长时间运行的交互中进行的点对点消息交换序列（同步的和异步的）的交互模型。

在进一步学习本文之前，您应该对 BPEL、WS-C 和 WS-T 规范有一个基本的理解，因为我们将在这里探讨来自这些规范的许多概念。在下面的 参考资料部分，您可以找到这些规范以及这个系列前面的文章和其他有用资料的链接。

异步操作要求：回顾

支持实际的企业业务流程本质上要涉及到异步操作，因为这些流程持续的时间比较长。每个流程的各个活动都需要与初始请求分开以优化系统资源的使用，并且需要把处理过程分解为一组可恢复的事务。我在这个系列的第一篇文章中提到过，支持异步操作需要完成下面几个任务：

1. 为它们的交换定义一个或一组相关器和一种机制。
2. 定义一个 回复地址，这个地址指定应该把响应发送到何处，并确保向服务提供者通知了这个目的地。
3. 服务提供者生成响应的过程作为一个事务与请求分开。
4. 客户机接收到异步响应。
5. 客户机和服务提供者把响应与相应的请求关联在一起。

另外，由于我将在可能涉及到流程及其伙伴间许多交互的较大型有状态业务事务的范畴内讨论异步操作，在异步操作期间交换的消息将需要被路由到同一个业务流程实例。因此，我还需要提出先前这个系列的第一篇文章中没有列入的另一个要求：

6. 把请求路由到有状态业务流程实例。

回页首

BPEL XML 语法元素

本文将概述 BPEL 如何为长时间运行的业务事务简化集成伙伴间业务流程的过程，其中一个业务事务由流程及其伙伴之间的多个交互组成。在下面几部分中，我将提供可以用来满足上面标识出的异步操作要求的具体 BPEL XML 语法示例。

BPEL XML 流语言具有用来对活动和用于控制流程行为的机制进行描述的语法。在我的示例中，我将使用这种语法的一个子集，这个子集中包含下面的 活动标记（activity token）和 元素（element）：

• 基本活动（Basic activity）：用于处理入站请求和响应的接收、数据向全局容器的分配以及出站 Web 服务请求的生成。本文将演示的这些活动的示例包括 receive 和 invoke 。
• 结构化活动（Structured activity）：用于管理活动序列的整个流程流、活动的并行处理以及在控制流程流时添加条件逻辑。本文将演示的这些活动的示例包括 sequence 和 flow 。
• 其他的 BPEL XML 元素帮助定义支持业务事务中的异步操作所需的关系和相关性。本文将演示的这些元素的示例包括 partners 、 serviceLinkTypes 、 role 、 link 、 source 和 target 。

关于 BPEL XML 语法的详细描述，请回顾一下 BPEL 规范（请参阅 参考资料）。

回页首

将业务语义应用于 Web 服务意味着什么？

将业务语义应用于 Web 服务实际上是利用 Web 服务的一种方法，这种方法允许企业在一个可运行的编程环境中复制企业与其伙伴在现实生活中具有的角色和关系。在这个环境中，可以通过把企业的伙伴所用的来自不同供应商的业务应用程序集成在一起使手工任务自动化。把业务交互中各参与者之间的实际关系和相关性反映到 Web 服务客户机和服务提供者是利用动态电子商务的价值取向的基础。当启动实际流程时，就开始了一组任务，其中一些任务是并行完成，而其他的任务则需要顺序执行。在流程进行期间，可能要涉及到其他业务伙伴，把这些业务伙伴的输入结合到业务逻辑中以决定流程的整体输出结果。这种情况非常典型，用 BPEL 很容易描述和实现。

使用 BPEL XML 语法描述的业务流程模型可以由 业务流程引擎来解释和执行。业务流程引擎通常是 Web 应用程序服务器的运行时的一部分；它管理正执行的流程的流动和控制权。流程中的每个步骤都将用一个 活动来代表；这种活动被实现为外部伙伴服务上的一个出站 Web 服务调用或对一个入站 Web 服务请求的处理。业务流程引擎执行流程模型时会通过它的 Web 服务接口创建一个可运行的流程实例。这些流程接口用于启动流程本身或者用于控制流程的各个方面（例如等待（wait）、终止（terminate）和补偿（compensate））。流程所公开的 Web 服务操作在执行与该流程相关联的业务任务时，可以聚集其他的 Web 服务。因此，流程流将包含流程自身和内部 Web 服务以及外部伙伴 Web 服务之间的一组 Web 服务交互。

回页首

长时间运行的业务事务需要异步 Web 服务支持

由于以下几个因素，在分布式环境中运行的企业业务流程的持续时间一般比较长：

• 与伙伴的交互因因特网延迟而变慢。
• 批处理通常被推给旧的后端系统来承担。
• B2B 解决方案经常需要常规的数据和传输转换。

由于处理时间的关系，与交互相关联的 Web 服务请求和响应将依赖异步操作把这两个事件分开。

BPEL 既支持同步操作又支持异步操作。对于前者，可以使用 <reply> 活动标记把对请求的响应定义为在同一个执行线程上返回。但对于长时间运行的业务流程（其中的许多活动可能是并行运行，并且使用了非阻塞线程以提高效率），BPEL 使得流程可以被描述，这样就可以使用 <invoke> 活动标记在分开的执行线程上生成响应。

回页首

流程活动的协调

就象 WS-C 和 WS-T 规范中所提到的那样，除了把参与伙伴的角色和职责映射到业务流程描述中外，还需要使用一组公共基础架构服务把分布式环境中所需的活动协调和事务支持所具有的可运行的特征应用到流程实现中去。但协调工具和事务工具的使用将由业务流程引擎根据 BPEL 流程描述结构来管理。因此，流程描述本身将不会显式利用规范中列出的协调和事务服务。

WS-C 和 WS-T 规范列出的工具将使参与者的业务流程引擎能够注册一些协调协议，这些协议确保就已建模的业务流程的输出结果达成可靠的、相互的一致。出于这个原因，在本文中我将不讨论为业务流程提供协调和事务方面支持的具体工具，因为这些工具的实现和管理将依赖于具体的业务流程引擎。

目前，BPEL 支持 业务活动（Business Activity）协调类型，这种协调类型考虑到了对持续时间比较长的活动的协调，并使用业务逻辑来通过基于补偿的恢复处理业务异常。当需要跨不同供应商实现的互操作性时以及用简单的流程异常终止不适合处理业务异常时，这种级别的支持是非常重要的。通常情况下，当一个活动的运行时间较长，并且该活动执行的操作需要是可恢复的，这时就用 scope 活动标记来封装该活动，这样，在必要的时候就可以应用补偿来通过 BPEL 中支持的补偿处理器机制在该活动内把操作的结果恢复为未执行操作时的样子。这种方法既可以应用于同步操作也可以应用于异步操作。当实现与 WS-C 和 WS-T 有关的工具来支持可以用 BPEL 描述的流程行为时，我们希望业务流程引擎使用异步操作。

关于业务活动协调协议的详细描述，请回顾一下 WS-T 规范（请参阅 参考资料）。

回页首

对业务伙伴间的异步交互进行建模

作为其 XML 语法的一部分，BPEL 规范包含用于定义活动、伙伴、点对点角色、消息交换协议、活动的同步相关性的机制，用于标识相关器的消息属性以及用于在执行业务流程的过程中共享业务协议数据和其他上下文数据的数据容器。BPEL 使企业能够为组成流程流的每个业务交互对流程自身与参与伙伴间的行为建模。交互被看作是点对点的消息交换（也就是一条有显式响应的请求、一条无响应请求或者单独一条单向通知）。根据为每个伙伴分配的角色为行为赋予一些交互方面的特征，同时为每个角色发送和接收消息，这些角色的身份根据与每个角色相关的 portTypes 操作加以识别。有些情况下，可能只发送单独一条消息（也就是一条无响应请求或者一条通知）。

您可能会觉得上面这段描述在现阶段有点笼统，所以我将回顾一些关于如何使用 BPEL 来满足我在上面列出的支持异步操作的六条要求的具体示例。

定义回调机制

流程和给定的伙伴（也就是一个单独的 Web 服务）之间的点对点消息交换被看作是它们双方之间根据它们的关系进行的交互。这两方之间的关系被建模为 serviceLinkType ，其中最多定义两个角色。每个角色都必须至少支持一个 portType 以使交互能取得成功。

<serviceLinkType name="BuyerSellerLink"
	xmlns="http://schemas.xmlsoap.org/ws/2002/07/service-link/">
	<role name="ServiceProvider">
	<portType name="Serviceprovider:ServicePortType"/>
	</role>
	<role name="Client">
	<portType name="Client:CallbackmechanismPortType"/>
	</role>
</serviceLinkType>
	

如果希望异步响应成为交互的一部分，就要为 serviceLinkType 标识两个角色，如上面的清单 1 所示：一个用作服务提供者，标识所提供服务的 portType ， 一个用作请求客户机，标识将处理与请求相关的异步响应的 回调机制（callback mechanism）服务的 portType 。

业务流程使用的 Web 服务被建模为 partners ；因此，内部服务和外部业务伙伴服务都要应用。 partners 定义交互的参与者，其中每个参与者的角色都根据为 serviceLinkType （它对关系进行建模）定义的角色来标识。

<partners>
	<partner name="RequestingClient" serviceLinkType="BuyerSellerLink"
	myRole="ServiceProvider"? partnerRole="Client"?>+
	</partner>
</partners>
	

这些机制使 IT 设计师和业务分析师可以满足我在本文开头处列出的异步操作的第 2 和第 4 条要求。

利用相关器

大多数情况下，一个服务将被回调机制的每个参与伙伴使用，因此，需要把相关器的使用定义为业务流程定义的一部分。通常情况下，业务协议信息，比如客户标识、订单号、供应商标识和发票号将被用于把请求与响应关联起来；当几个交互需要互相关联起来时，有时必须把各个相关器结合起来。最初的交互可能使用客户标识和订单号相关器的组合，而响应和后续的交互可能也包含一个发票号相关器。

由于业务协议数据在实际交互中被用于把业务任务关联在一起，因此，自然也是使用这种数据把 Web 服务请求和响应关联起来。为把业务协议数据作为相关器使用，您需要使用流程定义把消息属性定义为已命名的数据类型，这样您就可以给现有类型赋予更密切相关的意思（例如，把 OrderNumber 属性定义为 integer 类型或者把 VendorID 属性定义为 String 类型）。一旦定义了一个属性，您就可以指定一个 propertyAlias 来根据消息的结构（例如，通过标识 WSDL 的 <message> 和 <part> 元素）和 XPATH 查询字符串标识出特定的业务协议数据位于应用程序消息的何处。从本质上来说，这是在消息内定义了一些字段，在这些字段中可以找到相关器的值。

		
targetNamespace="http://example.com/supplyCorrelation.wsdl"
xmlns:tns="http://example.com/supplyMessages.wsdl"
xmlns:bpws=http://schemas.xmlsoap.org/ws/2002/07/business-process/
<!-- define correlation properties -->
<bpws:property name="customerID" type="xsd:string"/>
<bpws:property name="orderNumber" type="xsd:int"/>
<bpws:property name="vendorID" type="xsd:string"/>
<bpws:property name="invoiceNumber" type="xsd:int"/>
<bpws:propertyAlias propertyName="customerID"
messageType="tns:POMessage" part="PO"
query="/CID"/>
<bpws:propertyAlias propertyName="orderNumber"
messageType="tns:POMessage" part="PO"
query="/Order"/>
<bpws:propertyAlias propertyName="vendorID"
messageType="tns:InvMessage" part="IVC"
query="/VID"/>
<bpws:propertyAlias propertyName="invoiceNumber"
messageType="tns:InvMessage" part="IVC"
query="/InvNum"/>
	

毫无疑问，被用来定位相关器的字段必须在每个抽象的 WSDL 消息定义内被定义为正式的消息部件。同样，还必须在请求消息和响应消息中定义同样的消息部件，与 serviceLinkType 的各角色相关联的 portTypes 的各操作必须使用已为之定义了 propertyAlias 的消息类型。

当依赖不止一段业务协议数据把请求和响应关联在一起时，BPEL 使您能够把消息属性归入 correlationSets 中，并使用已命名的 correlationSets 标识流程实例中的应用程序级会话。

<correlationSets
xmlns:cor="http://example.com/supplyCorrelation.wsdl">
<!-- Order numbers are particular to a customer, this set is carried in application data -->
<correlationSet name="PurchaseOrder"
properties="cor:customerID cor:orderNumber"/>
<!-- Invoice numbers are particular to a vendor, this set is carried in application data -->
<correlationSet name="Invoice"
properties="cor:vendorID cor:customerID cor:orderNumber"/>
</correlationSets>

这些机制使 IT 设计师和业务分析师可以满足上面列表中的第 1、5 和 6 条异步要求。

使响应消息同步

当服务提供者 ― 在这个案例中，是正在执行用 BPEL 描述的业务流程的业务流程引擎 ― 接收到一个请求（例如，多步骤业务事务中的一次交互）时，在执行被业务流程作为 Web 服务公开的业务操作时需要执行一个或多个函数。一旦处理完成，一个响应就会被发送到请求客户机，该响应包含业务操作结果或表明操作已完成的通知。假设被执行的操作是长时间运行的业务事务的一部分，那么这次交互的响应将在单独的执行线程上被异步提供。

管理请求的接收、把请求路由到适当的流程实例、执行完成一个或多个任务的流程逻辑、确保流相关性得到满足并且在所有的处理完成后立即生成响应 ― 所有这些都可以很容易地用 BPEL 描述出来、用兼容的（compliant）业务流程引擎来处理，而无需 IT 编程人员开发复杂的同步流-控制逻辑，他们也不必管理流程状态数据。

利用相关器，BPEL 使业务流程引擎能够创建新的流程实例来处理入站请求或者根据请求内消息属性的值把入站请求路由到现有的流程实例。在可以并行执行多个活动以优化性能的流程流中，需要使后继的相关活动同步。为标识同步相关性，BPEL 使用活动定义内的 links 来控制活动间的同步。如果一个活动的输出结果需要作为另一个活动的输入（或者换句话说，一个活动必须在另一个活动前执行），那么这个活动将把自身标识为一个链接的 source ，而依赖它的活动将把自己标识为 target 。有了这些信息，业务流程引擎就可以管理流程流的相互依赖性来控制整体输出结果，从而确保与请求客户机相关的响应的生成是一种一致的行为。

		
		
<flow>
<!--Three synchronization links are defined  -->
<links>
<link name="ReceiveRequest"/>
<link name="XtoY"/>
<link name="CtoD"/>
</links>
	
<receive partner="RequestingClient">
<source linkName="ReceiveRequest"/>
</receive>
<sequence name="X">
<target linkName="ReceiveRequest"/>
<source linkName="XtoY"/>
<invoke name="A" .../>
<invoke name="B" .../>
</sequence>
<!--Sequence Y is dependent on Sequence X completing  -->
<sequence name"Y">
<target linkName="XtoY"/>
<receive name="C"/>
<source linkName="CtoD"/>
</receive>
<invoke name="E" .../>
</sequence>
<!--Invoke partner Requesting Client is dependent on Sequence X and Sequence Y completing  -->
<sequence name"D">
<target linkName="CtoD"/>
<invoke partner="RequestingClient"/>
<invoke name="F" .../>
</sequence>
</flow>		

由于响应是在单独的执行线程上发送，所以在流程描述中用 invoke 活动标记来调用客户机的回调机制服务。概括起来就是，响应被作为利用了已命名伙伴 RequestingClient 的 invoke 活动的结果发送到回调机制， RequestingClient 被定义为 BuyerSellerLink 关系（ serviceLinkType ）中的参与者（ partnerRole 被设置为 Client ），其中 Client 角色指定支持 Client:CallbackmechanismPortType portType 。

这些机制使 IT 设计师和业务分析师可以满足第 3 和第 5 条异步要求。

回页首

了解 BPEL 的潜能

要使企业能够在为自己的实际流程进行建模时利用 Web 服务，开发 Web 服务的业务流程执行语言、Web 服务协调和 Web 服务事务等规范是至关重要的一步。有了 BPEL，您就可以使用活动来封装各个流程步骤的原子事务，从而描述业务事务的长时间运行且多步骤的流程。

一旦用 BPEL XML 流语言描述了流程，业务流程引擎就必须解释流程描述以便执行和管理业务事务。业务流程引擎将提供基础架构服务和资源来启用运行时间较长的有状态业务事务，这种业务事务要求流程、内部服务和外部伙伴服务（它们本身也可以是伙伴的流程流公开的个别服务）之间的交互。

但这一次，要使企业流程能够在一个可运行的编程环境中被完全实现，IBM 和其他的供应商将需要更新他们的业务流程引擎，以解释 BPEL XML 流语言和支持 WS-C 和 WS-T 规范中提到的协调和事务工具。同样，这三个至关重要的规范也需要被提交给标准组织并被批准成为开放的标准。目前，IBM、Microsoft 和 BEA 正在朝着这个目标努力。

一旦业务流程引擎能够全面支持 BPEL、WS-C 和 WS-T，那么试图通过利用 Web 服务技术和这些新规范使业务流程中的步骤实现自动化的任何企业的 IT 员工都需要：

• 使用 BPEL XML 流语言描述企业的流程。
• 为活动提供业务逻辑。
• 为将在流程流活动中被用来完成业务事务的旧应用程序（例如，事务资源管理器）提供 Web 服务接口。
• 告诉业务流程引擎如何定位流程流活动中所用的 Web 服务。

不用多久，企业就将利用它们现有的企业资产，将他们的任务关键（mission-critical）的流程与他们的伙伴的那些流程集成在一起，执行运行时间较长且可中断的流程流，这些流程流就反映目前实际情况的输出结果达成了一致。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请单击文章顶部或底部的 讨论参加关于本文的 讨论论坛。
  
  
• 阅读 Holt Adams 发表在 IBM developerWorks 上的“异步操作和 Web 服务”系列中的前面两篇文章：
  • “ 异步事务入门”（2002 年 4 月）
  • “ 构建异步 Web 服务的编程模式”（2002 年 6 月）
  
  
  
• 查阅发表在 developerWorks 上的下列规范：
  • Web 服务的业务流程执行语言
  • Web 服务协调
  • Web 服务事务
  
  
  
• 下载 IBM Business Process Execution Language for Web Services Java Runtime（BPWS4J），一个可从 IBM alphaWorks 获取的业务流程引擎。
  
  
• 阅读 Web 服务描述语言（Web Service Description Language，WSDL）规范的版本 1.1，可以从 W3C 的 Web 站点获得。
  
  
• 参阅 IBM WebSphere Application Server的产品页面。
  
  
• 参阅 IBM WebSphere Studio Application Developer的产品页面。
  
  

关于作者

Holt Adams 目前是支持 IBM 的 jStart 计划的高级 IT 设计师，他与客户和商业伙伴合作采用 Web 服务和其他新兴技术。1982 年从 University of Tennessee 获得电子工程学位毕业后，他加入了 IBM 位于北卡罗来纳州的 Research Triangle Park。他具有开发通信和网络产品的软件和硬件的经验、移动和无线解决方案的技术销售方面的经验以及基于因特网的解决方案的体系架构和集成方面的经验。在过去两年间，他致力于把 Web 服务提升为 IBM 的战略性集成技术，起初是和客户一起进行概念的证明，最近在为生产环境开发解决方案。您可以通过 rhadams@us.ibm.com与 Holt 联系。

为本文评分

评论

回页首

内容

• 异步操作要求：回顾
• BPEL XML 语法元素
• 将业务语义应用于 Web 服务意味着什么？
• 长时间运行的业务事务需要异步 Web 服务支持
• 流程活动的协调
• 对业务伙伴间的异步交互进行建模
• 了解 BPEL 的潜能
• 参考资料
• 关于作者
• 建议