用于 Web Services 业务事务的 OASIS WS-CAF 方法

关注

转载最新推荐文章于 2026-11-09 19:04:00 发布 1.3k 阅读 AI 写同款· GEO 优化 ›

WSServletContextListener 所需jar包已经经过测试，当你想将SOAP-BASED web servcie部署到tomcat时，先映射为servlet，而用lisenter产生此实例，配置文件为sun-jaxws.xml.但需要你在web-inf/lib下加入所需jar包才可以立即下载

通过在复杂多方业务操作中提供保证一致的输出，并在生成设计良好的业务流程实现中提供关注点分离，原子事务的概念在创建当今的企业应用程序环境的过程中扮演了基石的角色。

　　随着 Web services 已经发展成为在企业间级别上集成流程和应用程序的一种手段，传统的事务语义和协议已被证明是不合时宜的。基于 Web services 的事务俗称业务事务（ Business Transaction ），它与传统事务的区别在于，它们的执行期过长，需要提交给事务以便在运行时成为“达成协议的”，而且隔离级别必须放松。

　　这个问题的解决方案必须基于 HTTP 协议工作，并包括现有所有类型的事务处理技术：数据库管理系统、应用服务器、消息排队系统和打包的应用程序。解决方案需要支持一些需求，包括从轻量级的应用程序到复杂的事务，前者的主要目标是让 Web services 知道它们何时位于同一个应用程序中，后者需要花费数天或数周才能完成，并且其跨越的地理范围、时区和企业边界都很广泛。在本文中，我们将考察 OASIS WS-CAF 标准化进程，并说明它是如何尝试解决这个重要而困难的主题的。

简介

　　原子事务是用于在出现故障时保证一致性的一项著名技术 [1] 。原子事务的 ACID 属性（ Atomicity , Consistency , Isolation , Durability ，即原子性，一致性，隔离性和持久性 ）确保了即使是在复杂的业务应用程序中，不管并发的访问和故障情况如何，也可以保持状态的一致性。这是一项十分有用的容错技术，尤其是当涉及到多个可能是远程的资源时。

　　以前的事务处理系统在它们解决的问题症结以及它们用来解决它的抽象方面具有很大的通用性。特别地，事务处理系统是针对特定平台而开发的，而且每个系统都假定它单独控制事务域，因此通常不必与其他事务处理系统进行互操作（尽管通过像 X/Open XA 这样的接口通常可以很好地支持与像数据库这样的底层组件的互操作性）。

　　然而，在传统的原子事务系统中，可用的结构化机制是事务的连续而并发的组成部分。如果一个应用程序函数可以表示为一个原子事务，这些机制就已足够。事务最适于被看作是“短期的”实体，执行对系统的稳定状态变化；它们比较不适合于构造“长期的”应用程序函数（比如要运行数个小时，数天 … ）。通过长期保持资源（比如锁定），长期的原子事务（通常出现在业务到业务的交互中）可以把系统中的并发性降低到一个可以接受的水平；此外，如果这类原子事务回滚，许多已经执行的有价值的工作就会被取消。

　　Web services 引出了一类不同的问题：它们明确与促进系统的互操作性有关。从事务管理的角度看，这引出了一些有趣的问题。正是一个事实使 Web services 如此有趣，这个事实就是，体系结构故意不说明服务端点背后发生的事情—— Web services 最终只与几方之间的结构化数据的传输有关，以及用于保护这类传输的任何元级别信息（比如通过加密或数字签名消息）——但是正是在服务端点之后，我们发现了支持业务行为的传统事务处理体系结构。

　　因此，我们正面临一个悖论。 Web services 平台提供一种面向服务的、松散耦合的而且可能是异步的方法，用于在多方之间传播信息，可是在幕后，我们拥有传统的事务处理基础架构，其行为不是可互相操作的。而且，在向第三方公开资源时，有一个事实可能会导致出现问题，这个事实就是这些系统中的事务均被假定为显示 ACID 属性，因为它让各方有机会占用资源，并防止事务取得进展。因此，如果 Web services 体系结构中对事务提供支持，那么无疑需要重新解决这个问题。

