CN1812405B

CN1812405B - 在请求-响应传输协议上的可靠单向消息传送的方法

Info

Publication number: CN1812405B
Application number: CN2005101201668A
Authority: CN
Inventors: M·T·戴斯; R·D·希尔; R·T·利姆普兰切特; S·科恩; S·R·巴特雷斯
Original assignee: Microsoft Corp
Current assignee: Microsoft Technology Licensing LLC
Priority date: 2004-12-10
Filing date: 2005-11-10
Publication date: 2012-05-23
Anticipated expiration: 2025-11-10
Also published as: JP2006178961A; KR20060065487A; CN1812405A; US7349384B2; EP1670214A1; US20060129690A1; KR101201140B1

Abstract

各示例实施例提供RM协议和请求-响应传输协议(例如HTTP)之间的绑定机制。本发明发挥请求-响应传输协议的现有网络特征而不重新配置或使用新的基础结构服务。请求-回应传输模型本质上是非对称的，并提供两个数据流；请求流和回应流。当发起者是不可寻址的和/或通信需要请求-响应传输时，本发明允许基础结构和应用程序消息在请求流上发送，而确认和其它基础结构消息则可在传输的回应流上发送回去。

Description

在请求-响应传输协议上的可靠单向消息传送的方法

技术领域

本发明一般涉及例如web服务的分布式系统的可靠消息传递协议，尤其涉及提供在单向消息交换模式环境中分布式系统的可靠消息传递协议与请求-响应传输协议(例如HTTP)的绑定。

背景技术

通过使用电子消息使一台计算机或装置能经网络与另一计算系统通信，计算机网络已增强了我们传送并访问信息的能力。当在计算系统之间传送电子消息时，该电子消息常常通过协议堆栈传递，该协议堆栈对该电子消息内的数据执行操作(例如解析、路由、流控制等)。开放系统互联(OSI)模型是用于实现协议堆栈的网络框架的一个示例。

该OSI模型将传送电子消息的操作分解成7个独立的层，每个层被指定执行数据传送过程中的某些操作。尽管协议堆栈是可能实现每一层的，但是许多协议堆栈仅实现在网络上传送数据时使用的可选层。当从计算系统传输数据时，数据源自应用程序层，并往下传递给中间较低层，然后传送到网络。当从网络接收数据时，数据输入物理层，并往上传递给中间较高层，最后在应用程序层接收。应用程序层-最高层-负责支持应用程序和终端用户处理。此外，在应用程序层内可驻留若干其它层(例如简单开放访问协议(SOAP)层)。大多数协议堆栈所结合的另一层是传输层。传输层的一个示例是传输控制协议(TCP)。

Web服务(WS)是计算系统之间通信进步中的驱动力，并彻底转变了我们建立并使用软件的方法。Web服务使各应用程序共享数据，并且更强大地从其它其它应用程序中调用能力，而不管这些应用程序是如何建立的；它们在什么操作系统或平台上运行；以及使用什么装置来访问它们。Web服务借助工业标准协议在因特网上调用，这些工业标准协议包括SOAP、XML(可扩展标记语言)、UDDI(通用性、描述、发现和集成)、WSDL(Web服务描述语言)等。尽管Web服务保持彼此无关，但是它们可松散地彼此链接成执行特定任务的合作组合。

当前的WS技术提供发起者(例如客户机)和接受者(例如服务)之间的直接SOAP消息通信。在普遍的双向消息传递情形中，SOAP请求消息从发起者传送到接受者，并且作为响应发送SOAP回应消息。终端之间的另一通信变体是单向消息，其中发起者向接受者发送消息而没有响应。

新兴WS体系结构的关键优点是传送集成的可互操作方案的能力。然而，因为Web服务通过诸如因特网的不可靠信道提供来自不同企业、机构和其它服务供应商的各种服务，WS的可靠性变成日益重要的因素。WS的可靠性受若干因素的影响，包括但不限于：Web服务端点的可靠性、访问Web服务的信道的可靠性特征、性能和容错特征、以及Web服务可处理并发客户机访问的范围。

通过选择端点之间交换消息(例如SOAP消息)的可靠传输协议，来尝试完成Web服务的可靠消息传送。例如，诸如消息-队列的可靠消息传输可用来在发起者和接受者之间可靠地传送消息。通过将消息传送给跨越故障保持可靠性的队列并从该队列中读取消息，消息排队通信技术使不同系统上的应用程序能彼此通信。

尽管排队系统提供可用来可靠地运送SOAP消息的传输，这种系统有若干缺点。例如，这些系统提供非同步操作的方案，其中各请求(及可能响应)分开传送并处理。因此，这些系统通常在资源方面是重量级的；涉及多个中间体，它们具有持久的已处理消息存储器并具有在部署、编程模型和管理中大得多的复杂性。所有这些对可靠的直接传送是不必要的，并偏离了最小化等待时间的目标。此外，编程模型不直接支持请求-响应样式的编程或会话。因此，排队通信模型与当前的“交互式”Web服务模型不同，且不能解决关键的“相连”情形和“交互式”应用程序。例如，它不适合期望及时响应的情形，或者分布式-处理-环境需要在发起者和接受者之间共享的情形。

