CN1956421A - Web服务消息可靠传递方法 - Google Patents

Abstract

一种保证Web服务消息可靠传递的方法，它通过采用对等双向的消息传递方式、持久化存储、消息确认和消息选择重发机制、可靠性特征定义和可靠性特征分级策略以及支持多种消息确认模式，保证Web服务消息的可靠传递。对等双向的传递方式是指消息传递的双方既作为消息的发送者、又作为消息的接收者，消息在对等的双方同时双向传递。持久化存储策略是指为每个结点均设置一发送消息缓冲区和接收消息缓冲区，用来存储发送和接收的消息，以便在***、网络故障恢复后，重新故障发生前的消息传输过程。消息确认和消息选择重发机制、可靠性特征定义以及支持多种消息确认模式是通过对消息可靠性特征的定义、消息标识ID的确认以及消息的重发保证消息的可靠传输。

Description

Web服务消息可靠传递方法

技术领域

本发明涉及一种保证Web服务消息可靠传递的方法。

背景技术

Web服务是使应用程序之间，可以运用与平台无关、与编程语言无关的方式进行相互通信的一项技术。由于Web服务采用的通信手段是消息传递，因此能否保证消息可靠地从发送方传送到接收方，就成为一个至关重要的问题。保证消息可靠传递的基本目标是在应用程序产生异常、***发生崩溃、网络出现故障时，仍能保证Web服务消息可靠地从发送方传送到接收方。具体地体现在：1、当***没有发生崩溃，但网络故障或异常间断出现时，仍能确保发送方应用程序产生的所有消息均被传递到接收方的应用程序；或者，2、当***发生崩溃或网络故障或异常持续出现时，在网络异常消除、崩溃恢复、故障排除之后，仍能确保在这些情况发生之前的所有即将发送的消息都可以被传递到接收方。为了实现将Web服务消息可靠地从发送方传送到接收方这一目标，需要在消息传递的过程中，采用保证Web服务消息可靠传递的方法。

国际上许多著名的IT技术公司，在其研发的产品中，为了实现Web服务消息的可靠传递，均采用了各自提出的保证消息可靠传递的方法。目前，这些方法主要有两种：

一种是由BEA，IBM，Microsoft，TIBCO等公司提出和倡导的，基于客户机/服务器(Client/Server)模式、通过生成消息标识(ID)的方法保证消息的可靠传递。该方法利用了事务处理技术中的一些算法，支持存在中介结点的消息寻址(WS-Addressing)方式。但是，由于该方法没有明确定义保证消息可靠传递的可靠性特征，因此，所有消息的传递只能遵循相同的可靠性标准，而相同的标准无法按照消息传递的实际需求，区分并提供不同级别的可靠性保证；另外，这种方法只能支持单一的消息传递模式，不能支持多种消息传递模式(如回调，轮询等模式)，因而无法对实际应用所需要的多种消息传递模式给予支持，致使可靠性保证只能适用于特定的消息传递模式；而且，该方法虽然对发生的故障和异常产生的错误信息进行了简单的分类，但是，分类并不足以使得发送方可以参照这些信息制定重新传输消息的策略，即该方法没有定义为了解决消息因故障而丢失的持久化存储方法。

另一种是由Sun，Fujitsu，Novell，Oracle等公司提出和倡导的，基于客户机/服务器模式，通过定义一些保证消息可靠传输的可靠性特征、生成消息标识(ID)以及接收方如何发出消息确认和错误信息的方法保证消息的可靠传输。但是，该方法同样也没有定义消息持久化存储的策略，因而也无法实现在出现网络异常或故障、***崩溃时，确保未传送的消息不会丢失；另外，该方法没有涉及消息寻址问题，因而只能处理没有中介结点的消息传递；而且，对于一些由于异常或故障而需要重新传递的消息，该方法也没有制定消息传递失败后，发送方如何根据接收方的反馈信息，间隔多少时间、如何重新传递消息的方法和策略。

