WS-ReliableMessaging 和 WS-Polling 的关系

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 进行此工作。

WS-RM 的解决方案

在前一部分中，我们讨论了接收端点（能够发起连接的端点）必须如何负责建立每个新连接。通常，这被视为“轮询”，因为该端点向其他端点查询消息。虽然 WS-RM 规范的确定义了可供目标端点用作创建新连接的根据的机制，但务必要理解此操作不是轮询消息。这个重要的概念对理解 WS-RM 如何解决此问题非常关键。

在了解为何术语“轮询”并不合适前，我们将对 WS-RM 规范定义的内容进行分析。首先，WS-RM 规范定义了一个新的 URI 模板：

清单 1. 新的 URI 模板

http://docs.oasis-open.org/ws-rx/wsrm/200608/anonymous?id={uuid}

此 URI 是一个“模板”，因为使用它时，“{uuid}”将被替换为唯一的 UDDI，从而允许此 URI 可与此 URI 的其他实例唯一地区分开来。不过，无论 uuid 的值如何，此 URI 的语义含义将保持不变。此 URI 用于两个目的。首先，它具有与 WS-Addressing 匿名 URI 相同的语义含义。也就是说，当在 wsa:ReplyTo 之类端点引用（Endpoint Reference，EPR）中使用时，就意味着任何响应消息都应发送回传输特定的回发通道（或者，对于 HTTP 的情况则是 HTTP 响应流）。这通常用于同步请求-响应消息交换。

此 URI 的第二个语义含义则是在原始传输特定回发通道不可用时发挥作用（例如，连接已断开时）。在这些情况下，此 URI 唯一地标识创建原始连接的端点。或者，换个说法，当原始传输特定的回发通道不再可用时，服务可以保留任何以此 URI 为目的地的消息，直到创建了来自同一请求端点的新连接为止，并随后通过新连接的回发通道将消息返回。如果使用了静态 WS-Addressing 匿名 URI，则 URI 中将不包含可用于区分各个“匿名”端点的唯一标识信息。

其次，WS-RM 规范定义了一个新的单向操作，端点可以发送此操作来创建新连接：

清单 2. 新的单向操作

<soap:Envelope ...>
  <soap:Header
    <wsa:To> some service </wsa:To>
    <wsa:Action> http://...wsrx.../MakeConnection </wsa:Action>
  </soap:Header>
  <soap:Body>
    <wsrm:MakeConnection ...> 
      <wsrm:Address ...> xs:anyURI </wsrm:Address>
    </wsrm:MakeConnection>
  </soap:Body>
</soap:Envelope>

在我们的场景中，防火墙后的端点（请求方）将使用此消息，并指定一个 wsrm:Address 元素作为 wsrm:MakeConnection 元素的子项，其中包含标识消息的发起方的 URI；也就是说，它通常将包含一个 WS-RM 匿名 URI 模板（如上面所定义的）。接收此消息的端点将随后可以使用传输特定的回发通道自由地发送以此 URI 为目标的任何消息。虽然此消息交换的结果是请求方发起了一个连接且相应的消息被发回，但务必注意，请求方并不轮询消息。现在我们将分析为何这个差别如此重要。

首先，我们需要理解 MakeConnection 操作为何是单向操作，而不是请求-响应消息交换。根据通常的 WS-Addressing 请求-响应处理规则，请求-响应消息交换中的请求消息应该包含 wsa:ReplyTo EPR（或缺省设置为“anonymous”）。此 EPR 将随后用于两个目的：1) 作为响应消息的 [destination] EPR；2) 响应消息将发送到此 EPR。

如果 MakeConnection 操作遵循这些规则，则任何为了“响应”它而发出的消息必须将自己的 [destination] EPR 设置为 MakeConnection 消息的 wsa:ReplyTo，而不是最开始导致响应消息生成的原始请求消息的 wsa:ReplyTo。如果这两个 EPR 并不完全相同，则在未对消息进行更改，从而使其与 MakeConnection 的 wsa:ReplyTo EPR 匹配的情况下，我们就违反了 WS-Addressing 规则；或者进行了更改，可能会由于不再使用原始请求消息的 wsa:ReplyTo，从而最终导致将响应消息路由到错误的位置。（请记住，引用参数可能在消息路由过程中非常关键。）为了避免这种类型的问题，将 MakeConnection 定义为了单向操作。

因此，如果 MakeConnection 是单向操作，我们需要理解为何此消息的接收者能够最终使用它，而不会只发送回与 HTTP 202 Accept 响应类似的内容。为了理解这一点，我们必须分析当 wsrm:AcksTo EPR 设置为 WS-Addressing 的匿名 URI 时，WS-RM 如何使用传输特定的回发通道。