还有在基本上不可靠的传输协议上定义可靠传送层(例如可靠的HTTP或HTTPR)的尝试。然而，困扰该方案-以及排队方案-的共同问题是仅当特定的可靠传输协议用于发起者和接受者之间的通信时才能获得可靠的消息传送。Web服务的基本性质要求特定供应商平台、实现语言和特定传输协议的独立性。在一般情形中，发起者不能使用特定协议将消息直接传送给接受者(例如，接受者不支持该协议)，或者该消息在离开发送节点之后到达该目标节点之前需要通过多次转发。取决于特定转发中涉及的两个节点之间连接的性质，可能不得不选择不能提供可靠消息传送特征的适当传输协议。

中间体还可存在于协议堆栈的不同层上；因此，不提供完全的端对端可靠性。例如，传输协议可在低层中间体上提供可靠性(例如IP层中间体-例如IP路由器)。然而，传输协议可在SOAP中间体或应用程序层(例如HTTP代理)上结束。因此，传输协议不能提供该中间体上的可靠性，即在应用程序层上无端对端的可靠性。

最近，各种分布式系统的可靠消息传送协议(此后称为“RM协议”)提供对当前可靠的消息传送系统的上述缺点的解决方案。这些协议(例如Web服务(WS)的RM协议，包括WS-可靠消息传送、WS-可靠性等)是允许消息在出现软件组件、系统或网络故障时在端点应用程序之间可靠传送的传输不可知连接协议。因此，RM协议在发起者和接受者之间提供可靠的、端对端的、以及可能面向会话的通信的方案。

这些RM协议类似于TCP，因为TCP经因特网协议(IP)路由器和多个网络从TCP发送者向TCP接收者提供字节流的可靠的、仅只一次的按序传送。分布式系统的可靠消息传送协议也作同样的提供，并经多个中间体(包括传输和SOAP层中间体)、传输和连接提供消息(注意：传送单元是消息而不是字节)。尽管TCP和RM协议都是“可靠的”协议，但由于RM协议(以及更一般地SOAP层)驻留在OSI模型中的应用程序上，不管用来传送数据的是什么传输协议RM协议都能提供可靠的消息传送。因此，RM协议并不依赖于用来在端点之间传送消息的特定传输或其它协议。

尽管一些RM协议已出现了一段时间，但是这些协议规范仍然有若干缺点和缺陷。例如，分布式系统的可靠消息传送协议通常需要双向的消息交换；即，应用程序消息往一个方向传送，而基础结构确认往另一个方向传送。此外，有未经请求的接受者-到-发起者通信是不可能的情形；例如，当发起者在防火墙后面，并使用请求-响应传输协议(例如HTTP)连接(通过例如经HTTP代理的隧道效应)来与接受者通信时。然而，问题在能够将确认和其它基础结构消息发送给发起者时产生，因为发起者通常是不可寻址的和/或通信受限于请求-响应传输协议。因此，产生这样的需要，即通过提供请求-响应消息传送模式的传输，配合应用程序层消息以单向消息交换模式从发起者到接受者的可靠传送-以及双向的RM基础结构消息。

发明内容

分布式系统(例如Web服务)的当前可靠消息传送协议的所述缺陷和缺点通过本发明的示例实施例得以克服。各个示例性实施例通过发挥请求-响应传输协议的现有网络特征而不重新配置或使用新的基础结构服务，以在请求-响应传输协议上发送应用程序层消息时向分布式系统提供可靠的消息传送协议(RM协议，例如WS-可靠消息传送)。

在发起者计算装置上，示例实施例提供根据应用程序层消息的与接受者端点的可靠单向消息交换模式在发起者端点上创建应用程序层消息。然后该应用程序层消息根据分布式系统的可靠消息传送协议(RM协议)格式化。然后，应用程序层消息经请求-响应传输协议的请求流发送。相应的传输层响应消息在请求-相应传输的回应流上接收，并与RM协议基础结构信息链接以便遵从该RM协议。

从接受者计算装置，其它示例实施例提供以可靠的单向信息交换模式接收从发起者到接受者的应用程序层信息。该应用程序层消息经匿名请求-响应传输协议的请求流接收。此外，该应用程序层消息被标识为根据分布式系统的可靠消息传送协议(RM协议)格式化。RM协议基础结构信息然后与传输层响应链接，其中该基础结构信息对应于一个或多个应用程序层信息的可靠交换。然后，传输层响应经请求-响应传输协议的回应流发送，以便遵从RM协议。