　　这就是 Web 服务复合应用程序框架 ( OASIS Web Services Composite Application Framework) [2] 大展拳脚的舞台。 2003 年 8 月，当 ArjunaTechnologies , Fujitsu, IONA Technologies, Oracle 和 Sun Microsystems 把他们的 WS-CAF 规范提交给标准组织之后，该框架就正式诞生了。与一些其他的 Web services 厂商的工作不同，这项工作是完全开放的，而且所获得的成果也是免费提供的。在下面的场景中，我们将考察 WS-CAF 是如何尝试解决业务到业务事务的重要问题的。

WS-CAF 概览

　WS-CAF 套件包括三个规范，可以增量地实现它们以解决支持各种从简单到复杂的复合应用程序所需的要求：

Web Service Context (WS-Context), 一个用于简单上下文管理的轻量级框架。现在， WS-Context 已经到达 OASIS Committee Draft ，而且已经成为几个互操作性演示程序的主题 [10] 。
Web Service Coordination Framework (WS-CF), 定义了协调程序的行为，借助这个协调程序， Web services 可以注册上下文扩大和结果传播，以此为基础可以插入各种事务协议。
Web Services Transaction Management (WS-TXM), 包括三个不同的协议，用于实现跨事务管理程序的互操作性，并支持多个事务模型（两阶段提交，长期运行的动作或校正，以及业务流程流）。

　　WS-CAF 各个部分结合在一起的总体目标是，提供一个支持各种事务处理模型和体系结构的完整解决方案。 WS-CAF 的实现可以从小开始，然后随着时间的推移，逐步壮大为包含更多功能。 WS-CAF 规范的设计目标是配合 Web services 编制和编排（ choreography ）技术，比如 WS-BPEL [3] 和 WSCI [4] ，并与其他 Web services 规范兼容。 WS-CAF 的重点是定义联合使用 Web services 时所需的支持服务，包括其他规范。

　　WS-CAF 的各个部分构成了一个堆栈，从 WS-Context 开始，加入 WS-CF ，然后加入 WS-TXM ，从而交付了复合应用程序所需的完整特性和功能。 WS-CAF 的实现可以从具有简单上下文管理功能的 WS-Context 开始，稍后加入具有其他上下文管理功能和上下文消息交付保证的 WS-CF ，最后加入可以管理各种恢复协议的 WS-TXM 。

　　在下面的内容中，我们将会更加详细地考察这每一种规范，并说明它们是如何支持复合 Web services 应用程序的开发的。

WS-Context

　　WS-Context 为 Web services 提供一种机制来共享持久性状态，这种机制是支持会话式交互、单点登录、事务协调和其他依赖于系统级数据项（比如 ID 、令牌等）的功能所必需的。上下文提供一种方式，可以通过共享通用信息（比如单点登录会话中交换的安全令牌），把一组消息关联到一个更大的工作单元中。

　　因为分布式计算系统依赖于各种 ID 、令牌、频道和地址（这些都是每个软件基础架构的一部分），而且因为 Web services 独立于任何特定的执行环境，我们需要通过一种持久性的共享上下文结构来组织和管理这类系统级信息。应用程序需要服务来管理共享上下文的生命周期，而且要确保上下文结构保持最新，并且可以访问。

　　WS-Context 定义了一个可以任意进行扩充的上下文数据结构。默认情况下，所有上下文定义都是一个惟一的上下文标识符、上下文类型（比如事务或安全性）和一个超时值（上下文可以保持有效的时间长度）。例如：

 
  
   
   <
   env:Envelope 
   xmlns:env
   =http://www.w3.org/2002/12/soap-envelope>
 
   <env:Header
   >
   
   
   <
   wsctx:context 
   timeout
   ="0"
   >
   
     
   <
   wsctx:context-identifier
   >
   

        
   <
   "http:
   //www.arjuna.com/ws-ctx/123:abc:456:def" 

     </wsctx:context-identifier
   >
   
     
   <!--
    Other protocols can extend context here 
   -->
   
   
   </
   wsctx:context
   >
   
 
   </
   env:Header
   >
   
 
   <
   env:Body
   >
   
   
   <
   m:Message 
   xmlns:m
   =http://example.org/MessageSchema    


   <m:?
   </m:Message
   >
   
 
   </
   env:Body
   >
   

   </
   env:Envelope
   >

WS-CF

