CN100561920C - Web服务事务处理系统及处理方法 - Google Patents

Abstract

一种Web服务事务处理系统，它包括客户端、协调器和多个参与者三部分，彼此之间通过互联网相连；其中，参与者和协调器作为Web服务提供者和协调、处理者部署在Web服务运行时的平台上。Web服务事务处理过程实际上就是这三部分之间进行协调和交互的过程；客户端发起事务、划分事务边界和提交事务，协调器管理和协调事务，参与者提供、参与Web服务事务。客户端仅仅发起事务、划分事务边界、提交或者取消事务，事务的主要工作由协调器和参与者交互完成。本发明还公开了一种Web服务事务处理方法，它利用上述事务处理系统，采用两阶段提交协议保证各事务之间的原子性、一致性和可靠性，并且对事务进行监控配置管理。所述两阶段提交协议包括协调阶段和事务阶段。

Description

Web服务事务处理系统及处理方法

技术领域

本发明涉及一种Web服务事务处理系统及方法，该事务处理系统及方法能够保证基于开放式网络、松耦合环境中的多个Web服务运行结果保持原子性、一致性和可靠性。

背景技术

随着互联网技术和应用的迅速发展，互联网已经成为人们获取各种信息、技术、服务的主要手段。

在互联网技术发展的同时，基于互联网的应用模式也在不断发展。初期，人们只是使用浏览器查询、处理日常应用，Web服务器提供HTML等语言的支持，数据库服务器提供对数据的管理。为了提高系统的吞吐率和应用的实现效率，人们在两层模式上增加了中间一层------应用服务器，来提供各种Web服务、处理与商业逻辑有关的事务。随着应用需求的不断扩大，三层体系结构逐渐扩展到多层模式。在多层模式中，基于EJB、CORBA等分布式组件技术在业界得到了支持和广泛应用，并逐步成为网络中间件的主流技术，较好地解决了紧耦合方式下构件运行的支撑环境问题。

但是，由于传统的分布式对象、中间件技术都保持着相互独立的结构体系和协议以及客户端和服务器端的紧耦合性，使得它们不能适应动态发布服务的需求，也不能很好地实现在动态、松耦合环境下的业务协作。因此，为了满足日益增长的业务需求，人们提出Web服务概念来解决新一代互联网软件所面临的问题。

对于Web服务有以下几种定义：①Web服务是一种通过URI标识的软件应用，其接口及绑定形式可以通过XML标准定义、描述和检索，并且可以通过XML消息和互联网协议来与其它软件应用直接交互；②Web服务是封装成单个实体并发布到网络上以供其它程序使用的功能集合；Web服务可被理解为一种通过Web进行数据和功能共享的技术。总之，Web服务能够统一地封装信息、行为、数据和商务流程，从而屏蔽所在环境的软件和硬件设施，为不同实现标准和通信机制下的软件交互和集成提供有效的支持。

从上述分析可知，Web服务是基于XML标准的开放的Web规范技术，与传统的分布式组件技术相比Web服务具有更好的封装性，高度的可集成性以及更好的开放性和互操作性，它将企业内部紧耦合的分布式计算环境扩展到面向互联网的分布式计算环境，具有广泛的应用前景。

Web服务在解决异构环境下的互操作问题具有很好的优势，它可以使分布式的异构环境下的应用程序在网络间进行集成。在Web服务的组合和交换过程中，Web服务应用程序常常需要处理内部的资源，在关键的业务流程中需要保证分布在不同地理环境的属于不同组织的资源保持一致性。同时Web服务由于处在松耦合的环境下，会遇到很多的故障问题，如网络中断等等，因此需要及时处理运行时的各种异常并保证结果的可靠性。为了解决这些问题，Web服务处理环境需要事务技术的支持。

但是，传统的事务技术如Arjuna公司出品的Arjuna WST软件、Choreology公司出品的Cohesion1.0软件都是适用于紧耦合环境内的分布式事务，不适合松散耦合环境如Web服务环境内的多个Web服务事务。因为，传统的分布式事务发生在紧耦合的可信任的环境中，例如局域网内，并且具有ACID(原子性、一致性、隔离性和持久性)四个特性，事务持续的时间一般较短；事务服务器在自治防火墙里面运行，几乎集中控制参与事务的资源，参与方在提交事务前需要锁定底层资源以保证一致性；事务中的参与方或者完全提交或者完全回滚必须保持一致。而在Web服务环境里，事务是很复杂的，包含很多参与方，这些参与方可能属于不同的组织和部门并跨越信任域和公司防火墙。事务的运行时间可能很长，例如B2B电子交易这样的应用场景，一个订单从提交到完成可能需要几个小时甚至几天的时间。Web服务事务中的参与方不愿意或者不可能将底层资源进行排他性的锁定。因为Web服务场景内的事务持续时间很长，参与方的长时间的锁定资源会导致参与方不能参与其它事务，而且接收信任域之外的指令锁定资源可能会带来严重的后果。

由于分布式网络环境的松耦合特性和商业逻辑的复杂性，参与事务中的部分工作失败常常不需要取消已经运行了长时间或者作了很多工作的事务。因此Web服务中的事务参与方并不像传统的事务那样严格控制或者完全提交或者完全取消自己所作的工作。事务的发起者可以根据自己的商业逻辑允许部分参与方失败而不影响整个事务的运行。

发明内容

为了协调、处理、监控管理分布式、松耦合Web服务环境下的多个Web服务，使多个Web服务的运行结果保持原子性、一致性和可靠性，本发明的目的是提供一种Web服务事务处理系统及处理方法；该事务处理系统使用两阶段提交协议的处理方法保证各事务之间的原子性、一致性和可靠性，并且对事务进行监控配置管理。