本发明的其它特征和优点将在以下描述中陈述，且部分地将从描述中变得显而易见，或从本发明的实践中可获知。本发明的特征和优点可通过所附权利要求书特别指出的装置和组合来实现和获取。本发明的这些和其它特征将从以下描述和所附权利要求书中变得更为显而易见，或可由本发明的实践获知，如下所述。

附图说明

为了描述可获取本发明的上述和其它优点和特征的方式，对以上简述的本发明的更具体描述将参照附图中所示特定实施例提交。理解了这些附图仅描述了本发明的典型实施例并因此不被视为限制其范围，本发明通过使用以下附图以附加细节进行描述和解释：

图1A示出用于应用程序层消息在根据各示例实施例的请求-响应传输协议上的可靠单向交换模式的协议堆栈；

图1B示出在根据各示例实施例的请求-响应传输协议上可能的可靠单向消息序列交换的示图。

图2示出当在根据各示例实施例的请求-响应传输协议上发送应用程序层消息时，提供分布式系统的可靠消息传送协议的方法的流程图。

图3示出提供本发明的适当操作环境的示例系统。

具体实施方式

本发明涉及用于以单向消息交换模式在端点之间将分布式系统(例如Web服务)的可靠消息传送协议绑定到请求-响应传输协议(例如HTTP)的方法、系统和计算机程序产品。本发明各实施例可包括具有各种计算机硬件的专用或通用计算机，如下进行更详细地讨论。

本发明涉及分布式系统的可靠消息传送协议(下文中称为“RM”协议)的扩展，它描述允许消息在出现软件组件、系统或网络故障时能在分布应用程序之间可靠传送的协议。分布式系统(例如Web服务)的可靠消息传送协议便于消息从源(下文中称为“发起者”)到例如服务的目标(下文中称为“接受者”)的成功传输，并确保可检测错误条件。这些协议是传输不可知的，允许它们使用不同的网络传输技术来实现。此外，可靠消息传送协议的各种实现隐藏了来自应用程序的间歇通信故障，并在系统故障的情形中能提供可复原性。

如上所述，各示例实施例提供RM协议和请求-响应传输协议(例如HTTP)之间的绑定机制。本发明发挥请求-响应传输协议的现有网络特征而不重新配置或使用新的基础结构服务。请求-回应传输模型本质上是非对称的，并提供两个数据流；请求流和回应流。这种请求-回应模型限制了消息传送模式，从而响应消息仅可作为请求消息的答复并在该消息之后使用由请求提供的传输连接发送。请求-回应传输(例如SOAP传输)协议的一个典型示例是“匿名HTTP”，其中发起者是不可寻址的，并只能使用HTTP协议的回应流来接收消息。

各示例实施例利用这样的回应流来向发起者发送确认和其它基础结构消息。在此所述的匿名请求-响应传输协议的细节涉及任何发起者不可直接寻址的请求-回应传输协议(即无法发送未经发起者请求的消息)。然而，注意本发明并不限于匿名的请求-回应传输协议，而是应用于限于请求-向应传输协议的任何通信。因此，在此所述的请求-响应传输协议的任何特定使用仅用于说明性目的，并且除非明确声明并不是要限制或以其它方式缩小本发明的范围。

图1A示出用于在根据各示例实施例的请求-响应传输协议上的可靠单向消息交换模式的协议堆栈。应用程序层消息(未示出)可由发起者端点105在应用程序层115上根据例如Web服务协议的分布式系统协议产生。通常在Web服务中，应用程序层消息将是具有适当SOAP报头的SOAP消息。此外，该消息被视为是单向的，因为它通常包括用于在接受者端点110处理的输入操作；然而，没有应用程序层160的输出消息从接受者端点110回流到发起者端点105。

应用程序层消息将被传递给可靠消息传送层120，其中它根据RM协议(例如WS-可靠消息传送、WS-可靠性等)来格式化。在可靠消息传送层120上接收的消息135还存储在发起者缓冲区130中，用于在未接收到相应的确认消息时进行可能的重发，如下所述。然后应用程序层消息在请求-响应传输层125(例如匿名HTTP)的请求流145上发送，并在接受者端点110的传输层156上接收。该应用程序层消息被传递给可靠消息传送层155，其中将所接收的消息170存储在接受者缓冲区165中，用于随后在接受者端点110的应用程序层160上进行处理。

注意，单向线条从可靠消息传送层155画到应用程序层160，表示没有应用程序层160的消息会流向发起者端点105，因为发起者端点通常是不可寻址的和/或该通信需要请求-响应型的协议。然而，如前所述，各示例性实施例利用例如HTTP的典型请求-响应传输协议的回应流140的特征，来在请求-响应传输层156、125上发送确认响应(未示出)和其它基础结构消息。换言之，RM基础结构信息被链接到传输层响应消息或装载在该消息上。