　　协调程序是一个软件实体，负责确保多方之间达成一致。协调程序位于 CORBA , .NET , J2EE 和其他分布式计算环境中，用于跨多个数据源协调典型的两阶段提交事务协议。然而，协调是一种更加基础的要求：它可以用于安全、复制、缓冲和其他领域中。

　　因此，通过使用一个支持多个协调协议的插件机制， WS-CAF 中对协调程序的定义进行了扩展，以便用于 Web services 。 Web services 的设计目的是多协议的，而且因此可以映射为多项底层技术。 WS-CF 规范创建了一个能够驱动各种上下文类型和事务协议（比如 WS-TXM 中定义的那些协议和其他协议）的通用协调程序，而不是把协调程序绑定到两阶段提交协议上，虽然后者是定义当前协调程序的方式。

　　无论使用何种协调协议和部署在哪个域中，都存在相同的一般性要求：

为特定的协调协议，为特定的应用程序实例实例化（或激活）一个新的协调程序。
协调程序参与者注册，这样它们将会在应用程序的生命期（的某个部分）中收到协调程序的协议消息。
在组成应用程序的 Web services 之间传播上下文消息。
驱动协调协议直到完成为止的实体。

　　这些要点的头两条直接涉及到 WS-CF ，第三条是通过使用 WS-Context 而获得的，而第四条则是第三方实体的责任，通常是控制应用程序整体的客户端应用程序。

 
  
   
   <
   env:Envelope 
   xmlns:env
   ="http://www.w3.org/2002/12/soap-envelope"
   >
   
  
   <
   env:Header
   >
   
    
   <
   n:Composite 
   xmlns:n
   ="http://www.example.org/CompositeApplication"
   >
   
      
   <
   n:Coordinator
   >
   
        http://www.webservicestransactions.org/example/CoordinatorURI

      
   </
   Cooordinator
   >
   
    
   </
   n:Composite
   >
   
  
   </
   env:Header
   >
   
  
   <
   env:Body
   >
    ...

   </
   env:Envelope
   >

　　在上面的例子中，协调程序 URL 执行一个 Web services 接口，该接口为协调程序与 Web services 执行之间的交互定义了 SOAP 消息模式。协调程序就可以管理任何用户定义的上下文，并生成和传播用在复合操作中的任何上下文，包括恢复协议中的每个已注册的 Web services 。

WS-TXM

　　假设传统的 ACID 事务模型不适合 Web services ，我们就会提出这样一个问题，“哪种类型的模型或协议才适合呢？”这个问题的答案就是，可能没有一种特定的协议是足够的，因为部署 Web services 事务的环境可能多种多样。

　　因此， WS-TXM 提供设计用于适用多个用例的模型，从紧密耦合的基于企业内部网的事务（ tightly-coupled intranet-based transactions ,TX-ACID ） , 到因特网规模的长期事务（ Internet-scale long lived transactions ， TX-LRA ） , 再到面向业务流程的事务（ business-process oriented transactions ， TX-BP ）。

　　值得注意的重要一点是，这组协议并不是完整的。其意图是，如果开发出其他更适合于各种用例的模型，那么就应该把这些模型添加到 WS-TXM 。

TX-ACID

　　这个模型的设计目的是通过 Web services 支持现有的事务处理系统，因为这类系统已经组成了企业级应用程序的骨干部分。尽管 ACID 事务可能不适合于所有的 Web services ，它们肯定会适合其中的一些，特别是像金融中涉及到的那些高价值交互。结果，设计 WS-TXM 中定义的 ACID 事务模型时已经考虑了互操作性。在 ACID 模型中，每种行为都被束缚在事务的范围内，这样行为的结束便会自动触发相关事务的终止（提交或回滚）。

TX-LRA

　　长期运行的动作模型（ long running action model ， LRA ）是特别为那些持续较久的业务交互而设计的。在这个模型中，行为可以影响业务交互，在应用程序范围内执行的所有工作都必须是可补偿的。因此，对于应用程序的工作来说，要么成功执行，要么什么都不做。单独的 Web services 如何执行它们的工作并确保在需要补偿时能够撤消工作，这是实现的选择，并未公开给 LRA 模型。 LRA 模型只为补偿动作定义了触发器和执行触发器所需的条件。