为实现上述目的，本发明采取以下设计方案：一种Web服务事务处理系统，它包括客户端、协调器和多个参与者三部分，彼此之间通过互联网相连；其中，参与者作为Web服务提供者，协调器作为协调、处理者部署在Web服务运行时的平台上，并使用两阶段提交协议进行交互；

所述客户端是一组程序集合，用户通过客户应用程序调用客户端，发起Web服务事务、调用事务性的参与者、划分事务边界、提交或者取消事务；同时根据用户的商业逻辑允许客户端取消部分参与者的工作而不影响整个事务的运行；

所述协调器为本系统管理和控制Web服务事务的协调中心，通过使用两阶段提交协议管理事务的运行；

所述参与者提供、参与Web服务事务并承担事务性工作；参与者将自己系统的资源操作包装成Web服务，参与事务；参与者使用两阶段提交协议向协调器提交协议；

所述两阶段提交协议包括协调阶段和事务阶段。

所述协调器为本系统管理和控制Web服务事务的协调中心，管理事务的运行，它由消息转发器、控制器和参与者资源三部分构成；其中所述消息转发器又包括消息解析器、消息处理器；所述控制器包括两阶段提交控制器、协调器上下文；消息解析器负责解析接收到的消息，解析后的消息交给消息处理器进行处理；协调器上下文包含了协调器的地址、事务ID、协调器ID、状态等信息，以及参与者资源的引用列表，每个参与者登记到协调器中生成一个参与者资源，由协调器上下文负责维护；协调器在接收到客户端提交事务的请求后，消息处理器调用两阶段提交控制器，由两阶段提交控制器具体完成事务提交的工作。

所述参与者由一个消息解析器、消息处理器和参与者上下文组成；消息解析器负责接收协调器、客户端发送的消息，并解析请求的消息，根据请求消息的种类调用消息处理器的操作；参与者上下文封装了参与者的相关信息；在消息处理器具体处理消息时，需要使用参与者上下文的资料，处理完毕将结果消息通过消息解析器返回给协调器；消息解析器使用两阶段提交协议向所述协调器提交协议。

一种Web服务事务处理方法，它利用包括有客户端、协调器和多个参与者的Web服务事务处理系统，对基于开放式网络、松耦合环境中的多个Web服务事务进行协调、管理和控制；其中，由客户端发起事务、划分事务边界和提交或取消事务，协调器管理和协调事务，参与者提供、参与Web服务事务；其特征在于：所述协调器和参与者之间通过两阶段提交协议保证各事务之间的原子性、一致性和可靠性，并且对事务进行监控配置管理；

所述两阶段提交协议包括协调阶段和事务阶段；

所述协调阶段指客户端发起一个新的Web服务事务后，协调器接收到消息后创建事务；客户端调用参与者操作，参与者接收到客户端的请求后向协调器登记事务；

所述事务阶段指Web服务事务开始、执行、完成的全过程，由协调器和参与者共同完成；协调阶段后，参与者和协调器已互相知道对方的信息，开始进行事务阶段工作，在事务阶段完成后，协调器将事务结果向客户端报告。

所述协调阶段具体包括以下步骤：

1)客户端向协调器发出事务开始消息，要求开始一个原子Web服务事务，在该开始消息中指明事务类型是原子事务；

2)协调器在接收到该事务开始消息、创建新的事务后，向客户端发送包含有事务上下文内容的响应消息，事务上下文内容包含事务ID、事务类型、协调器地址、协调器ID等有关本次事务的信息；

3)客户端在得到响应消息后，调用参与者提供的Web服务操作，向各个参与者发送带有事务上下文内容的应用程序消息；

4)参与者接收到该应用程序消息后，根据事务上下文内容中协调器地址向协调器发送请求登记消息，要求登记；

5)协调器在登记了参与者的相关信息后发送登记完成消息，表示登记成功；

6)参与者登记成功后，向客户端发送可以执行应用程序的响应消息。

所述事务阶段具体包括以下步骤：

1)客户端向协调器发送提交事务的消息，开始提交事务；

2)协调器向参与者发送准备消息，要求参与者准备；

3)参与者根据自己情况发送已准备好消息或取消准备消息或退出Web服务事务消息；

4)协调器根据接收到的各个参与者发出的消息做出决定提交或者取消事务的决定，并向参与者发送提交事务消息或者取消事务消息；

5)参与者根据接收到的协调器的指令进行确认或者取消，并向协调器发送确认提交消息，完成提交事务：或者向协调器发送取消Web服务响应消息，完成取消事务；或向协调器发送退出Web服务响应消息，退出事务；

6)协调器完成和参与者的两阶段提交后，向客户端报告事务运行的结果；

7)结束。

附图说明

图1为本发明Web服务事务处理系统系统结构示意图

图2为本发明Web服务事务处理系统两阶段提交处理方法运行过程图

图3为本发明客户端发起事务程序框图

图4为本发明参与者结构示意图

图5为本发明参与者程序框图

图6为本发明协调器结构示意图

图7为本发明协调器程序框图

图8为本发明实施例应用场景示意图

图9为本发明实施例Web服务工作流事务原理图

具体实施方式

如图1所示，本发明提供的Web服务事务处理系统主要包括客户端、协调器和多个参与者三部分，彼此之间通过互联网相连；其中，参与者和协调器作为Web服务提供者和协调、处理者部署在Web服务运行时的平台上，并使用两阶段提交协议进行交互。

客户端是一组程序集合，Web服务应用程序使用该程序集合，可以方便的开始事务，提交或者取消事务，同时可以查询参与者的状态。用户通过客户应用程序调用客户端，发起Web服务事务、调用事务性的参与者、划分事务边界、提交或者取消事务，以及查询参与者的状态；同时还可以根据用户的商业逻辑允许取消部分参与者的工作而不影响整个事务的运行。