此外，注意链接到传输层响应消息的基础结构信息可用若干不同方法来表征。例如，基础结构信息(例如确认响应)可产生并封装于传输层响应中，该响应然后在请求-回应传输协议的回应流140上运载。这类似于将传输层响应消息表征为在基础结构信息内格式化。当然，还有其它方法来表征如何使基础结构信息与传输层响应消息相链接。此外，有许多众所周知的方法来用基础结构信息封装或格式化传输层响应消息。因此，将基础结构信息链接到应用于本发明的传输层响应消息，应广泛地解释为包括任何类型的用于格式化该基础结构信息或将该信息装载在传输层响应消息上的过程。

不管基础结构信息如何链接到传输层响应并如何在回应流140对面的发起者端点105上接收，如果该基础结构信息是确认响应(例如由WS-可靠信息传送定义的确认消息)，则可靠消息传送层120将从发起者缓冲区130中移除适当的应用程序消息135。然而，注意，如果未接收到消息的确认，则发起者端点105可重新尝试以类似于上述的方式发送消息135(即通过使用根据RM协议的请求-响应传输来发起新的请求)。如果在一定时间限制、预定重新尝试次数、或任何其它的重新尝试策略管理机制之后仍未接收到确认，则可向应用程序层115提交故障通知。

注意，来自可靠消息传送层120、155的基础结构消息(例如创建序列或终止序列请求)可在任一方向上发送，但受请求-响应传输的限制。特别地，来自接受者端点110的基础结构消息仅可在发起者请求之后的传输层响应上出现。还要注意，传输请求消息还可包括应用程序层消息，以及基础结构(RM协议)信息(例如SOAP报头内的字段)。

如上所述，确认消息和其它基础结构消息需要在请求-回应传输的回应流140上发送。然而，如果接受者端点110接收应用程序层消息但决定不发送确认，则它仍应发送标准的传输层响应(例如零响应)，以遵从请求-响应传输协议。发起端点105不再从这种零响应中推断任何特定含义，除了传输层请求已完成，以及该响应流不再可由接受者端点110用于传送基础结构消息。例如，在HTTP情形中，接受者端点110可用HTTP 202OK、204无内容、或其它类似的HTTP层响应消息来作响应。注意，该响应不由RM基础结构处理，但是如果该RM基础结构需要知道它不应等待RM基础结构响应消息，则它可知道接收了传输层响应。

其它示例实施例支持RM序列会话的创建和使用，用来以根据RM协议的单向消息交换模式可靠地传送一个或多个消息。对创建序列会话的请求可在链接(例如链接到应用程序层消息)的请求流145上接收，而唯一的序列标识符通常立即在同一传输链接的回应流140上发送。然而，注意，有其它可用于本发明的创建序列会话的方法。例如，发起者端点105可产生唯一的序列标识符，并在请求中发送它，或者该唯一的序列标识符可在频带外发送。因此，任何众所周知的建立序列会话的方法可用于本发明，且对如何建立序列会话的任何特定引用仅用于说明性目的，并且除非明确声明并不是要限制或以其它方式缩小本发明的范围。

通常，序列确认应当在接收相应的应用程序消息时发送。换言之，不延迟和批处理序列的确认，各示例实施例提供应在消息及其确认之间使用的一一对应，即消息在请求流145上流动，且其确认在回应流140上接收。然而，注意批处理也可用于本发明。例如，在接收最后的消息指示之前-或甚至在接收最后的消息指示时-可经回应流140向发起者105发送一个批量确认。然而，如上所述，如果确认未立即发送，则标准的传输层响应仍然应发送给发起者105，以便遵从请求-响应传输协议的要求。

不管确认的类型是什么(即批量的或单独的)，确认都应在进入连接的回应流140上并且只在序列会话的那些回应流140上发送给发起者端点105。然而，发起者端点105可在新的请求-响应连接上发送消息(基础结构或应用程序层消息)，而无需等待先前发送消息的确认消息。发起者端点105因为若干原因想要发送消息而不接收确认。例如，发起者端点105可能想要重新尝试传送未经确认的应用程序层消息135。或者(或以及)，发起者端点105可能想要发送在接受者端点110批处理确认的假设下产生的新消息。此外，发起者端点105可能想要将基础结构消息发送给接受者端点110，然后向接受者端点110提供使用传输响应来传送确认的机会，这些确认可例如在故障传输响应中批处理或丢失。

其它示例实施例假设接受者端点110可丢弃它接收的应用程序消息并不确认它。如果对序列作了排序而消息是次序颠倒地接收的，或者因为缺少存储该消息的缓冲区空间(例如流控制)，或出于任何数量的其它理由，接受者端点110会选择这样做。然而，注意，接受者端点110应无论如何都用回应流140上的至少一个标准传输层响应来作出响应，以便遵从传输协议的要求。

还有其它的示例实施例提供终止匿名请求-响应传输协议上的已建立单向序列的能力。类似于上述的序列会话创建过程，终止序列的基础结构消息可在连接的请求流145上发送。终止序列消息可通过基础结构协议链接到应用程序层消息(例如作为报头字段)或作为基础结构消息。无论如何，接受者端点110通常将用为序列会话发送的最后一个消息的序列确认来作出回应(假设接收了序列会话的所有消息)，以便遵从RM协议。然而，如果出于任何原因接受者110未发送确认或其它基础结构消息，则至少应发送回应流140上的标准传输-响应，以便遵从传输协议。