　　在 LRA 模型中，每个应用程序都被绑定在补偿交互的范围内。例如，当用户预订了一次航班的座位时，航班预订中心可以采取一种最有利的方法——实际预订座位并记在用户帐户上，这样做的根据是大多数预订座位的客户稍后都会买票；这种行为的补偿动作显然是取消座位的预订，并贷记用户的帐户。在嵌入的 LRA 范围内执行的工作必须保持是可补偿的，直到一个封闭服务通知单独的服务不再需要它为止。

　　对这个模型的警告是，应用程序服务可能不是可补偿的（比如，打印和邮寄支票的应用程序级服务），或者补偿能力可能是暂时的。 LRA 模型允许应用程序把可以进行补偿的服务与不能进行补偿的服务结合在一起。显然，通过混合这两种服务类型，用户得到的结果可能是，业务行为最终由 LRA 模型撤消，但是这可能需要外部（特定于应用程序的）补偿。

　　LRA 模型定义了一个叫做 Compensator 的协议实施者，它代表服务进行操作，取消它在 LRA 范围内执行的工作。如何开展补偿显然与服务有关；补偿工作可以由其他自身拥有 Compensator 的 LRA 执行。

　　让我们考虑另一个长期运行的业务事务的例子。该应用程序的内容是预订出租车，预订餐馆座位，预订剧院座位，然后是预订酒店房间。如果把所有这些操作当作一个事务来执行，那么在预订出租车（举个例子）期间获得的资源直到顶级事务终止之后才会释放。如果后续的行为不需要这些资源，那么它们不必要对其他客户端不可用。

　　图 1 说明了如果把联系的各个部分映射到 LRA 中。所有单独的行为都是可补偿的。例如，这意味着如果 LRA1 失败，或者用户决定不接受预定的出租车，工作将被自动取消。因为 LRA1 被嵌入到其他 LRA 中，一旦 LRA1 成功地完成任何补偿机制，它的工作可能被传递给 LRA5 ：这是 Compensator 的一种实现选择。在 LRA5 成功完成的事件中，没有工作需要进行补偿，否则在 LRA5 (LRA1 to LRA4) 范围内执行的所有工作都会得到补偿。

fig1
图 1 , LRA 示例

TX-BP

　　在业务流程事务模型（ business process transaction model ， BP model) 中，业务流程中涉及到的所有方都位于业务域（ business domain ）中，它们本身可能会使用业务流程来执行工作。业务流程事务负责管理这些域之间的交互。业务流程（业务到业务的交互）被划分为很多 业务任务 ，而每个任务都在一个特定的业务域内执行。业务域本身可以以一种循环方式再分为其他业务域（业务流程）。

　　如果模型的联合更加适于行为，每个域可以代表一个不同的事务模型。每个业务任务（可以被建模为作用域）可以在必须取消封闭作用域的事件中起到特定于实现的反作用。另外，控制应用程序可以周期性地请求整个业务域具有它们的状态点，这样它们就可以通过应用程序一致地回滚到该检查点，或者在事件失败时从该检查点重新启动。

　　单独的任务可能需要多个服务才能工作。我们假定每个任务是一个可补偿的工作单元。然而，与前面描述的 LRA 模型一样，如何提供补偿是任务的一个实现选择。

　　例如，考虑图2 中显示的购买家庭娱乐系统的例子。在线商店与它们的特定供应商交互，每个供应商都位于它自己的业务域中。获得每个组件必需的工作被建模为一个单独的任务或 Web services 。在这个例子中， HiFi 任务实际上由两个子任务构成。

fig 2
图2,业务流程和任务

　　在这个例子中，用户可以与商店进行同步的交互，以构建娱乐系统。另外，用户还可以提交一份订单（可能带有可选要求的列表）给商店，而商店到货时就会与用户取得联系；同样地，商店提供订单给每个供应商，要求它们在每个组件可用（或者已知不可用）时联系自己。

如何使用 WS-CAF ？

　　在业务行为期间，一个给定流程通常会与许多不同的合作伙伴进行交互，以便完成工作。这些交互可以基于同步或异步的传输机制。然而，典型的交互模式是基于异步的（单向）消息，因为这样做的好处是支持应用程序实体的松散耦合：需要响应的给定消息的发送者不需要和该响应的最终接收者相同。这允许在选择服务部署的过程中拥有更大的灵活性，特别是在易于出错或者需要动态变换角色和责任的环境中。

