WS-Reliable Exchange (WS-RX) OASIS Technical Committee 最近发布了 Web 服务可靠消息传递（WS-ReliableMessaging，WS-RM）规范，以供公众进行公开评审。在本文中，Doug Davis 讨论了新规范如何处理向无法接受传入连接的端点交付 SOAP 消息的问题，并分析了其与 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。

……

查看原文

欢迎访问最专业的网吧论坛,无盘论坛,网吧经营,网咖管理,网吧专业论坛https://bbs.txwb.com

关注天下网吧微信,了解网吧网咖经营管理，安装维护: