WS-RM 尝试解决什么问题，为什么?

　　在其工作期间，WS-RX Technical Committee (TC) 遇到了很多人面临的相同问题：将 SOAP 消息交付到由于某种原因无法接受新传入连接的端点。对于 WS-RM 规范，这特别麻烦，因为其处理模型的一个主要组成部分是这样一个能力：发送端点能够根据自己的判断将未得到确认的消息发送到目标端点。我们现在将通过一个简单的示例来说明在没有此功能的情况下 WS-RM 端点为何不能完成其工作。

　　以两个端点间发送的简单请求-响应消息系列为例。每个请求都必须可靠地按顺序交付给服务。类似地，对这些请求的每个响应都必须可靠地按顺序交付回请求方。在请求方和服务可以彼此建立新连接的环境中，每个端点中的 WS-RM 逻辑可以自由地根据需要向另一方发送未得到确认的消息以及确认信息。

　　不过，我们将通过添加防火墙稍微降低一下此环境的“开放性”。假定请求方要将其消息发送到企业内部网之外的服务。服务能够以异步方式通过防火墙创建到请求方的新连接的几率几乎降到了零。这意味着当服务尝试执行其常规的消息重发或发送确认信息的 WS-RM 逻辑时，将无法完成此任务。创建两个端点的新连接的唯一方式是由请求方发起此操作。通过这样做，实际上是请求方在询问服务是否有任何未决消息需要交付。通常这称为对消息的“轮询”。(为了便于说明，我们将无法接受新连接的端点称为“无法寻址”的端点。)

　　为了解决将消息重新发送到无法寻址的端点的问题，WS-RX TC 对多个可能的解决方案进行了研究。不过，除了一个轮询类型的解决方案外，几乎所有的解决方案都因为某些原因被否决了。TC 在处理其他解决方案时遇到的最大问题是，其中涉及到对普通 WS-RM 处理逻辑的更改。例如，考虑以下这种情况，请求消息已交付(且得到了确认)，但响应丢失了。在这种情况下，一种建议补救方案是请求方重新发送请求消息，从而提供一个用于发送丢失了的响应的回发通道。这需要对请求方进行一点修改，因为在普通 WS-RM 处理逻辑中，消息得到确认后，就不再需要对其进行重发了。

　　TC 处理的另一个关键问题是，如果 WS-RM 端点可以发起新连接，它同样可以自由地选择使用哪个 WS-RM 序列(如果有)。例如，在我们的场景中，服务将决定为每个响应消息使用哪个 WS-RM 序列。可以出于任何原因而决定将每个消息放入自己的序列中。或者，如果现有序列可能出现了问题，则可以将其关闭并启动新的序列。这种类型的决策对 WS-RM 端点完成其工作的能力非常关键。大部分非轮询类型的解决方案都涉及到消息的目的地(我们的场景中的请求方)受响应序列控制(这通常是由服务端负责的工作)的情况。同样，这也会对普通 WS-RM 处理逻辑进行修改。

　　经过长时间讨论后，TC 认为最佳可用选项将是让 WS-RM 逻辑同 SOAP 消息本身的实际传输分离开来。这意味着，他们希望让 WS-RM 处理逻辑保持不变，而同时仍然允许接收端点(我们场景中位于防火墙之后的端点)发起新连接。显然，任何轮询类型的解决方案都是对端点的更改，但对 WS-RM 逻辑本身的更改应该最少。这被视为一个关键的要求。

　　将消息送到无法寻址的端点是很多人可能都遇到过的问题，显然不是 WS-RM 特有的问题。那么，WS-RM 为什么会选择解决此问题，而不是等待某个其他规范(如 WS-Polling)来解决呢?

　　这个问题的答案并不是唯一的。很多 TC 成员都听到客户反映需要尽快解决此问题;他们急需一个标准(且可互操作)的解决方案。急客户之所急始终是一个很好的促进因素。

　　TC 的决策中的另一个因素是，顾名思义，WS-RM 规范的用途是“可靠”地交付消息。在这个问题出现之前，“可靠交付”重点大部分都放在得到确认前重发消息，而很多人认为可以也应该对可靠性进行扩展，以包括到无法寻址的端点的消息交付。

　　最后，TC 没有逃避此问题的另一个主要原因(与第一个原因相关)是，因为多个其他规范已经在开发自己的轮询类型解决方案了。这意味着，解决此问题的办法将不止一个，而是多个。而更糟糕的是，每个办法都采用自己领域特定的方式解决问题。如果存在可在所有领域使用的单个解决方案，则可更好地为行业服务。随着 WS-RM 逐渐成为大部分 SOAP 堆栈将支持的核心规范，TC 开发的解决方案将被尽可能广泛地采用和支持。

　　正如很多人所认为的，由于此问题非常普遍，这样做并没有什么价值，这个问题实际应该在 WS-Addressing 规范中得到解决。虽然这个说法颇有道理，但 W3C 的 WS-Addressing Working Group 已经将其规范最后定稿了。因此，如果社区希望短时间内推广一个相应的解决方案，则应由 WS-RM 进行此工作。