协调器为本系统管理和控制Web服务事务的协调中心，管理事务的运行。它又是由消息转发器、控制器和参与者资源三部分构成。消息转发器用来接收、解析、转发客户端向协调器发出的请求开始Web服务事务和提交事务的SOAP消息，解析消息类型，并将解析后的消息转发给参与者和协调器中的控制器进行处理。控制器接收到消息转发器转发的客户端请求Web服务事务的消息后，创建事务、登记参与者信息、解除登记信息、完成与参与者的两阶段提交过程，并向客户端报告事务结果。当参与者向协调器进行登记时，控制器将为参与者生成对应的参与者资源，存储在数据库中。在客户端向协调器提交事务时，由控制器和参与者资源进行交互，参与者资源再和参与者进行SOAP消息的传递。协调器部署在Web服务运行平台上，处理完成事务的大部分工作，对事务的生命周期进行管理，事务开始时创建参与者或者协调器实例，事务结束时销毁实例，从而简化事务客户端和参与者的工作。

参与者提供、参与Web服务事务并承担事务性工作。参与者将自己系统(如企业内的EAI等)的资源操作包装成Web服务，参与事务。为了保证各参与者资源的一致性，参与者使用两阶段协议向协调器提交协议。所谓两阶段是指协调阶段和事务阶段；

1)协调阶段：客户端发起一个新的Web服务事务后，协调器接收到消息后创建事务；客户端调用参与者操作，参与者接收到客户端的请求后向协调器登记事务。

2)事务阶段：即Web服务事务开始、执行、完成的全过程，由参与者和协调器共同完成。协调阶段后，参与者和协调器已互相知道对方的信息，开始进行事务阶段工作，在事务阶段完成后，协调器将事务结果向客户端报告。

参与者使用两阶段提交协议向协调器提交协议可以保证事务提交后，各参与者的工作完全提交，或者由于某些参与者不能提交，已经准备好的参与者可以将所做工作完全取消。

为了协助参与者完成Web服务，本发明Web服务事务处理系统提供了一组界面和类库，由开发事务性Web服务的程序员使用，可以方便的编写参与者Web服务。

考虑到管理事务的方便，如图1所示，本发明Web服务事务处理系统还包括一个事务监控管理器，对事务运行过程进行监控和管理。该监控管理器可以远程动态地监控正在运行的事务如实时查看事务运行时的状态等相关信息，同时还可以对事务进行配置管理，控制事务的最大并发数目，编写管理日志等，并将各种管理信息存储在数据库中。

在本发明Web服务事务处理系统中，监控管理器是提供给事务管理员的高级工具，相对比较独立；而客户端、协调器和参与者是系统必不可少的组成部分。从Web服务事务的运行过程分析可知，Web服务事务实际上就是这三部分之间进行协调和交互的过程；其中，由客户端发起事务、划分事务边界和提交事务，协调器管理和协调事务，参与者提供、参与Web服务事务。客户端仅仅需要发起事务、划分事务边界、提交或者取消事务，事务的主要工作由协调器和参与者交互完成；即事务由客户端发起，由协调器驱动完成，由协调器和参与者的两阶段提交过程保证事务的一致性。

图2为本发明Web服务事务处理系统工作过程图，即客户端、协调器和参与者三部分进行协调和交换的过程图，也就是本发明保证各事务之间的原子性、一致性和可靠性，并且对事务进行监控配置管理的处理方法。该Web服务事务处理方法包括两个阶段：

第一阶段：协调阶段，具体包括以下步骤：

1)客户端向协调器发出事务开始消息，要求开始一个原子Web服务事务，在该开始消息中指明事务类型是原子事务；

2)协调器在接收到该事务开始消息、创建新的事务后，向客户端发送包含有事务上下文内容的响应消息，事务上下文内容包含事务ID、事务类型、协调器地址、协调器ID等有关本次事务的信息；

3)客户端在得到响应消息后，调用参与者提供的Web服务操作，向各个参与者发送带有事务上下文内容的应用程序消息；

4)参与者接收到该应用程序消息后，根据事务上下文内容中协调器地址向协调器发送请求登记消息，要求登记；

5)协调器在登记了参与者的相关信息后发送登记完成消息，表示登记成功；

6)参与者登记成功后，向客户端发送可以执行应用程序的响应消息；

第二阶段：事务阶段，具体包括以下步骤：

1)客户端向协调器发送提交事务的消息，开始提交事务；

2)协调器向参与者发送准备消息，要求参与者准备；

3)参与者根据自己情况发送已准备好消息或取消准备消息或退出Web服务事务消息；

4)协调器根据接收到的各个参与者发出的消息做出决定提交或者取消事务的决定，并向参与者发送提交事务消息或者取消事务消息；

5)参与者根据接收到的协调器的指令进行确认或者取消，并向协调器发送确认提交消息，完成提交事务；或者向协调器发送取消Web服务响应消息，完成取消事务；或向协调器发送退出Web服务响应消息，退出事务；

6)协调器完成和参与者的两阶段提交后，向客户端报告事务运行的结果；

7)结束。

在事务阶段中，如果参与者都已经准备好(部分参与者可以选择退出事务)，那么事务将被提交，参与者所作的改动持久化。如果至少有一个没有准备好，那么事务将会取消。在事务阶段中，如果参与者的所做工作完全取消，则系统恢复到初始状态。使用两阶段提交保证了参与者所作的工作或者完全提交或者完全取消，从而保证了事务的原子性。事务运行时，各参与者的状态始终保持一致，事务提交后，参与者所作的工作都能持久化，从而保证事务的一致性和持久性。各参与者的运行是互相独立的，彼此意识不到对方的存在，从而保证事务的隔离性。

