可靠的 XML Web Service
Eric Schmidt
Microsoft Corporation，XML Core Services 组，项目经理
2001 年 12 月 11 日

下载此专栏的示例代码。

注意：要下载与本文相关的代码，您需要：
Visual Studio .NET Release Candidate（英文）
SQL Server 2000（英文）
在 PDC 上，我谈论了有关可靠的 XML Web Service（Web 服务）的话题，这个话题源于过去一年来的多次交流。在有关建立 XML Web Service 的众多常见问题中，可靠性问题是开发人员实现分散式 Web 服务所面临的五个最重要的问题之一。如果分开来讲，这个问题并不是太难，因此，本月我准备谈一谈建立可靠的 XML Web Service 这一棘手的问题。

概述
Global XML Web Services Architecture（GXA [英文]）最突出的一面就是可以使用可合成处理协议扩展该体系结构。这些协议主要通过 SOAP 标头实现，可以提供包括安全性、加密、路由和可靠性的广泛服务。当您开始构建基于 GXA 的应用程序时，您将发现 GXA 实质上是一种消息处理体系结构，它通过基于标准的编码技术 (SOAP) 在系统和服务之间提供协同工作能力。到目前为止，大部分实现工作都集中在 SOAP 1.1 和 WSDL 兼容服务上，因此 Web 服务实现方案可以与多种语言和操作系统协同工作。

这是一个了不起的概念。任何两个系统之间都能够进行交流，只要它们能够分析 XML 并理解 SOAP 规范的规则。但是，简单的消息交换并不能满足复杂的业务应用程序的需要。真正的应用程序（不管其内部域体系结构如何）均需要标准化的服务，例如处于 Web 服务消息处理层上的安全性、授权和可靠性。在 Global XML Web Services Architecture（具体地说就是 SOAP、SOAP 模块和基础结构协议）的创建和实现背后有一个巨大的动力。随着今年十月份四项新规范（WS-Routing、WS-Referral、WS-Licensing 和 WS-Security）的发布，我们已经开始着手下一代 XML Web Service 实现工作。尽管发布了这么多的新规范，但仍有两个领域尚无公共规范，即事务处理和可靠的消息处理，这主要是因为这些基础结构协议依赖于底层 SOAP 模块。

本专栏主要从 GXA 环境的角度讨论可靠性和可靠的消息处理的含义。而且我还要花一些时间探讨通过在 .NET 框架中扩展现有 Web 服务类来开发可靠性协议需要做些什么。本专栏有两个主要目的：

让读者了解可靠性概念，为以后各种规范的实施做好准备。请注意，本文不是规范，而只是一篇文章，旨在引发读者思考下面要讨论的问题。
说明 .NET 框架中 Web 服务和 SOAP 类强大的、基于标准的功能。
XML Web Service 的可靠性
我们把问题分开来讲。我们前面讲过，GXA 服务实现方案属于消息处理服务，它们需要在分散式环境中发送和接收基于标准的编码消息。在 Web 服务实现方案中发送 SOAP 消息的主要传输协议是 HTTP，它易于实现和管理，但本身不可靠。我们无需深入探讨 HTTP 不可靠的具体原因，但只要知道 HTTP 没有基于标准的服务来保证终点或服务器能够接收到请求就足够了。尽管内置的网络层设备可以在发生一般灾难性故障（例如未找到资源）时产生错误，但是却没有机制可以确保客户端能够以可靠的方式接收请求或响应。

通常是通过简单的重新发送操作处理 HTTP 故障，但在业务处理环境中这既不利于提高效率也没有效果。它导致不必要的通信量，并增加了重复交易的风险。

目前市场上有多种能够更有效解决此问题的消息处理技术，包括传输协议（如 HTTPR）、企业基础结构（如 MSMQ 和 MQ Series）以及业务处理协议（如 ebXML）。尽管每种技术针对特定的实现方案各有优点，但都不能以可在所有传输协议上跨域应用的可扩展方式解决可靠性问题；而且，在消息交换和处理方面的功能层次上也不尽相同。

面对所有这些问题，我决定总结一个需求列表，看一看在 Web 服务环境中实现可靠性原型需要做哪些工作。