国内的少数IT公司，如易达讯网络科技有限公司，深圳黎明网络公司等，也提出了一些保证消息传递的可靠性方法，但是这些方法大多基于传统的Java消息服务(即JMS，Java Message Service，由Sun公司开发的API，是J2EE的一部分)，而不是基于Web服务而提出的。

发明内容

鉴于上述原因，为了解决上述两种方法各自存在的部分缺点，本发明的主要目的是提供一种新型并且规范的保证Web服务消息可靠传递的方法。

为实现上述目的，本发明采用以下技术方案：一种Web服务消息可靠传递方法，该方法采用对等双向的消息传递方式进行消息传递；所谓对等双向的传递方式是指消息传递的双方中的任何一方，既作为消息的发送者、同时又作为消息的接收者，消息在对等的双方同时双向传递。

所述对等双向的消息传递方式具体步骤如下：

A、任意选择参与消息传递的两个结点；

B、两个结点源源不断向对方发送消息，此时两个结点的角色都是发送方；

C、过一段时间，两个结点开始分别接收到来自对方的消息，此时两个结点的角色都是接收方；

D、两结点一方面不断向对方发消息，同时也不断接收来自对方发送的消息，角色既是发送方，又是接收方；重复执行步骤B～D。

本发明还采用持久化存储机制，具体方法是：

A、在每个结点分别设置发送消息缓冲区和接收消息缓冲区；

B、由发送方产生的、即将发送的消息首先被保存在发送消息缓冲区中，然后再发送到接收方；已经接收到的消息首先被存放在接收消息缓冲区中，然后再传递给实际需要消息的应用***；

C、在每个结点，按一定时间间隔ΔT、以文件的形式，将发送消息缓冲区和接收消息缓冲区中的内容保存到磁盘上；

D、***发生故障时，恢复已经存储到磁盘上的发送消息缓冲区和接收消息缓冲区的内容，一旦故障排除、***恢复，便从已存储的文件中选择读取缓冲区的内容，继续执行发生故障前的消息传递过程。

本发明还采用消息确认和消息选择重发机制；在消息传递的过程中，***自动为每一条消息生成一个唯一的用于区分和确认每条消息的标识ID；

所谓消息确认机制是指发送方每发送一个包含有唯一标识ID的请求消息，接收方收到后都要向发送方发送相应的包含有唯一标识ID的确认消息，用于向发送方确认所发的消息已经到达，无论消息到达后，接收方的应用程序能否处理这个消息；

所谓消息选择重发机制是指发送方结合***和网络状况、以及来自接收方返回的确认消息，选择是否重新发送已经发送的消息；

具体的步骤如下：

A、发送方结点X向接收方结点Y发送请求消息ID＝i；

B、接收方结点Y收到请求消息ID＝i后，向发送方结点X发送确认消息ID＝i；

C、如果发送方一直没有收到接收方对此消息的确认消息，那么发送方将重新发送这个消息；

如果发送方接收到了确认消息，但是该确认消息表明接收方接收到的消息不完整或者出现不符合接收方要求格式的情况，发送方在一段时间ΔT后，选择重新发送这个消息；

如果确认消息表明接收方目前的缓冲区已满，无法接收更多的消息时，发送方将不再重新发送消息；

D、发送方收到接收方正确的确认消息后，重复执行上述步骤直到将全部请求消息发送完毕。

所述请求消息包括ID标识、时间特征、接收特征、数据体、是否为重传消息和确认模式字段；所述确认消息包括ID标识、时间特征、接收特征、数据体、反馈消息和确认模式字段；所述时间特征和接收特征为可靠性特征；其中，时间特征是指消息从发送方发送到接收方，接收方接收到消息后返回给发送方相应的确认消息的整个时间间隔；接收特征是指接收方需要确保接收到发送方发送的同一条消息的数目，具体分为四种情况：A、至少收到一次，即发送方发送的消息，接收方至少收到一次；B、至多收到一次，即发送方发送的消息，接收方至多收到一次；C、收到且仅收到一次，即发送方发送的消息，接收方收到且仅收到一次；D、按照消息唯一标识ID的次序收到消息。