为了进一步详细说明本发明Web服务事务处理系统及处理方法，下面详细说明本发明的各个组成部分及主要功能。

客户端是一组程序集合，是一组类库，供Web服务事务的客户使用。开发者使用该类库可以编写包含Web服务的事务性应用程序，而不需要了解复杂的底层事务知识。用户通过执行开发者编写的Web服务事务性应用程序调用客户端，发起Web服务事务、调用事务性的参与者、划分事务边界、提交或者取消事务的功能。在发起事务前需要指明协调器的地址，每个客户端可向多个参与者请求提供Web服务，参与者包装了客户端调用的参与者Web服务的相关信息，例如参与者的地址、操作名字、调用方式、参数列表等。

如图3所示，客户端主要执行以下操作：

1)开始发起事务

客户端指定协调器地址后向协调器发送事务开始消息，接收返回事务上下文内容；如果执行出错，则抛出事务异常中止消息；如果正常，则往下执行；

2)设定各个参与者

详细指定各个参与者Web服务的地址、操作名字、调用方式、参数列表等；

3)调用各个参与者的Web服务操作，向参与者发送带有事务上下文内容的应用程序消息；如果执行过程出错，则抛出事务异常中止消息；如果正常，则往下执行；

4)客户端向协调器发送提交事务消息，执行成功，则事务已提交，运行结束；如果执行出错，则抛出事务异常中止消息，根据异常消息，可以得到出错原因；或者，

客户端取消事务，向协调器发送取消事务消息，执行成功，则事务已取消，运行结束；如果执行出错，则抛出事务异常中止消息，根据异常消息可以得到出错原因；

5)结束。

参与者的结构如图4所示，每个参与者由一个消息解析器、消息处理器和参与者上下文组成。消息解析器负责接收协调器、客户端发送的消息，并解析请求的消息，根据请求消息的种类调用消息处理器的操作。参与者上下文封装了参与者的相关信息，例如参与者的事务ID、地址、参与者ID、状态、协调器的地址等信息。在消息处理器具体处理消息时，需要使用参与者上下文的资料，处理完毕将结果消息交给消息解析器返回。

消息解析器提供在线消息操作做为消息入口，消息做为参数传入并进行解析。根据解析后的消息类型交给消息处理器处理并返回结果，例如准备消息解析后调用消息处理器的正准备操作。

参与者接收到客户端发送的请求Web服务的SOAP消息后，根据接收到的消息进行处理，并将结果返回。在运行过程中，参与者的状态时时发生变化，参与者的工作过程如图5所示，详细解释如下：

1)参与者处于创建完成状态，等待Web服务请求；

2)参与者接收客户端发送的请求Web服务消息后，开始向协调器进行登记

请求消息包含事务上下文内容，参与者提取事务上下文并生成参与者的上下文初始内容；根据事务上下文内容，参与者向协调器发送请求登记消息；

3)参与者处于等待登记状态；

4)参与者接收协调器发送的登记完成消息，处于登记完成状态，处理客户端的请求消息，向客户端发送可以执行应用程序的响应消息；

5)接受协调器发送的准备消息，开始准备

参与者向协调器登记完成后，就完成了两阶段提交的第一阶段，开始进行两阶段提交的第二阶段；协调器在接收到客户端提交事务的请求后，向参与者发送准备消息；参与者在接收到准备消息后处于正在准备状态；

6)参与者执行准备操作，根据操作返回结果

(1)无法完成准备，则发送取消消息，参与者放弃/终止此次Web服务事务，结束；

(2)参与者想退出事务，则返回退出消息，参与者退出此次Web服务事务，结束；

(3)准备完成，则返回已准备好消息，参与者处于已准备好状态；

7)参与者准备完毕

(1)参与者接收到协调器发送的开始提交事务的消息，开始提交事务，如果成功，参与者向协调器发送已提交消息，结束；如果出错，参与者向协调器发送出错消息，结束；

(2)参与者接收到协调器发送的取消提交事务的消息，开始取消所作的工作，向协调器发送已取消消息，结束；如果出错，参与者向协调器发送出错消息，结束。

协调器的结构如图6所示，协调器包括消息转发器、控制器和参与者资源三部分；消息转发器又包括消息解析器和消息处理器，控制器又包括两阶段提交控制器和协调器上下文。消息解析器负责解析接收到的消息，解析后的消息交给消息处理器进行处理。协调器上下文包含了协调器的地址、事务ID、协调器ID、状态等信息以及参与者资源的引用列表，每个参与者登记到协调器中生成一个参与者资源，由协调器上下文负责维护。协调器在接收到客户端提交事务的请求后，消息处理器调用两阶段提交控制器，由两阶段提交控制器具体完成事务提交的工作。在处理过程中，两阶段提交控制器需要和协调器上下文、参与者资源进行交互，查询所需的信息并更新相关信息。

协调器上下文定义了协调器的相关信息。该类包含了协调器的地址、事务ID、协调器ID、状态、参与者列表等字段，并提供对这些字段设置、更改的操作。协调器创建事务时会生成协调器上下文，在事务运行过程中更新其中字段。

参与者向协调器发送请求登记消息后，协调器会生成一个对应的参与者资源对象，并将该参与者资源的引用插入到协调器的参与者列表中。参与者资源相当于参与者在协调器中的代理，它包含参与者的相关信息，例如参与者的地址、ID、状态等，同时封装了与参与者Web服务的具体交互操作。

两阶段提交控制器处理协调器和参与者的两阶段提交过程。协调器在接收到客户端提交事务的请求后，根据协调器上下文中的参与者列表，依次向登记的参与者发送指令消息，并根据参与者的响应消息，更新协调器上下文中的协调器状态以及参与者列表中的参与者状态。