图1B示出在根据各示例实施例的请求-响应传输协议上的可能RM协议消息序列交换的示图。如图所示，发起者端点105作出创建单向序列对话102的请求，并在匿名请求-响应传输的请求流上发送它。注意，从发起者端点105流到接受者端点110的箭头表示传输协议的请求流，其中从接受者端点110循环回发起者端点105的箭头表示请求-响应传输的回应流。此外，还要注意，对创建单向序列会话102的请求可包括在应用程序层消息内。

响应于创建单向RM协议序列会话102的请求，接受者端点110将在传输的回应流上把传输层响应104发送回发起者105。如该示例中所示，该传输层响应104包括RM基础结构信息，诸如单向RM序列会话的序列标识符108。换言之，在将发送传输层回应流上的响应之前，基础结构信息被链接到传输层响应。

然后，发起者端点105可利用序列标识符108来在随后的请求-响应传输连接的请求流上发送应用程序层信息106。每个信息应由消息标号114标识，用于排序和其它可靠的消息传送目的。当接受者端点110接收应用程序层消息106时，它通常用包括RM信息112的传输层响应104来作出响应。更具体地，RM基础结构信息112可包括一个或多个应用程序层信息的序列标识符108和确认128。

注意，传输层响应104不需要包括RM信息，而仅仅是标准的传输层响应。例如，如在下一交换中所示，发送包括序列标识符108和最后消息116的报头的应用程序层单向消息118(通常还包括未示出的消息标号)。在发起者端点105在传输的请求流上发送该消息之后，该实例中的接受者端点110用标准传输层零响应122在回应流上作响应。如上所述，可发送这种响应以遵从请求-响应传输协议。然而，注意在该实例中，为了遵从RM协议，接受者端点110最终仍应发送该消息的确认128。如上所述，如果在一定时间限制、预定重新尝试次数、或任何其它的重新尝试策略管理机制之后仍未接收到确认，则可向应用程序层提交故障通知。

假设最后消息的确认由发起者端点105接收，则在请求-响应传输协议的另一个请求流上发送包括序列标识符108的终止序列126。最后，在该示例中，接受者端点110用另一个传输层零响应124作响应。在该实例中，双方都考虑所终止的序列会话。还要注意，接受者端点110可不发送零响应124，而用终止序列消息126的确认来作出响应。

本发明还可根据包括功能步骤和/或非功能动作的方法进行描述。以下是对在实践本发明中执行的动作和/或步骤的描述。通常，功能步骤根据所完成的结果来描述本发明，而非功能动作则描述更具体的用来获取特定结果的行动。尽管功能步骤和/或非功能动作可以特定顺序进行描述和声明，本发明并不限于动作和/或步骤的任何特殊顺序或组合。此外，步骤和/或动作在权利要求的陈述-以及以下图2的流程图的描述-中的使用用来示出这些术语的所需特定使用。

图2示出本发明各个实例实施例的流程图。图2的以下描述有时将引用图1A和1B的相应元件。尽管可从这些示图中引用特定元件，但是这些元件仅用于说明性目的，并且除非明确声明并不是要限制或以其它方式缩小本发明的范围。

图2示出在请求-相应传输协议上发送应用程序层消息时提供RM协议的方法200的实例流程图。在发起者侧，方法200包括创建应用程序层消息的动作(205)。例如，发起者端点105可创建可靠单向消息交换模式的用于传送到接受者端点110的应用程序层消息。通常，发起者端点105不是可寻址的，即，应用程序层115消息通常将包括用于在接受者端点110上处理的输入信息，而没有从接受者端点110回流到发起者端点105的应用程序层输出160消息。当然，如前所述，基础结构消息(例如确认请求、创建序列、终止序列等)也可被链接到应用程序层消息115。

然而，注意，通常请求发起序列会话的基础结构消息(以及终止基础结构消息)并不链接到应用程序层消息上。实际上，通常创建序列会话通常由RM层120响应于来自应用程序层115的本地API调用(诸如CreateSession或Session.open)而创建。因此，如前所述，用于建立或发起序列会话(和/或终止序列会话)的任何特定过程仅用作说明性目的，并且除非明确声明并不是要限制或以其它方式缩小本发明的范围。

不管基础结构信息是否与应用程序层消息链接，方法200还包括根据RM协议格式化应用程序层消息的动作(210)。例如，发起者端点105上的可靠消息传送层120可格式化应用程序层消息，并在发起者缓冲区130中存储应用程序层消息135的副本以便重试。然后，方法200包括在传输请求流上发送应用程序层消息的动作(215)。即，例如，消息从可靠消息传送层120往下传递到请求-响应传输层125。然后该消息在请求流145上被发送给接受者端点110。请求-响应传输协议可以是匿名传输，例如匿名HTTP或其它类似的请求-响应传输协议。