在消息传递过程中，发送方和接收方均要对包含有所述可靠性特征的请求消息和确认消息作如下处理，具体步骤为：

A、针对每一条存放在发送消息缓冲区中的、即将发送的消息，分别指定它们的可靠性特征即时间特征和接收特征，指定者可以是最终用户，也可以是***采用自动预先设置的方式完成；

B、对于发送消息缓冲区中的消息，在规定时间即时间特征内返回确认消息的消息，则只需要从发送消息缓冲区中删除该消息即可；对于在规定时间内没有返回确认消息的消息，则发送方需要重新发送该消息；

C、对于接收消息缓冲区中的消息，对于收到的所有消息，需要向发送方发送相应的确认信息；如果接收到的消息的ID与先前收到的消息ID相同，则分析该消息的接收特征：

如果是情况A、至少收到一次，则把该消息继续保留在缓冲区中；

如果是情况B、至多收到一次，则把该消息从缓冲区中删除；

如果是情况C、收到且仅收到一次，则把该消息从缓冲区删除；

如果是情况D、按照ID次序收到消息，则把该消息从缓冲区删除，而且只有所有具有比该消息ID更小的消息都已经接收到后，该消息才允许被交付给实际需要该消息的应用程序。

所述消息确认的模式分为：同步响应、异步回调和轮询三种模式，其中轮询模式又细分为同步轮询和异步轮询两种模式；

所述同步响应消息确认模式是指在发送方发送消息给接收方的同一个网络连接上，返回接收方对该消息的确认消息；

所述异步回调消息确认模式是指发送方新建一个网络连接来发送请求消息给接收方，接收方在收到消息后，再新建一个网络连接，返回接收方对该消息的确认消息；

所述同步轮询消息确认模式是指发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自己的缓冲区，查找缓冲区中的消息是否满足确认请求消息中包括的ID值，并在这个确认请求消息所在的网络连接上，返回查询的确认结果；

所述异步轮询消息确认模式是指发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自己的缓冲区，查找缓冲区中的消息是否满足确认请求消息中包括的ID值，新建一个网络连接，将查询的结果发送给发送方。

本发明提出的保证Web服务消息可靠传递的方法是为消息的可靠性传递而提出的，它通过采用对等双向的消息传递方式，提高了消息传递的效率；通过提供持久化存储策略，提高了应用程序、***、网络发生故障、崩溃或异常发生时的处理能力；通过采用消息确认和消息选择重发机制，保证消息传递的完整过程，提升了故障处理能力；通过定义可靠性特征和特征分级策略，避免了所有消息传递使用相同的可靠性特征和方式进行传递，从而为消息传递提供了不同的可靠性支持，使得消息可以按照不同级别的可靠性特征来传递；通过支持多种消息确认模式，丰富了消息确认的途径和方式，从而更为灵活地支持了消息传递的可靠性。

附图说明

图1为本发明采用对等双向的传递方式进行消息传递的过程示意图

图2为本发明采用的消息确认和消息选择重发机制的示意图

图3为本发明带有可靠性特征的请求消息和确认消息的格式示意图

图4为本发明同步响应消息确认模式示意图

图5为本发明异步回调消息确认模式示意图

图6为本发明同步轮询消息确认模式示意图

图7为本发明异步轮询消息确认模式示意图

具体实施方式

本发明提供的保证Web服务消息可靠传递的方法主要应用于Web服务可靠消息传递***。本发明通过采用对等双向的消息传递方式、持久化存储策略、消息确认和消息选择重发机制、可靠性特征定义和可靠性特征分级策略以及支持多种消息确认模式，这五方面的技术控制Web服务消息传递的过程，保证Web服务消息的可靠传递。

下面依次介绍这五方面技术的具体实施方式：