协调器的具体运行过程如图7所示，其具体步骤如下：

1)开始

2)协调器接收客户端发送的事务开始消息，事务开始消息中指明事务类型是原子事务，协调器处于开始状态；

3)协调器开始创建事务，生成协调器上下文，并构造事务上下文和已开始消息返回，事务已经创建，协调器处于已开始状态；

4)协调器接收到参与者的请求登记消息后，在协调器上下文中的参与者列表中添加该参与者的信息；

5)协调器接收到客户端提交事务的请求消息后，处于准备状态，向登记的每个参与者发送准备消息；

6)收集参与者的响应消息，并判断：

a)如果所有的参与者都响应退出消息则参与者全部退出事务，事务处于退出状态，执行第9步；

b)如果参与者响应已准备好消息，则表示参与者投票赞成提交事务，事务处于已准备好状态；往下执行

c)如果至少有一个参与者响应取消消息，则表示参与者没有准备好提交事务，事务处于放弃/终止状态；往下执行

7)协调器根据事务状态，作出决定

a)假如事务处于已准备好状态，则协调器向登记的参与者依次发送提交事务消息要求参与者提交事务，协调器处于等待提交状态，往下执行第8步；

b)假如事务处于放弃/终止状态，则协调器向登记的参与者依次发送取消消息要求参与者取消事务，协调器处于等待取消状态，往下执行第8步；

8)处于等待提交状态的协调器，如果所有参与者响应确认提交消息，则协调器处于提交完毕状态，执行第9步；如果至少有一个响应退出消息，则协调器处于异常状态，事务异常中止，执行第9步；

处于等待取消状态的协调器，如果所有参与者响应取消消息，则协调器处于取消状态，执行第9步；如果至少有一个响应退出消息，则协调器处于退出状态，事务异常中止，执行第9步；

9)根据事务的运行结果向客户端报告：如果事务已提交，返回事务提交完毕消息；如果事务已取消，返回事务取消完毕消息；如果异常中止，返回退出消息，指明错误原因。

本发明监控管理器作为一个独立的可视化工具提供给事务管理员，可以远程动态地监控管理事务的运行，从而极大地方便了管理员。

管理控制台使用Java管理扩展框架(JMX)结构对运行时容器进行管理。

启动管理控制台时，选择Web服务监控管理插件并指定需要监控的事务协调器主机地址，插件连接到服务器则监控管理工具就可以运行了。

1监控功能：

1)显示正在运行事务的信息，例如事务的ID、状态等等

2)显示事务的协调器的信息，例如协调器地址、类型、状态等等。

3)显示事务的参与者的相关信息，例如参与者的ID、地址、状态等。

4)提供定时刷新、删除运行完成的事务信息等其它操作。

2.管理和配置功能：

1)设置事务运行的最大并发数目。

2)设置是否使用一阶段提交进行优化。

3)日志的管理。

监控管理工具提供友好的操作界面，事务管理员可以远程动态地监控管理正在运行的事务，具有很强的实用性。

下面以一个预定旅游服务为例，对本发明Web服务事务处理系统的应用场景进行简要介绍。

假设一旅客要到某个城市旅游，他需要预定到该城市的飞机票，到机场的出租车以及该城市旅店的房间。航空公司提供预定飞机票的服务，旅馆提供预定房间的服务，出租车公司提供预定出租车的服务。要达到这个目的，旅客需要对飞机票、出租车和房间的预定全部成功，如果某个预定失败，比如预定客房的服务失败，则已经预定的机票和出租车服务应该能够取消，因为旅客此时已经无法按照本次预定计划旅游了，那么他预定其他服务的付费应该能够得到补偿，另一方面他取消预订的机票和出租车应该可以被新的旅客预订。即本次旅游预定的三个服务或者全部成功，游客正常出游，或者三个服务预定全部失败，旅客和服务公司的权益都得到保障。

在上面这个应用场景中，可以使用Web服务事务处理系统解决。如图8所示，航空公司使用参与者类库开发出预定飞机票的Web服务，包装了预定机票的企业内应用程序，提供名字为bookFlight的操作接口由用户调用。同理，出租车公司开发出预定出租车的Web服务，提供操作接口bookTaxi；旅店开发出预定房间的Web服务，提供操作接口bookRoom。对Web服务的请求消息中需要包含用户的个人信息，预定成功后企业内部的数据库中增加一条记录。同时，旅行社代理提供一个协调器Web服务做为事务的协调中心。

用户使用本发明Web服务事务处理系统(简称WSTPS)的客户端类库按照自己的商业逻辑编写事务性应用程序，首先指明协调器的地址后开始一个原子事务，接着依次调用航空公司、旅馆和出租车公司提供的操作bookFlight、bookRoom、bookTaxi，将个人信息作为请求参数传入，最后提交事务。用户不需要了解协调器和参与者Web服务的复杂的交互过程，某个服务调用失败后也不需要自己取消其它操作，这由系统内部完成.

使用WSTPS用户可以保证预定机票、房间和出租车结果的一致性和可靠性。比如旅客首先调用预订机票服务，应用程序客户端开始一个事务活动，新建协调器实例，该服务作为参与者向协调器登记，该服务被客户端正常调用，返回预定成功结果，下一步旅客调用预订出租车服务，该服务作为参与者向协调器登记，被客户端调用，也返回预定成功结果；最后一步旅客调用预订客房服务，该服务作为参与者向协调器登记，如果该服务被成功被调用，则本次事务活动成功结束，旅客可以按照计划出游。但如果在服务执行过程中服务由于某种原因没有正常被调用，比如客房已满，或者网络故障。那么这时该参与者就要通知协调器本次调用失败。协调器得到该消息后，通知其它的预订机票和出租车服务，并调用他们的补偿方法，保证旅客提交的银行帐户金额恢复到初始状态，并释放从前预定给该旅客的机票和座位，使其为新的旅客所用。至此一次失败事务活动完成。另外如果有多个航空公司(或者旅店、出租车公司)提供预定类似的服务。那么用户可以开始一个组合事务，选择最优的参与者Web服务进行提交，例如提交价格最低的服务，并取消其它服务。组合事务可以更好地满足商业逻辑的灵活性，适应复杂的商业世界。