当 RM Source 向 RM Destination 发送 CreateSequence 并在 wsrm:AcksTo EPR 中指定 WS-Addressing 匿名 URI 时，则意味着必须通过传输特定的回发通道发送确认信息。因此，当没有消息发送回 RM Source（例如，请求消息的 wsa:ReplyTo 不是匿名的）时，RM Destination 可能会创建一个新 SOAP 信封，专门用于传输确认信息，并将其通过回发通道发回。另外，当 RM Source（例如请求方）希望从回发通道接收任何信息时，则仍然需要检查响应，以确定是否存在需要进行处理的 SOAP 消息。

这与 MakeConnection 操作使用的逻辑完全相同。也就是说，MakeConnection 消息的目的不是轮询消息，而是直接创建一个新连接并标识其创建者，此时接收者就可以使用此空响应流来发送以此发起者为目标的消息了。通过这样做，我们就可以获得与传统轮询机制相同的结果了，但并不必担心会违反 WS-Addressing 处理规则或不正确地更改消息本身。

如上所述，通过使用 MakeConnection，可允许传输任何以指定 URI 为目标的消息。这意味着，虽然此机制在 WS-RM 中定义，但并不要求只能将使用 WS-RM 传输的 WS-RM 协议消息或应用程序消息作为 MakeConnection 消息的响应发送。此消息的接收者可以发送任何以该 URI 为目标的消息。这就允许同步环境尝试模拟异步消息传递——或者，换个说法，发送方重新得到向任何特定端点发送哪个消息的控制权。消息交换方面的唯一特征是，它无法控制这个连接本身的建立，而无法寻址的端点的本质决定了这一点无法避免。

MakeConnection 元素允许传入目标 URI 之外的其他标识信息。以下是 MakeConnection 元素的完整伪模式：

清单 3. MakeConnection 元素的完整伪模式

<wsrm:MakeConnection ...> 
  <wsrm:Identifier ...> xs:anyURI </wsrm:Identifier> ?
  <wsrm:Address ...> xs:anyURI </wsrm:Address> ?
  ... 
</wsrm:MakeConnection>

请注意，它允许传入 wsrm:Identifier。这就允许此消息的发送方请求仅通过回发通道发送与指定的 WS-RM Sequence 相关的消息。与 wsrm:Address 元素不同，此元素限制了可以通过回发通道发送的消息类型。应该将其仅用于 RM Source 和 RM Destination 之间存在紧密耦合的情况，因为此消息的接收方并不具有传统 WS-RM 端点的完全灵活性。

例如，此方法将无法自由地根据需要创建新序列，因为 MakeConnection 的接收方将永远不知道在 MakeConnection 消息中指定的新序列标识符。另外，使用 wsrm:Identifier 元素并不会将消息限制为单个目标 URI。请注意，可能会传输任何与所涉及的 WS-RM 序列相关的消息，而不管其目标位置如何。

最后，请注意，MakeConnection 中的扩展性点允许传入其他类型的标识信息（假定此消息的接收者理解该数据）；我将稍后对此进行讨论。如果传入了多种类型的数据，必须使用“and”将其以逻辑方式连接到一起。

其他用例

到目前为止，我们讨论的都是请求-响应用例。不过，需要指出的是，很多其他消息交换模式需要使用此功能，而 TC 当初采用这样宽泛的解决方案的目的就是为了支持这些消息交换模式。下面我们将对其中较为重要的消息交换模式进行讨论。

WS-RM 规范对序列的范围没有限制。这意味着可以将一个序列用于跨多个端点的消息，反之，也可以在向单个端点发送消息时使用多个序列。WS-RM 匿名 URI 并不限制此功能。在真正的同步环境中，ERP 的创建者可以自由地使用其认为恰当的任何值。例如，它可能选择为多个序列使用相同的 EPR。类似地，当使用 WS-RM 匿名 URI 时，EPR 的创建者可以多次使用相同的 URI。这将导致将很多不同的消息发送到相同的端点。

正如前面提到的，重新发送未得到确认的响应消息的一个解决方案将涉及到重发请求消息（即使已得到确认）。由于需要对普通 WS-RM 处理模型进行更改，因此否决了此解决方案。但之所以否决它，还有其他原因。以单请求/多响应消息交换模式为例。在此场景中，继续重新发送错过了第一个响应交付的请求并没有意义。请求方可能不知道要发送多少响应，因此可能不必重新发送所有请求消息，因为其中一些请求可能会生成多个响应。通过仅发送可以用于发回所有可能消息（响应或任何其他消息）的单个消息，可实现经过极大优化的交互。