一、对等双向的消息传递方式

本发明提出的保证Web服务消息可靠传递的方法规定Web服务消息传递按照对等双向的传递方式进行。所谓对等双向的传递方式是指消息传递的双方中的任何一方，既作为消息的发送者、同时又作为消息的接收者，消息在对等的双方同时双向传递。

如图1所示，为了描述方便，将传递消息的结点的角色用右下标标注，用左右方向键的始端表示发送方，末端表示接收方，具体步骤如下：

1、任意选择参与消息传递的两个结点X、Y；

2、两个结点源源不断向对方发送消息X_发送方→Y，Y_发送方→X，此时两个结点的角色都是发送方；

3、过一段时间，两个结点开始分别接收到来自对方的消息X_发送方←Y，Y_接收方←X；

4、此时，两结点一方面不断向对方发消息，同时也不断接收来自对方发送的消息，角色既是发送方，又是接收方X发送方，接收方，Y_{发送方，接收方}；

5、重复执行步骤2～4，从而实现了一种对等双向的传输方式。

本发明采用对等双向的消息传递方式，支持消息被同时双向传递，避免了在客户机/服务器模式下，发送方和接收方角色固定带来消息传递方向的局限和效率的下降，提高了消息传递的效率。

二、持久化存储

为了降低***、网络故障、崩溃对消息传递结果的影响，保证消息传递的可靠性，本发明采用了持久化存储机制，具体方法是：

1、由于本发明采用对等双向的传递方式进行消息传递，每个结点既是发送方，又是接收方，所以，本发明在每个结点分别设置发送消息缓冲区和接收消息缓冲区；

2、由发送方产生的、即将发送的消息首先被保存在发送消息缓冲区中，然后再发送到接收方；已经接收到的消息首先被存放在接收消息缓冲区中，然后再传递给实际需要消息的应用***；

3、在每个结点，按一定时间间隔ΔT、以文件的形式，将发送消息缓冲区和接收消息缓冲区中的内容保存到磁盘上；

4、***发生故障时，恢复已经存储到磁盘上的发送消息缓冲区和接收消息缓冲区的内容，一旦故障排除、***恢复，便从已存储的文件中选择读取缓冲区的内容，继续执行发生故障前的消息传递过程。

由于发送消息缓冲区和接收消息缓冲区的内容是按照一定时间间隔存储到磁盘上的，所以，当故障排除、***恢复后，只要将故障发生前某个时间点存储的文件重新调出，读取文件中发送消息缓冲区和接收消息缓冲区的内容，重新执行消息传递过程即可。

本发明在消息传递的过程中采用持久化存储机制大大降低了***、网络故障、崩溃对消息传递结果的影响，保证了消息传递的可靠性。

三、消息确认和消息选择重发机制

为了保证消息传递的可靠性，本发明在消息传递的整个过程中均采用了消息确认和消息选择重发机制。

在消息传递的过程中，***自动为每一条消息生成一个唯一的标识ID，用于区分和确认每条消息。

所谓消息确认机制是指发送方每发送一个包含有唯一标识ID的请求消息，接收方收到后都要向发送方发送相应的包含有唯一标识ID的确认消息，用于向发送方确认所发的消息已经到达，无论消息到达后，接收方的应用程序能否处理这个消息。

所谓消息选择重发机制是指发送方结合***和网络状况、以及来自接收方返回的确认消息，选择是否重新发送已经发送的消息。

具体的步骤如图2所示：

A、发送方结点X向接收方结点Y发送请求消息ID＝i；

B、接收方结点Y收到请求消息ID＝i后，向发送方结点X发送确认消息ID＝i；

C、如果发送方一直没有收到接收方对此消息的确认消息，那么发送方将重新发送这个消息；

如果发送方接收到了确认消息，但是该确认消息表明接收方接收到的消息不完整或者出现不符合接收方要求格式的情况，发送方在一段时间ΔT后，选择重新发送这个消息；