无论如何，在接受者侧，方法200还包括在请求流上接收应用程序层消息的动作(225)。例如，接受者端点110可在请求-响应传输层156上接收请求流145上的应用程序层消息。然后，方法200还包括标识应用程序层消息根据RM协议格式化的动作(230)。此外，方法200包括将RM协议基础结构信息链接到传输层响应的动作(235)。例如，可靠消息传送层155可将应用程序层消息170存储在接受者缓冲区165中，用来由接受者端点110的应用程序层160进行随后的处理。然后，可靠消息传送层155可对应于从发起者105发送到接受者110的一个或多个应用程序层消息的可靠交换，将传输层响应链接到RM基础结构信息112。

链接到传输层响应的基础结构信息可以是表示接受者已可靠地接收了一个或多个应用程序层消息的确认响应。该确认响应可包括对在请求流上发送的应用程序层消息的确认响应。此外，格式化的应用程序层消息可根据RM协议被链接到确认请求。在该实例中，确认响应是对确认请求的回应。或者，在应用程序层消息被链接到创建单向序列会话的请求的情形中，RM信息可以是序列标识符108。

在格式化传输层响应之后，方法200包括在响应流上发送传输层响应的动作(240)。类似地，在发起者侧，方法200还包括在回应流上接收相应的传输层响应的动作(220)。例如，接受者端点110在回应流140上发送传输层响应(例如104、114)并在发起者端点105上接收。然后从传输层响应中提取RM或基础结构层的响应，并将其给予RM层120。该RM层120从发起者缓冲区130中删除消息135的副本。

其它示例实施例规定，在发送应用程序层消息之前，由唯一的序列标识符表示的单向序列会话在发起者105和接受者110之间建立。因此，应用程序层消息将包括该唯一的序列标识符。然后，包括该唯一序列标识符的后续消息可根据RM协议格式化，并在请求-响应传输的请求流145上发送。该后续消息可在接收到对应于最初应用程序层消息的确认响应之前发送。然后，在发起者105上接收请求-响应传输的回应流140上的后续传输层响应。

还有其它的实施例规定后续消息是应用程序层消息，它包括用于在接受者端点110上处理的输入信息，而没有回流到发起者端点的应用程序层输出信息。在该实施例中，后续传输层响应可被链接到RM协议基础结构信息112，该信息112包括表示接受者端点110已接收到至少后续的应用程序层消息的确认响应128。

在后续消息是包括终止序列单元126的RM协议基础结构消息的情形中，可发送后续传输层响应以便遵从请求-响应传输协议，例如零响应124。或者，传输层响应可包括RM协议基础结构信息，它是表示接受者110已接收到序列会话中最后的应用程序层消息的确认响应128。

另外的实施例规定，传输协议可以是HTTP，且其中后续传输层响应是为了遵从请求-响应传输协议而发送的HTTP消息。还有另外的示例实施例规定，接收到了序列会话的另一应用程序层消息，但是颠倒顺序到达的，则接受者端点丢弃该消息并不发送确认，但仍然发送传输层响应以便遵从请求-响应传输协议。

本发明范围内的诸实施例也包括用来执行或具有存储其上的计算机可执行指令或数据结构的计算机可读介质。这种计算机可读介质可以是通用或专用计算机可访问的任何可用介质。作为示例，而非限制，这种计算机可读介质可包括RAM、ROM、EEPROM、CD-ROM或其它光盘存储、磁盘存储或其它磁盘存储装置、或可用以执行或存储计算机可执行指令或数据结构形式的所需程序代码工具以及可被通用或专用计算机访问的任何其它介质。当信息经网络或另一通信连接(硬接线、无线、或硬接线或无线的组合)传送到或提供给计算机时，计算机完全可视该连接为计算机可读介质。因而，任何这种连接完全可被称为计算机可读介质。以上组合应当也可被包括在计算机可读介质的范围内。计算机可执行指令包括，例如使通用计算机、专用计算机、或专用处理装置执行某些功能或功能组的指令和数据。

图3和以下讨论旨在提供一种本发明可在其中实现的适当计算环境的简要一般说明。尽管不是必需的，本发明将在由个人计算机执行的诸如程序模块的计算机可执行指令的一般上下文中进行说明。一般而言，程序模块包括执行特定任务或实现具体抽象数据结构的例程、程序、对象、组件、数据结构等等。计算机可执行指令、相关联数据结构、以及程序模块代表用来执行在此所揭示方法的诸步骤的程序代码装置的示例。这些可执行指令或相关联数据结构的特定顺序表示用于实现在这些步骤中描述的功能的相应动作的示例。