在基于Web服务的工作流系统中，一个完整的业务流程通常由多个Web服务所构成。根据相应的控制链、数据链和转移条件，工作流引擎通过逐个调用流程中的Web服务来完成该业务流程的执行。业务流程通常使用标准的流程语言编写，本文以业务流程执行语言(Business Process Execution Language forWeb服务，简称BPEL)为例，介绍WSTPS在Web服务工作流中的应用。

BPEL可以包含多个活动，某些关键活动需要保证其可靠性和一致性，因此需要事务支持。通过扩充BPEL语法，使得BPEL具有以下事务性语义：

1)事务的创建。

增加businessTransaction元素，transactionName属性指明了事务名字，BPEL流程可以包含多个事务，通过名字加以区分。action属性指明应采取的动作，属性值是begin表示开始一个事务，type属性表示要创建的事务类型，可选值是atom(表示原子事务)或者cohesion(表示组合事务)。如下所示。

           <businessTransaction transactionName＝″myTrans″action＝″begin″

type＝″atom|cohesion″/>

事务上下文的接收和传播事务可以传播到参与流程的活动中，活动调用

远程的Web服务，远程Web服务做为参与者参与到事务中去。如下所示，

在invoke元素中增加transactionName属性表示参与的事务的名字。

    <invoke partner＝″publisher″portType＝″publishing:publisherPT″transactionName＝″

myTrans″

               operation＝″booking″inputVariable＝″bookRequest″

name＝″invokePublisher″>

2)事务的提交或者取消。

事务最后需要提交或者取消，使用businessTransaction元素加以表示。transactionName属性表示需要提交或者取消的事务名字，action属性表示提交或者取消的动作，属性值confirm表示提交事务，cancel表示取消事务。outputVariable属性值表示提交或者取消事务的结果。如下所示。

  <businessTransaction transactionName＝″myTrans″action＝″confirm|cancel″

outputVariable＝″transactionResult″/>

对于组合事务，可以根据流程的需要指定提交或者取消的参与者Web服务，如下所示，增加participants属性值指明需要提交或者取消的参与者名字。

 <businessTransaction transactionName＝″myTrans″action＝″confirm|cancel″

outputVariable＝″transactionResult″participants＝″.....″/>

3)BPEL流程本身可以参与事务。

BPEL流程本身做为一个Web服务发布，对外界来说和普通的Web服务没有区别。同样，BPEL流程本身也可以做为一个参与者参与到事务中，因此能够接收事务上下文并进行处理。如下所示，在receive元素中增加businessTransactionContext属性，存放接收到的事务上下文。

     <receive partnerLink＝”customer”portType＝”SP:purchasingPT”

operation＝”purchase”variable＝”PO”

                          businessTransactionContext＝”receivedContext”>

        …

       </receive>

在BPEL流程接收到事务上下文后需要向指定的事务协调器登记，并接收协调器的指令消息，例如Confirm或者Cancel消息。因此增加confirmHandler和cancelHandler元素，流程接收到confirm或者cancel消息后执行对应的handler。如下所示：

     <confirmHandler>

        <invoke partnerLink＝”existing服务”...

                operation＝”confirm”

                inputVariable＝”reservationConfirmation”/>

     </confirmHandler>

     <cancelHandler>

<invoke partnerLink＝”existing服务”...

                  operation＝”cancel”

                  inputVariable＝”reservationCancellation”/>

       </cancelHandler>

用户根据自己的商业逻辑编写完具有事务性语义的BPEL流程文件后，需要BPEL引擎解释执行流程文件。引擎在解析BPEL文件后创建流程实例按流程顺序依次执行结构化活动，调用流程中的Web服务。BPEL文件由于增加了事务性语义，引擎遇到有关事务的声明后根据事务性标签的不同调用WSTPS的客户端类库进行处理。

如图9所示，引擎在执行BPEL流程文件时，遇到businessTransaction元素，如果事件(action)属性值是开始(begin)，则使用客户端类库指明协调器地址后创建一个新的事务，并得到事务上下文。遇到带有transactionName属性的invoke元素，则向合作方Web服务(参与者)发送带有事务上下文的请求消息。遇到事件属性值是确认或者取消businessTransaction元素时则提交或者取消该事务，并得到事务运行结果。

BPEL引擎解释执行带有事务性标签的BPEL流程文件，根据不同的标签调用客户端类库，不需要了解协调器和参与者Web复杂的交互过程，从而专注于流程的执行，具体的事务性工作则由WSTPS系统进行处理。参与者Web服务由开发Web服务的程序员使用参与者类库编写。事务协调器可以独立存在，既可以部署在BPEL引擎所在主机也可以根据需要部署在其它主机上，从而减轻了引擎的负担，体现了分布式特性。BPEL引擎使用WSTPS系统支持事务处理，最大程度地减少了对引擎的修改，又具有一定的灵活性，为Web服务工作流事务处理提供了较好的解决方案。

本发明的特点是：

1)为了保证WSTPS的通用性和规范性，WSTPS需要支持标准的Web服务事务协议。在这里采用OASIS组织制定的BTP规范，各方交互的消息格式按照规范格式进行定义。