如果确认消息表明接收方目前的缓冲区已满，无法接收更多的消息时，发送方将不再重新发送消息；

D、发送方收到接收方正确的确认消息后，重复执行上述步骤直到将全部请求消息发送完毕。

本发明采用消息确认和消息选择重发机制保证了消息传递的可靠性，提升了***故障处理能力。

四、可靠性特征定义和可靠性特征分级策略

为了更准确地适应消息传递的可靠性需求，本发明提出了可靠性特征的定义和针对可靠性特征的分级策略，即把消息的特征明确定义出来，并根据这些特征，把需要传递的消息根据这些特征明确进行划分，避免所有消息传递使用相同的可靠性特征和方式，实现了可靠性特征的分级。

可靠性特征包括两个方面：时间特征和接收特征。其中，时间特征是指消息从发送方发送到接收方，接收方接收到消息后返回给发送方相应的确认消息的整个时间间隔。接收特征是指接收方需要确保接收到发送方发送的同一条消息的数目，由于***/网络故障的存在，确认消息可能丢失，发送方对于没有收到确认的消息需要重新传递，这就存在接收方可能收到发送方多次相同的消息，具体分为四种情况：A、至少收到一次，即发送方发送的消息，接收方至少收到一次；B、至多收到一次，即发送方发送的消息，接收方至多收到一次；C、收到且仅收到一次，即发送方发送的消息，接收方收到且仅收到一次；D、按照消息唯一标识ID的次序收到消息，即在情况C收到且仅收到一次的基础上，收到的消息按照ID序号递增(ID₁，ID₂，...，ID_K，...)的方式，在接收消息缓冲区中排序后，再递交给所需交付的应用程序。

图3为本发明请求消息和确认消息的格式。如图所示，每条请求消息都要包括ID标识、时间特征、接收特征、数据体、是否为重传消息和确认模式字段。每条确认消息都要包括ID标识、时间特征、接收特征、数据体、反馈消息和确认模式字段。

在消息传递过程中，发送方和接收方均要对请求消息和确认消息作如下处理，具体步骤为：

1、针对每一条存放在发送消息缓冲区中的、即将发送的消息，分别指定它们的可靠性特征即时间特征和接收特征，指定者可以是最终用户，也可以是***采用自动预先设置的方式完成；

2、对于发送消息缓冲区中的消息，在规定时间即时间特征内返回确认消息的消息，则只需要从发送消息缓冲区中删除该消息即可；对于在规定时间内没有返回确认消息的消息，则发送方需要重新发送该消息；

3、对于接收消息缓冲区中的消息，对于收到的所有消息，需要向发送方发送相应的确认信息；如果接收到的消息的ID与先前收到的消息ID相同，则分析该消息的接收特征：

如果是情况A、至少收到一次，则把该消息继续保留在缓冲区中；

如果是情况B、至多收到一次，则把该消息从缓冲区中删除；

如果是情况C、收到且仅收到一次，则把该消息从缓冲区删除；

如果是情况D、按照ID次序收到消息，则把该消息从缓冲区删除，而且只有所有具有比该消息ID更小的消息都已经接收到后，该消息才允许被交付给实际需要该消息的应用程序。

五、支持多种消息确认模式

为了更为灵活地支持消息传递的可靠性，本发明采用了多种消息确认模式，具体支持的消息确认模式分为：同步响应、异步回调和轮询三种模式，其中轮询模式又细分为同步轮询和异步轮询两种模式。

同步响应消息确认模式：在发送方发送消息给接收方的同一个网络连接上，返回接收方对该消息的确认消息，如图4所示。

异步回调消息确认模式：发送方新建一个网络连接来发送请求消息给接收方，接收方在收到消息后，再新建一个网络连接，返回接收方对该消息的确认消息，如图5所示。

轮询消息确认模式：细分为同步轮询消息确认模式和异步轮询消息确认模式两种