本领域技术人员会理解本发明在带有多种计算机系统配置的网络计算环境中，包括个人计算机、手持式装置、多处理器系统、基于微处理器的或可编程的消费电器、网络PC、小型计算机、大型计算机等等，也是可以实践的。本发明还可在任务经由通信网络链路(通过硬接线链路、无线链路、或硬接线链路或无线链路的组合)的本地和远程处理装置执行的分布式计算环境中实践。在分布式计算环境中，程序模块可被置于本地和远程存储器存储设备中。

参照图3，实现本发明的示例性系统具有常规计算机320形式的通用计算设备，包括处理单元321、系统存储器322以及把包括系统存储器322在内的各种系统组件耦合到处理单元321的系统总线323。系统总线323可能是若干总线结构类型中的任何一种，包括存储器总线或存储器控制器、外围总线、以及使用多种总线架构的任一种的本地总线。系统存储器包括只读存储器(ROM)324和随机存取存储器(RAM)325。含有帮助在个人计算机320中元件之间，如启动期间的信息交换的基本例程的基本输入/输出系统(BIOS)326存储在ROM 324中。

计算机320还包括读取和写入硬盘339的硬盘驱动器327、读取或写入可移动磁盘329的磁盘驱动器328、和读取或写入诸如CD ROM或其它光学介质等可移动光盘331的光盘驱动器330。磁性硬盘驱动器327、磁盘驱动器328、光盘驱动器330分别通过硬盘驱动器接口332、磁盘驱动器接口333、光盘驱动器接口334连接至系统总线323。诸驱动器及其相关联的计算机可读介质为计算机320提供计算机可执行指令、数据结构、程序模块和其它数据的非易失性储存。尽管在此所述的示例性环境采用了磁性硬盘339、可移动磁盘329和可移动光盘331，但可使用其它类型计算机可访问的能够存储数据的计算机可读介质，包括磁卡、闪存卡、数字通用盘、Bernoulli卡、RAM、ROM等等。

包括操作系统335、一个或多个应用程序336、其它程序模块337和程序数据338的一个或多个程序模块的程序代码装置，可以存储在磁性硬盘339、磁盘329、光盘331、ROM 324或RAM 325中。用户可通过诸如键盘340、定位装置342或诸如话筒、游戏杆、游戏垫、扫描仪等等的其它输入装置(未示出)向计算机系统320输入命令和信息。这些和其它输入装置常常通过与系统总线323耦合的输入/输出接口346连接到处理单元321。或者输入装置也可通过其它接口相连，如并行端口、游戏端口或通用串行总线(USB)。监视器347或另一显示装置也通过诸如如视频适配器348的接口和系统总线323相连。除了显示器，个人计算机通常包括其它外围输出装置(未示出)，如扬声器和打印机。

计算机320可以在使用与一台或多台远程计算机，诸如远程计算机349a和349b的逻辑连接的网络化环境中运行。远程计算机349a和349b可以是另一台个人计算机、服务器、路由器、网络PC、对等装置或其它普通网络节点，而且通常包括上述与计算机320相关的许多或全部部件，尽管在图3中仅显示了存储器存储装置350a和350b及其相关联应用程序336a和336b。图3中所示的逻辑连接包括在此作为示例而非限制地显示的局域网(LAN)351和广域网(WAN)352。这样的网络化环境在办公室、企业范围计算机网络、企业内联网和因特网上是常见的。

当用于LAN网络环境中时，计算机320通过网络接口或适配器353与LAN 351连接。当用于WAN网络环境中时，计算机320可包括调制解调器354、无线链路或其它用于在诸如因特网的广域网352中建立通信的装置。可以是内置式或外置式的调制解调器354，与系统总线323通过串行端口接口346连接。在网络化环境中，所述与计算机320相关的程序模块或其一部分，可以存储在远程存储器存储装置中。可以理解，所示网络连接是示例性的，也可以使用其它用于在广域网352中建立通信连接的方法。

本发明可体现为其它特定形式，而不背离其精神或本质特征。所述诸实施例在所有方面都应仅仅被视为是说明性的，而不是限制性的。因此，本发明的范围由所附权利要求书而不是前面的说明书来指出。在权利要求书的等效技术方案含义和范围内的所有变化被包含在其范围内。

Claims

1.一种在分布式系统的发起者计算装置上通过发挥请求-响应传输协议的现有网络特征而不重新配置或使用新的基础结构服务，以在请求-响应传输协议上发送应用程序层消息时向分布式系统提供可靠消息传送协议RM协议的方法，所述方法包括以下动作：

以可靠单向消息交换模式在发起者端点上创建应用程序层消息，用于将所述应用程序层消息传送给接受者端点；

根据分布式系统的可靠消息传送RM协议格式化所述应用程序层消息；

在请求-响应传输的请求流上发送所述应用程序层消息；

在请求-响应传输的回应流上接收相应的传输层响应，所述传输层响应与RM协议基础结构信息链接以便遵从该RM协议。