与前一用例相关的是 out-only 消息交换用法。例如，以订阅管理器为例——它根本没有请求消息，而事件接收者（位于防火墙后）仍然必须发起连接。在这种情况下，同样可通过 MakeConnection 之类的通用操作来允许使用单个消息初始化任何确定了相应目标的消息传递。订阅者只需要在其订阅 EPR 中使用 RM 匿名 URI 即可。（有关更多细节，请参见 WS-RM 规范的附录中的 MakeConnection 示例。）

请注意，即使未使用（甚至不支持）WS-RM 的其余部分的内容，仍然可以在 EPR 中使用 WS-RM 匿名 URI。这意味着，对于希望直接支持此消息检索机制的端点而言，并不需要使用（甚至不需要实现）传统的 WS-RM“在得到确认前重发”部分内容。

最后一个用例与上一个用例相关：正如所提到的，MakeConnection 既可以与 WS-RM 序列结合使用，也可以不与其一起使用。这意味着尝试向无法达到的端点发送消息的端点可以选择是否使用 WS-RM 的序列。当在 ERP 中使用可达到端点时，尝试向这些 EPR 发送消息的端点可以自由决定是否将这些消息放入 WS-RM 序列中（不考虑我们讨论的用途的策略限制）。

因此，由于 MakeConnection 允许发送任何以该 URI 为目标的消息，因此并不要求对发送端点施加其他约束（例如，序列的使用）。也就是说，MakeConnection 允许返回启用 WS-RM 的消息，也允许返回未启用 WS-RM 的消息，具体选择权留给了这些消息的发送者。

其他信息

要讨论的 WS-RM 的 MakeConnection 的最后一个功能是 MessagePending SOAP Header：

清单 4. MessagePending SOAP Header

<wsrm:MessagePending pending="true" />

此 Header 可以包含在任何消息中，以指示在等待发送其他消息，从而允许此 Header 的接收者（MakeConnection 的发送者）直接发送另一个 MakeConnection，而不用等待普通的延迟时间。

有一点有必要重复一下。WS-RM 规范尝试将用于进行消息交付的机制同消息本身的生成分离开来。这就使得在此类无法寻址端点场景中，所有非传输相关的逻辑几乎可以保持不变。这样做还有一个隐含结果，即在 RM 序列中发送消息时，接收到 MakeConnection 并不一定意味着应该在回发通道上发回消息。也就是说，确定应该何时发送（或重新发送）消息的 WS-RM 逻辑不应因为使用了 MakeConnection 而直接发生变化。当端点接收到 MakeConnection 时，不应着手构造消息。如果消息位于无法寻址的端点中，也不应在尚未重新发送未得到确认的消息的情况下进行消息重发。

引入 MakeConnection 的目标之一是限制其对非传输代码的影响，从而将 MakeConnection 直接提交给另一个传输机制。有关更多信息，请参见下面部分中的内容。

如果 MakeConnection 接收者没有要发送到该连接的发起者的消息，则应该发回一个空响应。例如，对于 HTTP，应该返回一个 HTTP 202 Accept。

对实现的影响

和任何 Web 服务规范的新功能一样，为了支持 MakeConnection，将会对现有 SOAP 实现造成影响。虽然表明上看，这种消息交付机制类型可能是对实现的一个根本性变更，但一旦实现了 WS-Addressing 后就不应如此了。

WS-Addressing 对 SOAP 实现的一个最积极且最重要的影响是，任何现有同步请求-响应消息交换都可能通过直接添加包含可寻址 URI 的 wsa:ReplyTo Header 而成为异步消息交换。（对此概念不熟悉的读者应该参阅 WS-Addressing 规范，以了解更多细节。）

这个功能的引入现在要求 Web 服务端点支持这样一个做法：即要通过 HTTP 响应流发回的任何响应消息现在都能通过完全不同的连接返回。这是一种优秀的开发方法，因为这样可帮助增强这样一个概念，即 SOAP 仅是一系列单向消息而已。消息之间的任何关系都必须在消息本身中进行指定，而不要绑定到传输本身可能提供的任何关系。也就是说，正是因为 HTTP 具有请求流和响应流，客户机不能假设请求流上的消息就是响应，甚至根本不能假设其与请求消息相关。显然，很多情况下都将如此，但 WS-Addressing 现在允许不这样处理。SOAP 端点现在必须检查消息的内容，以在消息之间建立联系，而这意味着用于在端点之间传递消息的传输机制（或协议）与消息本身的内容或关系是正交关系。

