WS-ReliableMessaging 利用了可靠消息传送和事务处理协议中的多种算法。 特别是，WS-ReliableMessaging 提供了一种灵活的确认方案，在这种方案中接收方可以高效地传输已收到（和尚未收到）的消息范围。 WS-ReliableMessaging 还提供一种高效的排序机制，以确保接收方能够按照消息原来的发送次序来处理这些消息，即便由于重新传输或多路径传送而出现重新排序也是如此。

　　WS-ReliableMessaging 的设计可与现有的 Web 服务基础结构结合在一起。 特别是，WS-ReliableMessaging 必须建立在 WSDL 和 XML 架构中所说明的各个现有应用程序协议和接口的基础上。 这意味着经销商和供应商不必重新设计其应用程序级的消息架构或交换模式。 各应用程序的各种实现使用 WSDL 和 XML 架构，而 WSDL 和 XML 架构定义各项服务的业务接口。 提供 Web 服务协议的基础结构软件将可靠的消息传送功能与 Web 服务协议结合在一起。

　　WS-ReliableMessaging 并不绑定到底层的传输协议或会话。 这意味着即使一个或两个系统都被重新启动，WS-ReliableMessaging 对话的生存周期也可以跨越很长时间（数天，数周）。 这就允许在中途挂起对话（例如，以便进行系统维护），然后继续进行而不必重新传输整个对话。

　　WS-ReliableMessaging 协议具有多种特性，这些特性有利于大型双向传输（诸如通常在合作伙伴集成方案中使用的传输，就像本例一样）。 WS-Addressing 允许在任一方向上异步发送消息。 WS-ReliableMessaging 通过多种途径利用这种功能。 WS-ReliableMessaging 并不对所收到的每条消息都发送确认消息，而是允许目标在单个紧凑的控件元素中成批地确认所收到的每条消息。 这个控件元素可通过自己的消息进行发送，或者也可包含在一条后续要发送回源节点的应用程序消息（例如，请求/回复对话中的响应消息）中。 WS-ReliableMessaging 对正在传输而尚未完成的消息数量没有任何限制；在单个底层传输连接的任一方向上，两个终结点可以具有多条“正在传输的”可靠消息。 在这种常见的情况下，WS-ReliableMessaging 的消息开销变得非常低。

　　建立公共参数

　　两个自治的合作伙伴（诸如供应商和经销商）各自具有一组不同的功能和要求，这种情况是很普遍的。 例如，供应商和经销商二者对以下各项可能都有不同的要求或功能：

　　供应商在一天的什么时间接受传输，以及它所支持的未获确认的消息的最大数量。

　　供应商需要什么样的安全凭据。

　　使用什么超时设置来控制未获确认消息的重新传输。

　　供应商是否接受事务处理。

　　供应商支持哪些版本的特定规范。

　　WS-Policy 建立了一种框架，以便公布许多服务要求、首选项和功能。 WS-PolicyAssertions 定义了一种方法，以便进行个别声明（例如供应商对安全令牌的要求，以及首选 X.509 而不是 Kerberos）。 可以将断言组合到文档中并将其关联到 Web 服务元素，如 WS-PolicyAttachment 所定义的，Web 服务伙伴可以通过很多方法来交换 WSDL 接口和 WS-Policy 信息。 有些将是非正式的带外方法，利用电子邮件，在 Web 站点上发布文档，或者使用 UDDI 等等。

　　有时，非正式的方法的限制过多，我们的结构认识到需要一种 WS-MetadataExchange 模型。 我们预期这个模型可定义一种 WSDL 接口和消息模型，以供 Web 服务客户端用来为 URL 或终结点引用处的某项服务获取 WSDL 和 WS-Policy 信息。

　　在我们的简单方案中，经销商将使用一种与供应商的终结点引用相关的架构 Web 服务来检索 WSDL 和 WS-Policy 文档，这些文档定义了用于 WS-ReliableMessaging、WS-Security 等的供应商的接口、要求和首选项。一个有经验的供应商还可以对终结点引用进行改进，并向经销商传回一个新的终结点引用。 该终结点引用中可能包括策略，或者经销商可能需要获取该新终结点的策略。

　　经销商也可以选择请求并审核该供应商的策略，并选择与自己策略一致的替代策略。 然后，经销商可以发送消息，保证满足供应商系统的所有要求，且正在使用的每个协议的版本都是正确的。