注 运行与本文相关的下载文件需要下列内容：

在 PDC 上，我谈论了有关可靠的 XML Web 服务（Web 服务）的话题，这个话题源于过去一年来的多次交流。在有关构建 XML Web 服务的各种常见问题中，可靠性问题是开发人员实现分散式 Web 服务所面临的五个最重要的问题之一。如果分解开来讲，这个问题并不是太难，因此，本月我准备谈一谈构建可靠的 XML Web 服务这一棘手的问题。

本页内容

概述

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

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

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

返回页首

XML Web 服务的可靠性

我们把问题分解开来讲。如上所述，GXA 服务的实现是消息服务。它们需要在分散式环境中发送和接收基于标准的编码消息。在 Web 服务实现中发送 SOAP 消息的主要传输协议是 HTTP。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

我动手处理的第一个问题是定义如何分解可靠性协议 (ericRP)。以下是该协议的要点：

注意 不管采取哪种方式为 SOAP 环境实现可靠性层，除了 SOAP 分析器之外，还需要其他基础结构。

处理 API

对于这个原型，我构建了六个主要的类和一个小型数据库。我将类称为处理 API。Web 服务客户端和服务器将使用这些类监视和更正使用 ericRP 可靠性协议的消息。所有的类都属于 ericRP 命名空间：