以下是我自己创建的可靠性层的主要需求列表：

基于标准并应用于消息协议层
确认发送
有序发送
对称对话
加快异步处理
基于标准
该协议必须由现有的基于标准的技术组成。而且，该协议还应该对 SOAP 1.1 规范进行扩展，然后应用到消息编码层而不是传输层。这样，消息才能够在所有可用的机制（从 HTTP 到某些专用套接字实现方案）上进行传输。

确认发送
为了有章可循，该协议必须采用某种发送确认机制，也就是说，使用该协议发送的消息应当从处理器接收一个且只有一个关于该消息状态的确认信息。

有序发送
有序发送引入了对话概念，即客户端和服务器可以交换消息和确认（确认也是可唯一标识的对话的一部分）。收到消息后，将检查消息以进行排序，确保处理器收到一组有序的消息。

对称对话
建立在对话机制之上的协议，还必须确保消息和确认的对称性。必须确保每条消息只被处理一次，并且只生成一个确认。

加快异步处理
这是需求列表中最重要的一点，所以留在最后说明。HTTP 是基于同步请求响应模型的，适用于处理任务量小或运行时间短的简单应用程序。Web 服务实现方案有一个不太高明的小秘密，即用户不需要从处理的角度了解服务是如何在后端实现的。也就是说，Web 服务实现方案处理一个请求可能只需要三秒钟，也可能会花上三个小时。这导致消息处理体系结构效率低下，且无法扩缩。我们需要的是一个能够加快异步消息处理体系结构的处理模型。但是要注意，异步模型实现方案要比紧耦合的请求响应实现方案复杂得多，因为它需要更多的基础结构。

我来解释一下。在使用标准 HTTP 的同步消息处理模型中，客户端在向服务器发送请求后、从服务器接收到响应之前一直保持停滞状态。在这段时间内，可能会发生许多灾难性事件：

连接可能会因外部原因而断开，从而丢失请求或响应。
服务器可能会因脱机或过载而超时。
服务器进程可能取决于下行服务，而这种服务的响应时间无法控制。
同步模型


图 1：同步模型

不管问题是与网络有关还是与应用程序有关，要确保可靠性都需要实现某种附加协议驱动的基础结构。在本次讨论中，我想着重讲述消息是如何在传输层上进行处理的。传输层是独立于应用程序的关键部分，使用它可以实现可靠性层，并将消息的最终处理过程分离出来。更具体一点来说，每一条消息（不管针对哪种应用程序）都需要从网络层上读取，并分配至适当的应用程序资源。我们可以在这里添加一个发送可靠性确认和执行持续存储的附加协议，这样应用程序资源就可以选择处理该消息的时间和方式。而且，这个新协议可以帮助我们分离或加快异步处理模型。下面将解释如何完成此过程。

在下面的异步模型中，某一请求被发送至 SOAP 服务器。服务器从网络层上读取该消息流，并立即向客户端返回 HTTP 202 响应。此进程仅就向服务器发送消息的时间而言是同步的，这样可以减少与连接有关的问题。到达服务器后，消息将被传送到可靠性层，在这里进行检查以验证消息是否过期、重复和有序。然后，消息被持续存储（在关系数据库中），并向客户端发送有关其状态的确认。最后，消息将被分配至正确的应用程序功能。

异步模型


图 2：异步模型

在 HTTP 环境中，您可以控制向客户端发送响应的时间。通过控制向客户端发送响应的时间，您可以将下行处理影响通信可靠性的风险降到最低。在 SOAP 中，这是通过单向消息传递实现的。它指示底层 SOAP 处理器立刻向客户端发送 HTTP 202 响应，通知客户端已收到消息，并已成功地将消息分配给正确的资源进行处理。之后，处理器向客户端发送有关该消息状态的响应。本文稍后将对这种模型的优点进行详细介绍。

建立可靠性层
明确了上述要求之后，我们来讨论如何使用 .NET 框架为 Web 服务实现方案建立可靠性协议。根据上述要求，我建立了一个小型 API，以便提供可用的实现方案。

协议：ericRP
第一个问题是定义