看待此更改的另一个方式是，实现应不再假定在 HTTP 响应流上承载的消息与在 HTTP 请求流上的消息相关。WS-RM 在其确认消息处理中就利用了此功能。当创建了新序列时，RM Source 指定一个 wsrm:AcksTo EPR。这时 RM Destination 必须将确认信息发送到的端点。如果此 EPR 包含 WS-Addressing 匿名 URI，则必须在传输回发通道（也就是 HTTP 响应流）上发送确认信息。

以 HTTP 请求流上的请求消息为例，该消息的 wsa:ReplyTo 设置为了可寻址的端点。任何响应消息都将在新连接上发送到 wsa:ReplyTo EPR。如果使用 WS-RM 发送该请求消息，而 wsrm:AcksTo EPR 中包含 WS-Addressing 匿名 URI，则不会出现没有 SOAP 消息通过 HTTP 响应流传递的情况，而会创建一个仅用于发送 WS-RM 确认信息的新 SOAP 信封。这是 HTTP 响应流上传递的消息不是客户机所等待的响应消息的一个示例。此消息与在请求中发送的应用程序数据完全无关。因此，实现不能再仅因为传输的隐含相关性而依赖于消息之间的任何关联。

只要存在这种类型的支持，对 MakeConnection 的支持就会微不足道了。接下来我们将对此影响进行分析，首先要分析的是对客户机（发送 MakeConnection 的端点）的影响。此实现需要进行两个更改。首先，它必须注意到可能存在需要向其交付消息的端点。如何知道这种信息是实现细节。一些可供选择的方式包括：应用程序通知 SOAP 代码需要检查特定端点上的消息；或 SOAP 代码在传出消息中查找 WS-RM 匿名 URI，并推断需要使用 MakeConnection。可以采用很多方法进行此工作，但端点必须确定，由于无法接受新连接，因此必须使用 MakeConnection 获取传入消息。

客户机端点将需要进行的第二个更改是，要发送 MakeConnection 消息（这应该很明显）。支持此更改应该非常容易，因为发送了 MakeConnection 后，应该像处理通过异步机制送达的任何其他消息一样处理通过响应流发送回的任何消息。

让我们分析一下消息通过新连接交付到端点时发生的情况，从而了解为何支持这个更改非常容易。从非常抽象的角度而言，在这种情况下，某些传输特定的代码将等待建立连接，从连接读取 SOAP 消息，并随后将其提交给 SOAP 引擎的其余部分进行处理。在传输代码和 SOAP 引擎的其他部分实现了清楚的分离。MakeConnection 的实现可以利用此分离。当消息作为 MakeConnection 的结果发回时，可以像将异步消息交付中的新消息提交给 SOAP 引擎一样，采用完全相同的方式将此消息提交给 SOAP 引擎。使用 MakeConnection 接收消息的过程应该仅被视为另一个传输。这样，相对于对新传入消息的处理而言，对客户机端点的影响应该最小。

我们现在将对服务端（或需要将消息发送到无法寻址的端点的端点）进行分析。同样，此处的影响也不应太大。从较高的抽象级别来看，如果服务器端点将 MakeConnection 消息视为不进行任何工作的单向消息，则通常根本不会发送回任何消息。对于使用 HTTP 的情况，将仅发送回不包含任何内容的 HTTP 202 Accept 响应。在发送任何空响应前，服务器可以直接使用 MakeConnection 消息中的相关信息，查找以客户机为目标的消息（如果有）并随后使用其替代空消息发回到客户机。请注意，这与现在 WS-RM 使用空响应流发送包含 WS-RM 确认信息的新 SOAP 信封的方式区别并不大。只是在这种情况下，我们发送的不是确认信息，而是之前创建的且等待被交付的 SOAP 信封。但从概念而言，实际并没有任何区别。正如在分析客户机时所看到的，对服务器的影响应该最小。

服务器端实现还有一点要注意。在相应的 MakeConnection 达到之前，它必须保留传出信息。根据实现选择不同，这可以是轻量级的东西（例如内存内的持久性存储区），也可以是稍微重量级的东西（例如，使用 DB2 保存消息）。无论采用哪种方式，此持久性存储都不应对现有 SOAP 代码本身造成影响。

与 WS-Polling 的比较

WS-Polling 于 2005 年 10 月作为成员提交草案提交给了 W3C。当时提供此草案的目的是为了将其作为新规范考虑，或合并到现有规范组中。在决定是否启动新的 WG 前，WS-RX Technical Committee 遇到了这个“无法寻址”端点问题，对于 WS-Polling 的决定推迟到了 WS-RX TC 解决此问题后。当时决定，如果 WS-RX TC 采用了能像 WS-Polling 一样满足相同需求的解决方案，则不需要进行独立的标准制订工作。