2)使用两阶段提交协议保证事务的原子性和一致性。本发明采用两阶段提交协议，可以使事务的参与方既支持资源锁定的方式也支持资源补偿的方式，从而对参与方不同的资源处理方式进行支持。

3)具有事务监控配置管理的高级功能，因此需要提供一个可视化的工具，使管理员可以方便地对WSTPS进行配置管理，也可以监控正在运行的事务。

4)支持BTP规范提出的原子事务和组合事务。原子事务的所有参与方的工作或者完全提交或者完全取消，组合事务的参与方的工作可以根据用户的商业逻辑允许部分参与放的工作取消而整个事务可以继续运行。原子事务是最基本最常见的事务类型，而组合事务使得Web服务事务更加灵活，从而适应更复杂的商业逻辑需求。

5)支持事务的嵌套，不论原子事务还是组合事务允许包含任意层次的子事务。嵌套事务可以将复杂的事务分成多个子事务，运行在不同的机器上从而增强了事务的模块化，提高了并发性能。

以上所述是本发明的具体实施例及所运用的技术原理，任何基于本发明技术方案基础上的等效变换，均属于本发明保护范围之内。

Claims (10)

1、一种Web服务事务处理系统，其特征在于：它包括客户端、协调器和多个参与者三部分，彼此之间通过互联网相连；其中，参与者作为Web服务提供者，协调器作为协调、处理者部署在Web服务运行时的平台上，并使用两阶段提交协议进行交互；

所述客户端是一组程序集合，用户通过客户应用程序调用客户端，发起Web服务事务、调用事务性的参与者、划分事务边界、提交或者取消事务；同时根据用户的商业逻辑允许客户端取消部分参与者的工作而不影响整个事务的运行；

所述协调器为本系统管理和控制Web服务事务的协调中心，通过使用两阶段提交协议管理事务的运行；

所述参与者提供、参与Web服务事务并承担事务性工作；参与者将自己系统的资源操作包装成Web服务，参与事务；参与者使用两阶段提交协议向协调器提交协议；

所述两阶段提交协议包括协调阶段和事务阶段；

协调阶段指客户端发起一个新的Web服务事务后，协调器接收到消息后创建事务；客户端调用参与者操作，参与者接收到客户端的请求后向协调器登记事务；

事务阶段指Web服务事务开始、执行、完成的全过程，由所述协调器和参与者完成；协调阶段后，参与者和协调器已互相知道对方的信息，开始进行事务阶段工作，在事务阶段完成后，协调器将事务结果向客户端报告。

2、根据权利要求1所述的Web服务事务处理系统，其特征在于：所述协调器为本系统管理和控制Web服务事务的协调中心，管理事务的运行，它由消息转发器、控制器和参与者资源三部分构成；其中

所述消息转发器又包括消息解析器、消息处理器；所述控制器包括两阶段提交控制器、协调器上下文；

消息解析器负责解析接收到的消息，解析后的消息交给消息处理器进行处理；

协调器上下文包含了协调器的地址、事务ID、协调器ID、状态信息，以及参与者资源的引用列表，每个参与者登记到协调器中生成一个参与者资源，由协调器上下文负责维护；

协调器在接收到客户端提交事务的请求后，消息处理器调用两阶段提交控制器，由两阶段提交控制器具体完成事务提交的工作。

3、根据权利要求2所述的Web服务事务处理系统，其特征在于：所述参与者由一个消息解析器、消息处理器和参与者上下文组成；

消息解析器负责接收协调器、客户端发送的消息，并解析请求的消息，根据请求消息的种类调用消息处理器的操作；

参与者上下文封装了参与者的相关信息；

在消息处理器具体处理消息时，需要使用参与者上下文的资料，处理完毕将结果消息通过消息解析器返回给协调器；

消息解析器使用两阶段提交协议向所述协调器提交协议。

4、根据权利要求1或2或3所述的Web服务事务处理系统，其特征在于：该系统还包括一个监控管理器，对事务运行过程进行监控和管理。

5、一种Web服务事务处理方法，它利用包括有客户端、协调器和多个参与者的Web服务事务处理系统，对基于开放式网络、松耦合环境中的多个Web服务事务进行协调、管理和控制；其中，由客户端发起事务、划分事务边界和提交或取消事务，协调器管理和协调事务，参与者提供、参与Web服务事务；其特征在于：

所述协调器和参与者之间通过两阶段提交协议保证各事务之间的原子性、一致性和可靠性，并且对事务进行监控配置管理；

所述两阶段提交协议包括协调阶段和事务阶段；

所述协调阶段指客户端发起一个新的Web服务事务后，协调器接收到消息后创建事务；客户端调用参与者操作，参与者接收到客户端的请求后向协调器登记事务；

所述事务阶段指Web服务事务开始、执行、完成的全过程，由协调器和参与者共同完成；协调阶段后，参与者和协调器已互相知道对方的信息，开始进行事务阶段工作，在事务阶段完成后，协调器将事务结果向客户端报告。

6、根据权利要求5所述的一种Web服务事务处理方法，其特征在于：所述协调阶段具体包括以下步骤：

1)客户端向协调器发出事务开始消息，要求开始一个原子Web服务事务，在该开始消息中指明事务类型是原子事务；

2)协调器在接收到该事务开始消息、创建新的事务后，向客户端发送包含有事务上下文内容的响应消息，事务上下文内容包含事务ID、事务类型、协调器地址、协调器ID；

3)客户端在得到响应消息后，调用参与者提供的Web服务操作，向各个参与者发送带有事务上下文内容的应用程序消息；

4)参与者接收到该应用程序消息后，根据事务上下文内容中协调器地址向协调器发送请求登记消息，要求登记；