2.如权利要求1所述的方法，其特征在于，所述链接到传输层响应的基础结构信息是表示所述接受者已可靠地接收到一个或多个应用程序层消息的确认响应。

3.如权利要求2所述的方法，其特征在于，所述确认响应包括对在请求流上发送的应用程序层消息的确认响应。

4.如权利要求3所述的方法，其特征在于，所述格式化的应用程序层消息根据RM协议被链接到确认请求，且其中所述确认响应是对确认请求的回应。

5.如权利要求1所述的方法，其特征在于，在发送所述应用程序层消息之前，由唯一序列标识符标识的单向序列会话在发起者和接受者之间建立，且其中所述应用程序层消息包括所述唯一序列标识符。

6.如权利要求5所述的方法，还包括以下动作：

根据所述RM协议格式化后续消息，其中所述后续消息包括唯一的序列标识符；以及

在请求-响应传输的请求流上发送所述后续消息。

7.如权利要求6所述的方法，还包括以下动作：

在所述请求-响应传输的回应流上接收后续的传输层响应。

8.如权利要求7所述的方法，其特征在于，所述后续消息是包括用于在接受者端点上处理的输入信息的应用程序层消息，而没有回流到发起者端点的应用程序层输出信息，且其中后续传输层响应被链接到RM协议基础结构信息，所述信息包括表示接受者已接收到至少后续消息的确认响应。

9.如权利要求7所述的方法，其特征在于，所述后续消息是包括终止序列单元的RM协议基础结构消息，且其中后续的传输层响应被接收以便遵从请求-响应传输协议，或者包括RM协议基础结构信息，所述信息包括表示接受者已接收到序列会话中至少最后的应用程序层消息的确认响应。

10.如权利要求7所述的方法，其特征在于，后续传输层响应被接收以便遵从请求-响应传输协议。

11.如权利要求10所述的方法，其特征在于，所述传输协议是HTTP，且其中后续的传输层响应是遵从HTTP的消息。

12.如权利要求6所述的方法，其特征在于，所述后续消息在接收对应于所述应用程序层消息的确认响应之前发送。

13.一种在分布式系统的接受者计算装置上通过发挥请求-响应传输协议的现有网络特征而不重新配置或使用新的基础结构服务，以在请求-响应传输协议上发送应用程序层消息时向分布式系统提供可靠消息传送协议RM协议的方法，所述方法包括以下动作：

以可靠的单向消息交换模式接收从发起者到接受者的应用程序层消息，所述应用程序层消息经请求-响应传输协议的请求流接收；

标识所述应用程序层消息根据分布式系统的可靠消息传送RM协议格式化；

将RM协议基础结构信息链接到传输层响应，所述基础结构信息对应于从所述发起者发送到所述接受者的一个或多个应用程序层消息的可靠交换；以及

经请求-响应传输协议的回应流发送所述传输层响应，以便遵从RM协议。

14.如权利要求13所述的方法，其特征在于，所述链接到传输层响应的基础结构信息是表示所述接受者已可靠地接收到一个或多个应用程序层消息的确认响应。

15.如权利要求14所述的方法，其特征在于，所述确认响应包括对在请求流上发送的应用程序层消息的确认响应。

16.如权利要求15所述的方法，其特征在于，所述格式化的应用程序层消息根据RM协议被链接到确认请求，且其中所述确认响应是对确认请求的回应。

17.如权利要求13所述的方法，其特征在于，在接收所述应用程序层消息之前，由唯一序列标识符标识的单向序列会话在发起者和接受者之间建立，且其中所述应用程序层消息包括所述唯一序列标识符。

18.如权利要求17所述的方法，还包括以下动作：

在请求-响应传输的请求流上接收后续消息，其中所述后续消息包括唯一的序列标识符；以及

标识所述后续消息根据RM协议格式化。

19.如权利要求18所述的方法，还包括以下动作：

在所述请求-响应传输的回应流上发送后续的传输层响应。

20.如权利要求19所述的方法，其特征在于，所述后续消息是包括用于在接受者端点上处理的输入信息的应用程序层消息，而没有回流到发起者端点的应用程序层输出信息，且其中后续的传输层响应被链接到RM协议基础结构信息，所述信息包括表示接受者已接收到至少后续消息的确认响应。

21.如权利要求20所述的方法，其特征在于，所述后续消息是包括终止序列单元的RM协议基础结构消息，且其中后续的传输层响应被接收以便遵从请求-响应传输协议，或者包括RM协议基础结构信息，所述信息包括表示接受者已接收到序列会话中至少最后的应用程序层消息的确认响应。

22.如权利要求20所述的方法，其特征在于，后续的传输层响应被接收以便遵从请求-响应传输协议。

23.如权利要求22所述的方法，其特征在于，所述传输协议是HTTP，且其中后续的传输层响应是遵从HTTP的消息。

24.如权利要求18所述的方法，其特征在于，所述后续消息在发送对应于所述应用程序层消息的确认响应之前接收。