同步轮询消息确认模式：发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自己的缓冲区，查找缓冲区中的消息是否满足确认请求消息中包括的ID值，并在这个确认请求消息所在的网络连接上，返回查询的确认结果，如图6所示。

异步轮询消息确认模式：发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自己的缓冲区，查找缓冲区中的消息是否满足确认请求消息中包括的ID值，新建一个网络连接，将查询的结果发送给发送方，如图7所示。

本发明提出的保证Web服务消息可靠传递的方法与其它保证可靠消息传递方法相比，具有以下特点：

1、本发明提出的保证消息可靠传递的方法是一种基于Web服务提出的保证消息传递可靠性的方法，而不是传统的基于消息服务保证消息传递可靠性的方法。

2、本发明采用对等双向的消息传递方式，可以支持消息被同时双向传递，避免了在客户机/服务器模式下，发送方和接收方角色固定带来消息传递方向的局限和效率的下降，在保证可靠性的同时，提高了消息传递的效率。

3、本发明采用持久化存储策略，提高了应用程序、***、网络发生故障、崩溃或异常发生时的处理能力，提高了***的可靠性。

4、本发明采用消息确认和消息选择重发机制，保证消息传递的完整过程，提升了故障处理能力。

5、本发明通过定义可靠性特征和特征分级，避免了所有消息传递使用相同的可靠性特征和方式进行传递，从而为消息传递提供了不同的可靠性支持，使得消息可以按照不同级别的可靠性特征来传递。

6、本发明支持多种消息确认模式，丰富了消息确认的途径和方式，从而更为灵活地支持消息传递的可靠性。

Claims (7)

1、一种Web服务消息可靠传递方法，其特征在于：该方法采用对等双向的消息传递方式进行消息传递；所谓对等双向的传递方式是指消息传递的双方中的任何一方，既作为消息的发送者、同时又作为消息的接收者，消息在对等的双方同时双向传递。

2、根据权利要求1所述的Web服务消息可靠传递方法，其特征在于：所述对等双向的消息传递方式具体步骤如下：

A、任意选择参与消息传递的两个结点；

B、两个结点源源不断向对方发送消息，此时两个结点的角色都是发送方；

C、过一段时间，两个结点开始分别接收到来自对方的消息，此时两个结点的角色都是接收方；

D、两结点一方面不断向对方发消息，同时也不断接收来自对方发送的消息，角色既是发送方，又是接收方；重复执行步骤B～D。

3、根据权利要求1或2所述的Web服务消息可靠传递方法，其特征在于：本发明还采用持久化存储机制，具体方法是：

A、在每个结点分别设置发送消息缓冲区和接收消息缓冲区；

B、由发送方产生的、即将发送的消息首先被保存在发送消息缓冲区中，然后再发送到接收方；已经接收到的消息首先被存放在接收消息缓冲区中，然后再传递给实际需要消息的应用***；

C、在每个结点，按一定时间间隔ΔT、以文件的形式，将发送消息缓冲区和接收消息缓冲区中的内容保存到磁盘上；

D、***发生故障时，恢复已经存储到磁盘上的发送消息缓冲区和接收消息缓冲区的内容，一旦故障排除、***恢复，便从已存储的文件中选择读取缓冲区的内容，继续执行发生故障前的消息传递过程。

4、根据权利要求3所述的Web服务消息可靠传递方法，其特征在于：该方法还采用消息确认和消息选择重发机制；

在消息传递的过程中，***自动为每一条消息生成一个唯一的用于区分和确认每条消息的标识ID；

所谓消息确认机制是指发送方每发送一个包含有唯一标识ID的请求消息，接收方收到后都要向发送方发送相应的包含有唯一标识ID的确认消息，用于向发送方确认所发的消息已经到达，无论消息到达后，接收方的应用程序能否处理这个消息；

所谓消息选择重发机制是指发送方结合***和网络状况、以及来自接收方返回的确认消息，选择是否重新发送已经发送的消息；

具体的步骤如下：

A、发送方结点X向接收方结点Y发送请求消息ID＝i；