5)协调器在登记了参与者的相关信息后发送登记完成消息，表示登记成功；

6)参与者登记成功后，向客户端发送可以执行应用程序的响应消息。

7、根据权利要求5或6所述的一种Web服务事务处理方法，其特征在于：所述事务阶段具体包括以下步骤：

1)客户端向协调器发送提交事务的消息，开始提交事务；

2)协调器向参与者发送准备消息，要求参与者准备；

3)参与者根据自己情况发送已准备好消息或取消准备消息或退出Web服务事务消息；

4)协调器根据接收到的各个参与者发出的消息做出决定提交或者取消事务的决定，并向参与者发送提交事务消息或者取消事务消息；

5)参与者根据接收到的协调器的指令进行确认或者取消，并向协调器发送确认提交消息，完成提交事务；或者向协调器发送取消Web服务响应消息，完成取消事务；或向协调器发送退出Web服务响应消息，退出事务；

6)协调器完成和参与者的两阶段提交后，向客户端报告事务运行的结果；

7)结束。

8、根据权利要求5所述的一种Web服务事务处理方法，其特征在于：所述客户端执行以下操作：

1)开始发起事务

客户端指定协调器地址后向协调器发送事务开始消息，接收返回事务上下文内容；如果执行出错，则抛出事务异常中止消息；如果正常，则往下执行；

2)设定各个参与者

详细指定各个参与者Web服务的地址、操作名字、调用方式、参数列表；

3)调用各个参与者的Web服务操作，向参与者发送带有事务上下文内容的应用程序消息；如果执行过程出错，则抛出事务异常中止消息；如果正常，则往下执行；

4)客户端向协调器发送提交事务消息，执行成功，则事务已提交，运行结束；如果执行出错，则抛出事务异常中止消息，根据异常消息，可以得到出错原因；或者，

客户端取消事务，向协调器发送取消事务消息，执行成功，则事务已取消，运行结束；如果执行出错，则抛出事务异常中止消息，根据异常消息可以得到出错原因；

5)结束。

9、根据权利要求5或8所述的一种Web服务事务处理方法，其特征在于：所述参与者执行以下操作：

1)参与者处于创建完成状态，等待Web服务请求；

2)参与者接收客户端发送的请求Web服务消息后，开始向协调器进行登记

请求消息包含事务上下文内容，参与者提取事务上下文并生成参与者的上下文初始内容；根据事务上下文内容，参与者向协调器发送请求登记消息；

3)参与者处于等待登记状态；

4)参与者接收协调器发送的登记完成消息，处于登记完成状态，处理客户端的请求消息，向客户端发送可以执行应用程序的响应消息；

5)接受协调器发送的准备消息，开始准备

参与者向协调器登记完成后，就完成了两阶段提交协议的第一阶段，开始进行两阶段提交协议的第二阶段；协调器在接收到客户端提交事务的请求后，向参与者发送准备消息；参与者在接收到准备消息后处于正在准备状态；

6)参与者执行准备操作，根据操作返回结果

(1)无法完成准备，则发送取消消息，参与者放弃/终止此次Web服务事务，结束；

(2)参与者想退出事务，则返回退出消息，参与者退出此次Web服务事务，结束；

(3)准备完成，则返回已准备好消息，参与者处于已准备好状态；

7)参与者准备完毕

(1)参与者接收到协调器发送的开始提交事务的消息，开始提交事务，如果成功，参与者向协调器发送已提交消息，结束；如果出错，参与者向协调器发送出错消息，结束；

(2)参与者接收到协调器发送的取消提交事务的消息，开始取消所作的工作，向协调器发送已取消消息，结束；如果出错，参与者向协调器发送出错消息，结束。

10、根据权利要求9所述的一种Web服务事务处理方法，其特征在于：所述协调器执行以下步骤：

1)开始

2)协调器接收客户端发送的事务开始消息，事务开始消息中指明事务类型是原子事务，协调器处于开始状态；

3)协调器开始创建事务，生成协调器上下文，并构造事务上下文和已开始消息返回，事务已经创建，协调器处于已开始状态；

4)协调器接收到参与者的请求登记消息后，在协调器上下文中的参与者列表中添加该参与者的信息；

5)协调器接收到客户端提交事务的请求消息后，处于准备状态，向登记的每个参与者发送准备消息；

6)收集参与者的响应消息，并判断：

a)如果所有的参与者都响应退出消息则参与者全部退出事务，事务处于退出状态，执行第9步；

b)如果参与者响应已准备好消息，则表示参与者投票赞成提交事务，事务处于已准备好状态；往下执行

c)如果至少有一个参与者响应取消消息，则表示参与者没有准备好提交事务，事务处于放弃/终止状态；往下执行

7)协调器根据事务状态，作出决定

a)假如事务处于已准备好状态，则协调器向登记的参与者依次发送提交事务消息要求参与者提交事务，协调器处于等待提交状态，往下执行第8步；

b)假如事务处于放弃/终止状态，则协调器向登记的参与者依次发送取消消息要求参与者取消事务，协调器处于等待取消状态，往下执行第8步；

8)处于等待提交状态的协调器，如果所有参与者响应确认提交消息，则协调器处于提交完毕状态，执行第9步；如果至少有一个响应退出消息，则协调器处于异常状态，事务异常中止，执行第9步；

处于等待取消状态的协调器，如果所有参与者响应取消消息，则协调器处于取消状态，执行第9步；如果至少有一个响应退出消息，则协调器处于退出状态，事务异常中止，执行第9步；

9)根据事务的运行结果向客户端报告：如果事务已提交，返回事务提交完毕消息；如果事务已取消，返回事务取消完毕消息；如果异常中止，返回退出消息，指明错误原因。

Images