　　然而，如果交互的结构为独立的单向消息，显然需要一些把响应绑定到请求的手段。此外，在某些情形中，对于把多个请求发送给一个服务，但只需要一个响应来说，它可能是必需的。例如，考虑一个在线计算机订购服务，该服务允许您发送一份初始订单，但是可以跟进增强的请求，直到机器最终运到为止。这样就存在多个发出的请求（最初的 + N 个改进的）和一个进入的响应（交货）。

　　这些要求都可以被归结为要求消息 上下文化 ：另外的信息与消息相关联，以支持基础架构“路由”消息（在物理上或逻辑上）。完成这种匹配有一种明显的方式，即通过使用与消息相关的另外的信息（比如消息次序号）。然而，这样做具有以下缺点：

它要求来自涉及到的各方的支持（和同意）。例如，我们是否对这种信息使用了字符串、 URI 或整数？
它是一个特殊的解决方案，每次应用程序具有此类要求时就要实现它。尽管对于一次或两次交互，它是有效的，但是随着交互数目和服务的增长，它不能随之扩展。

　　WS-Context 定义了一种绑定了上下文的抽象行为的概念：行为的生命期就是上下文的生命期。所以，我们可以（例如）使用一种行为来对会话建模：在行为作用域内，面向会话的服务上的所有交互通过上下文被惟一且清楚地绑定到该行为上。行为还可以对业务流程实例、会话和其他概念建模。

　　例如，上下文的开始部分可能如下：

<ContextType>MyContext</ContextType>
<context-identifier>
www.webservicestransactions.org/example/xml2004

</context-identifier>

　　行为可能需要用户身份验证。例如，正如我们提过的那样， Bob 和 Pen 之间的交互需要某种身份验证信息。为了方便整个复合应用程序中的单点登录，可能要将上下文扩展为包括用户信息，并将其提供给为 WS-BPEL 定义的流中首个 Web services 的输入。流中的首个 Web services 将会检查用户名和密码（星号用于表示下面例子中的不透明数据），并生成一个身份验证令牌。这种身份验证令牌将被放回到上下文数据结构中，扩充原始的结构。这个令牌（而不是用户名和密码）用于随后检查用户是否有权访问流中的其他 Web services 。

　　扩充之后的上下文可能包含以下内容：

<extended-context>
<user-name>John Doe</user-name>
<password>********</password>
<AuthToken>********</AuthToken>
</extended-context>

　　正如前面举例说明的那样，上下文就是一个活动的数据结构；安全登录的结果（或者相当于上下文内容的其他操作）通常会被添加，然后传播给流中的下一个 Web services 。例如，联系多个安全域的单点登录系统可以添加另一个令牌给上下文。

　　像业务流程执行语言（ Business Process Execution Language ， BPEL ）和 Web 服务编排接口（ WebServices Choreography Interface ， WSCI ）这样的规范，其重点是把多个 Web services 联系在一起，以创建多步骤的应用程序，比如填写购买订单或者解决保险索赔。因此，这些应用程序具有跨多个步骤共享上下文和协调这些步骤的需求。

　　尽管像 BPEL 和 WSCI 这样的机制提供了一种机制，用于把 WSDL 层扩展为识别多个 Web services 的一系列执行。 WS-CAF 定义了补偿系统层，这个层是确保多个 Web services 获得应用程序的预期结果，以及来自本地或远程源的多个 Web services 进行协作以生成可预测行为（不论系统是否出现故障），并使系统处于可知状态所必需的。

结束语

　　其他 Web services 规范也分为私有和开放的，而 WS-Context 规范是惟一的。不存在为 Web services 定义通用上下文管理机制的其他规范。

　　OASIS WS-Coordination Framework 规范与私有的 WS-Coordination 具有共同的起源——它们均基于 Object Management Group(OMG) 的扩展事务规范，叫做 Additional Structuring Mechanisms for the OTS [8] 。这个规范被开发为 Object Transaction Specification (OTS) 的一个扩展 [9] ，定义了如何协调 CORBA 和 J2EE 世界的工作。

参考资料