对于我们讨论的 MakeConnection 操作，很显然 MakeConnection 提供了几乎与 WS-Polling 完全相同的功能。都提供了相应的方法来告知发送端点应该在传输回发通道不可用的情况下“缓存”消息。都提供了相应的方法来标识应该作为建立新连接的操作的响应发送回去的消息。最后，两者都提供了优化 Header，以便实现更有效的交付模式。不过，应该对 WS-Polling 和 WS-RM 的 MakeConnection 之间的差异进行一下讨论。

WS-Polling 具有真正的“轮询”操作。也就是说，它的 MakeConnection 操作版本 (GetMessage) 建模为请求-响应消息交换，而这意味着我们上面讨论的有关 MakeConnection 为何是单向操作的所有问题也会出现在 WS-Polling 中。因此，从这个方面而言，WS-RM 正确地解决了问题，而 WS-Polling（如何进入了标准化阶段）将需要更改为单向操作。

WS-Polling 的 GetMessage 操作允许请求方指定 WS-Addressing MessageID 作为标识信息的一部分，即请求方在寻找对具有指定 MessageID 的请求消息的任何响应消息。虽然这是一个有意思的功能，但在有关 WS- RM 的 MakeConnection 的讨论过程中，人们认为它更多是一个“边缘案例”，目标 URI 的规范就足够了。不过，由于 MakeConnection 是可扩展的，实现可以在需要的情况下自由地定义这种类型的标识元素。

WS-Polling 和 WS-RM 的 MakeConnection 之间的最后一个重要的差别是 WS-Polling wsp:To 引用参数。此引用参数设计为包含在 EPR 中，因此稍后会将其作为 Header 包含在以该 EPR 为目标的消息中。此 Header 将包含一个 URI，用于标识消息的实际目标 URI。通常，由于这些接收到的消息的 [destination] EPR 包含匿名 EPR，其中并不包含以异步方式发送消息时通常应该有的任何路由信息。此 wsp:To 元素当时就是意在用于承载该信息。接收到所轮询的消息时，发起者将检查此 URI，并使用其替代 wsa:To Header 来确定如何处理此消息。

WS-RM 的 MakeConnection 并没有等效的概念。虽然此问题仍然存在，由于 EPR 的创建者与将接收以该 EPR 为目标的消息的端点相同，因此可以自由地添加任何必要的引用参数，以成功处理消息。这意味着很多实现仍然可能选择添加这种类型的参数，由于这并不是 MakeConnection 消息需要理解甚至处理的内容（遵循普通 WS-Addressing 规则时除外），因此并未将其视为 WS-RM 规范中必要的部分。

WS-Polling 规范涉及到一个值得一提的有趣用例——邮箱方案。在此方案中，服务将消息发送到邮箱端点，而不是采用保留消息的方式。这是通过在向服务提供（例如，在 wsa:ReplyTo 中）的 EPR 中指定邮箱的 URI 来完成的。请求方可以随后使用 WS-Polling 的 GetMessage 操作来从邮箱检索消息。此方案的优势在于，虽然请求方仍然必须知道使用了某种类型的轮询机制，但服务本身并不必如此。它直接遵循普通 WS-Addressing 规则即可。可以采用完全相同的方式使用 WS-RM 的 MakeConnection 功能，即可以用于采用与 WS-Polling 的 GetMessage 类似的方式从邮箱端点检索消息。这就允许无法达到的端点使用相同的机制从邮箱检索消息，就像从服务器进行检索一样。

总结

那么，WS-Polling 的未来如何呢？简单说来，WS-Polling 的“暂停”状态还将继续。现在 WS-RM 规范已在进行公开评审了。如果此规范被批准为正式 OASIS 标准且 MakeConnection 功能仍然能够满足 WS-Polling 的所有要求，我估计 WS-Polling 将会仍然保持其作为 W3C 成员提交草案的资格，不会需要对其进行任何进一步的工作。对于已经支持 WS-Polling 的组织以及实际已经实现了此草案的组织，我们建议采用 WS-RM 的 MakeConnection 功能来满足您的需要。

我们希望通过本文对 MakeConnection 功能的全面分析，以及对其设计决策的根本原因和对现有 SOAP 实现的可能影响的说明，能够使您切实认识到 MakeConnection 不是一个轮询功能，而是可以用于在端点间传递 SOAP 消息的另一个传输机制。考虑到 WS-Addressing 对 SOAP 实现已有的影响，支持 MakeConnection 并不会像乍看之下的那样需要进行根本性的更改。