B、接收方结点Y收到请求消息ID＝i后，向发送方结点X发送确认消息ID＝i；

C、如果发送方一直没有收到接收方对此消息的确认消息，那么发送方将重新发送这个消息；

如果发送方接收到了确认消息，但是该确认消息表明接收方接收到的消息不完整或者出现不符合接收方要求格式的情况，发送方在一段时间ΔT后，选择重新发送这个消息；

如果确认消息表明接收方目前的缓冲区已满，无法接收更多的消息时，发送方将不再重新发送消息；

D、发送方收到接收方正确的确认消息后，重复执行上述步骤直到将全部请求消息发送完毕。

5、根据权利要求4所述的Web服务消息可靠传递方法，其特征在于：所述请求消息包括ID标识、时间特征、接收特征、数据体、是否为重传消息和确认模式字段；

所述确认消息包括ID标识、时间特征、接收特征、数据体、反馈消息和确认模式字段；

所述时间特征和接收特征为可靠性特征；其中，时间特征是指消息从发送方发送到接收方，接收方接收到消息后返回给发送方相应的确认消息的整个时间间隔；接收特征是指接收方需要确保接收到发送方发送的同一条消息的数目，具体分为四种情况：A、至少收到一次，即发送方发送的消息，接收方至少收到一次；B、至多收到一次，即发送方发送的消息，接收方至多收到一次；C、收到且仅收到一次，即发送方发送的消息，接收方收到且仅收到一次；D、按照消息唯一标识ID的次序收到消息。

6、根据权利要求5所述的Web服务消息可靠传递方法，其特征在于：在消息传递过程中，发送方和接收方均要对包含有所述可靠性特征的请求消息和确认消息作如下处理，具体步骤为：

A、针对每一条存放在发送消息缓冲区中的、即将发送的消息，分别指定它们的可靠性特征即时间特征和接收特征，指定者可以是最终用户，也可以是***采用自动预先设置的方式完成；

B、对于发送消息缓冲区中的消息，在规定时间即时间特征内返回确认消息的消息，则只需要从发送消息缓冲区中删除该消息即可；对于在规定时间内没有返回确认消息的消息，则发送方需要重新发送该消息；

C、对于接收消息缓冲区中的消息，对于收到的所有消息，需要向发送方发送相应的确认信息；如果接收到的消息的ID与先前收到的消息ID相同，则分析该消息的接收特征：

如果是情况A、至少收到一次，则把该消息继续保留在缓冲区中；

如果是情况B、至多收到一次，则把该消息从缓冲区中删除；

如果是情况C、收到且仅收到一次，则把该消息从缓冲区删除；

如果是情况D、按照ID次序收到消息，则把该消息从缓冲区删除，而且只有所有具有比该消息ID更小的消息都已经接收到后，该消息才允许被交付给实际需要该消息的应用程序。

7、根据权利要求5或6所述的Web服务消息可靠传递方法，其特征在于：所述消息确认的模式分为：同步响应、异步回调和轮询三种模式，其中轮询模式又细分为同步轮询和异步轮询两种模式；

所述同步响应消息确认模式是指在发送方发送消息给接收方的同一个网络连接上，返回接收方对该消息的确认消息；

所述异步回调消息确认模式是指发送方新建一个网络连接来发送请求消息给接收方，接收方在收到消息后，再新建一个网络连接，返回接收方对该消息的确认消息；

所述同步轮询消息确认模式是指发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自己的缓冲区，查找缓冲区中的消息是否满足确认请求消息中包括的ID值，并在这个确认请求消息所在的网络连接上，返回查询的确认结果；

所述异步轮询消息确认模式是指发送方在向接收方发送一定数目的消息后，对其发送的所有消息提出一个确认请求消息，接收方接收到这个确认请求后，轮询自己的缓冲区，查找缓冲区中的消息是否满足确认请求消息中包括的ID值，新建一个网络连接，将查询的结果发送给发送方。

Images