计算机科学论坛--防火墙：Web 服务不可逾越的障碍？

防火墙：Web 服务不可逾越的障碍？
http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html
通过防火墙进行异步传递消息

2006 年 10 月 08 日

本文介绍如何使用 Web 服务轮询（Web Services Polling，WS-Polling）来解决异步消息传递中的难题。本文作者在以前撰写的一篇文章“The hidden impact of WS-Addressing on SOAP”（请参阅参考资料）中讨论了 WS-Addressing 规范将如何对 SOAP 本身产生重大影响。这种基于 WS-Addressing Header 内的信息动态路由任何 SOAP 消息的概念给 SOAP 用户带了一种新的自由。他们不再局限于使用简单的 HTTP 请求/响应消息流。诸如 WS-Coordination/Transaction 和 WS-Reliable Messaging 之类的规范，现在只需使用 WS-Addressing Header，就可以假定存在使用标准方式定义的异步消息传递模型。但是，如同许多事情一样，使用异步消息处理机制也有不利的方面，而且还存在一个阻碍其采用的障碍——防火墙。
防火墙不好？请不要这样想！

是的，没错！其实防火墙本身并没有什么不好，但如果您考虑到异步消息处理的含义，防火墙无疑会起干扰作用。设想您在家用计算机上运行一个 Web 服务客户机，并且试图调用 Web 上的某些需要花费一些时间才能执行的服务。在此情况下，HTTP 连接所保持的时间可能不足以等到您接收响应，或者即使时间足够，您可能也不希望这样——为什么等待时还要占用资源？而且，我们现在讨论的是异步消息处理，所以您期望通过一个新的连接返回结果。首先，让我们研究一下如何告诉服务您希望异步返回响应。您的请求消息将包含一个 WS-Addressing ReplyTo Header，如下所示：

清单 1. WS-Addressing ReplyTo Header 示例

  <wsa:ReplyTo>
    <wsa:Address>http://myhomemachine.com/inMessages</wsa:Address>
  </wsa:ReplyTo>

显然，这指示任何响应消息都应该通过一个新的 HTTP 连接发送至 http://myhomemachine.com/inMessages。虽然这看起来已经够简单了，但它意味着有两件事必须是真实的：第一，SOAP 服务器/侦听器必须正在该计算机（您的家用计算机）上运行，以接收传入的消息。第二，Internet 上的计算机必须能够打开一个返回到您的家用计算机的连接——通过您的防火墙。

第一个问题的难度取决于您的经验水平。让一个非技术人员建立一个 SOAP 服务器可能有些过分，而且并非每个人都想在自己的家用计算机上安装像 SOAP 服务器这么庞大的内容。然而，第二个问题更加棘手。由于外界所有的病毒都对操作系统中的安全漏洞虎视眈眈，而且多数人都不想受到它们的危害，因此他们从不打开路由器或防火墙的任何端口，所以即使某些掌握相关技术知识的人执意要建立 SOAP 服务器，SOAP 响应消息仍无法异步返回给他们。那么，您该如何做呢？

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html#main]回页首[/URL]

他山之石，可以攻玉

如果您看到其他基于 Internet 的消息传递系统解决了上述问题，您可以重用某些相同的解决方案。尤其是当今最流行的消息传递系统：电子邮件系统。与上述 SOAP 场景非常相似，您可以打开防火墙上的 SMTP 端口 (25)，并运行一个 SMTP 服务器来接收传入的电子邮件。但这种技术所要求的知识远远超出了大多数非技术人员所掌握的范围。因而，大多数人选择将自己的电子邮件地址委托给其他人托管（某些邮件托管服务提供商）。然后，他们只需通过使用某些邮件客户机下载自己的电子邮件消息即可。这解决了两个问题：无需建立一个本地（且复杂的）服务器；无需冒着受攻击的风险而打开防火墙。

那么，您如何在 SOAP 中应用这种技术呢？随着 WS-Addressing 规范的制定，这个问题也随之解决了。现在，通过 WS-Addressing，您可以告诉消息的收件人将响应发送到何处——非常类似于电子邮件中的“发件人”字段。因此，请将您的 wsa:ReplyTo Header 做如下更改：

清单 2. 使用邮箱的 wsa:ReplyTo Header 示例

  <wsa:ReplyTo>
    <wsa:Address>http://mailbox.soaphub.org/soaphub/services/soaphub</wsa:Address>
  </wsa:ReplyTo>

现在，您的响应消息将发送到 SOAP 消息托管提供商 mailbox.soaphub.org。该站点仅接受该消息，然后等待您的 SOAP 客户机检索它。现在，您既不需要在客户机上运行一个庞大的 SOAP 服务器，也不需要打开防火墙。另一件令人欣喜的事情是，您所调用的 Web 服务不必为支持这种技术而做出任何改变（假定该 Web 服务至少支持 WS-Addressing）。从服务的角度来看，它只将响应发送到客户机所告知的地址——无论是实际的客户机地址，还是某些“消息托管提供商”的地址；它不知道也不关心——仅仅是打开一个到 wsa:ReplyTo 端点的连接，而不管其值是什么。

当然，这里还有一个问题——当前的 SOAP 客户机并未写入如何“请求（也可以称为轮询）”某个 Web 服务调用的结果。但是值得庆幸的是，WS-Polling 规范定义了一种轮询 Web 服务调用结果的标准方式，而且不需要编写大量的代码来执行该操作。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html#main]回页首[/URL]

WS-Polling

最基本的 WS-Polling 只定义一个 SOAP 操作，称为 GetMessage，SOAP 客户机可以对消息托管提供商执行该操作。该操作将返回所需的 SOAP 消息，或者根本不返回任何内容（如果没有等待传递到 SOAP 客户机的消息）。让我们来看一个示例。假定一个 SOAP 客户机正在调用一个 echoString 服务（该服务只返回传入的字符串）。请求消息如下所示：

清单 3. 指向 SOAP 消息托管提供商的请求消息

  <s:Envelope>
    <s:Header>
      <wsa:MessageID>uuid:705738e3907891e3</wsa:MessageID>
      <wsa:To>http://www.echostring.com/echoString</wsa:To>
      <wsa:Action>echoString</wsa:Action>
      <wsa:ReplyTo>
        <wsa:Address>http://mailbox.soaphub.org/soaphub/services/soaphub</wsa:Address>
      </wsa:ReplyTo>
      </s:Header>
    <s:Body>
      <echoString>
        <Text>Hello World</Text>
      </echoString>
    </s:Body>
  </s:Envelope>

请注意，该 wsa:ReplyTo Header 既不是匿名 URI，也不是 myhomemachine.com，而是 SOAP 消息托管提供商的 URL。因此，当 echoString 服务生成结果后，它将把结果发送到 mailbox.soaphub.org，该结果如下所示：

清单 4. 发送到 SOAP 消息托管提供商的响应消息

  <s:Envelope>
    <s:Header>
      <wsa:MessageID>uuid:5e73f8b9893821f0</wsa:MessageID>
      <wsa:To>http://mailbox.soaphub.org/soaphub/services/soaphub</wsa:To>
      <wsa:Action>echoStringResponse</wsa:Action>
      <wsa:From>
        <wsa:Address>
          http://www.echostring.com/services/echoString
        </wsa:Address>
      </wsa:From>
      <wsa:RelatesTo>uuid:705738e3907891e3</wsa:RelatesTo>
    </s:Header>
    <s:Body>
      <echoStringResponse>
        <Text>Hello World</Text>
      </echoStringResponse>
    </s:Body>
  </s:Envelope>

请注意，这与您所期望的相比没有什么不同（根据 WS-Addressing 处理规则）。现在，您的 SOAP 客户机必须轮询该响应：

清单 5. WS-Polling 请求

  <s:Envelope>
    <s:Header>
      <wsa:MessageID>uuid:705738e3dbb46924</wsa:MessageID>
      <wsa:To>http://mailbox.soaphub.org/soaphub/services/soaphub</wsa:To>
      <wsa:Action>
        http://www.w3.org/2005/08/ws-polling/GetMessage
      </wsa:Action>
      <wsa:ReplyTo>
        <wsa:Address>
   http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
        </wsa:Address>
      </wsa:ReplyTo>
    </s:Header>
    <s:Body>
      <wsp:GetMessage>
        <wsa:MessageID>uuid:705738e3907891e3</wsa:MessageID>
      </wsp:GetMessage>
    </s:Body>
  </s:Envelope>

GetMessage 操作有两个变量，但是您在这里只采用了一个 MessageID 参数，来表示您正在期待其响应的请求消息的 wsa:MessageID。或者从另一个方面来说，您先前向 Web 服务发送了一个请求消息，该消息含有一个 wsa:MessageID Header，其值为 uuid:705738e3907891e3。现在，您正在向 mailbox.soaphub.org 请求其响应消息。请注意，由于 wsa:ReplyTo Header 含有匿名 URI，因此来自 GetMessage 的响应将在 HTTP 响应流中返回，从而来自原始消息的响应可以通过防火墙传回给您。值得反复强调的一点是，请注意您所调用的 Web 服务并不知道您使用了 mailbox.soaphub.org。显然，任何支持 WS-Addressing 的现有 Web 服务都可以透明地使用 WS-Polling。

如果 SOAP 消息托管提供商还没有可用的响应消息，则它仅返回以下内容：

清单 6. WS-Polling NoMessageAvailable 响应

  <s:Envelope>
    <s:Header>
      <wsa:MessageID>uuid:49fd3860900fa472</wsa:MessageID>
      <wsa:To>
    http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
      </wsa:To>
      <wsa:Action>
    http://www.w3.org/2005/08/ws-polling/GetMessageResponse
      </wsa:Action>
      <wsa:From>
        <wsa:Address>
          http://mailbox.soaphub.org/soaphub/services/soaphub
        </wsa:Address>
      </wsa:From>
      <wsa:RelatesTo> uuid:705738e3dbb46924</wsa:RelatesTo>
    </s:Header>
    <s:Body>
      <wsp:NoMessageAvailable reason="wsp:UnknownMessageID"/>
    </s:Body>
  </s:Envelope>

该消息中的关键元素是 wsp:NoMessageAvailable——表示所请求的响应消息不可用，因此请求者（您的客户机）应该稍后再轮询。

另一种情况是，当来自 echoString 的响应可用，则来自 GetMessage() 的响应如下所示：

清单 7. WS-Polling 成功响应

  <s:Envelope>
    <s:Header>
      <wsa:MessageID>uuid:5e73f8b9893821f0</wsa:MessageID>
      <wsa:To>
  http://schemas.xmlsoap.org/ws/2004/03/addressing/role/anonymous
      </wsa:To>
      <wsa:Action>echoStringResponse</wsa:Action>
      <wsa:From>
        <wsa:Address>
          http://www.echostring.com/services/echoString
        </wsa:Address>
      </wsa:From>
      <wsa:RelatesTo>uuid:705738e3907891e3</wsa:RelatesTo>
      <wsa:RelatesTo>uuid:705738e3dbb46924</wsa:RelatesTo>
    </s:Header>
    <s:Body>
      <echoStringResponse>
        <Text>Hello World</Text>
      </echoStringResponse>
    </s:Body>
  </s:Envelope>

需要密切关注的地方是 wsa:RelatesTo Header。请注意有两个 wsa:RelatesTo Header。这是因为该响应消息实际是两个不同的请求消息的响应，一个是 WS-Polling GetMessage 请求，另一个是 echoString 请求。而这是 WS-Addressing 的另一个重要的功能。

如本例所示，与消息交换的服务器端不同，SOAP 客户机不可能不使用 WS-Polling。目前，SOAP 客户机会通过某种形式等待响应消息传回给自己（通过新的套接字或者 HTTP 响应流）。希望通过防火墙（并且无需运行一个 SOAP 服务器）进行异步消息传递的 SOAP 客户机需要增加对 WS-Polling 的支持。这种逻辑并不复杂——客户机不是等待响应消息到达，而是周期性地通过 GetMessage 操作来轮询其 SOAP 托管提供商，以获得所需的响应消息。您不需要做许多的工作或编写大量的代码，但请记住，这种技术时至今日还未最终定型。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html#main]回页首[/URL]

其他场景

WS-Polling 可以用于各种各样的场景。下面只列出了一些我觉得值得特别提及的场景。

未经请求的消息

如果 SOAP 客户机已经订阅了通知系统（例如，WS-Notification 或 WS-Eventing），则即使它们位于防火墙后，任何希望发送到防火墙后的订户客户机的通知消息现在也可以传递。订户（客户机）只需使用 WS-Polling 周期性地查询其 SOAP 消息传递主机，以获得等待传递给它的任何消息。当然，如果客户机订阅了通知系统，则它必须指定其 SOAP 消息传递主机作为其消息的目标 EPR，但通知系统并不知道这种情况。需要注意的重要一点是，WS-Polling 允许它的 GetMessage 请求查询任何以该客户机为目的地的消息——不只是响应消息。它定义了一些常用的查询方言，并且具有足够的可扩展性，允许定义新的方言（请参阅下面的[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html#web]全天候 Web[/URL] 场景）。

服务器端支持

虽然本文的重点是讨论如何使用 SOAP 消息传递主机作为邮箱，但服务端点也可以直接支持 WS-Polling 本身。WS-Polling 为客户机和服务定义了一种方式，以使另一方在适当的时候支持（并将使用）WS-Polling。通过这种方式，两个端点之间无需第三方邮箱就可以进行异步消息传递。

安全性

WS-Polling 旨在与其他 WS-* 规范结合使用，其中包括一些安全规范（WS-Security 和 WS-SecureConversation）。WS-Polling 规范说明了如何使用它的某些功能来保证不破坏消息的完整性——即使当使用第三方邮箱时。

消息传递控制

WS-Polling 可以作为一种端点控制 SOAP 引擎传递和处理消息速度的一方法。在没有防火墙的情况下，如果某个端点承载了 SOAP 服务器，则控制消息的传递速度（或试图传递的速度）比较困难。使用 WS-Polling，端点可以完全控制消息传递到其引擎以进行处理的频率。

全天候 Web

有时，服务在 Web 上不可能每天 24 小时可用。如果服务提供商使用 WS-Polling 邮箱作为其服务的 EPR，则传入的消息可以在任何时候进行传递。当该服务没有联机时，它可以检索邮箱中挂起的消息并进行处理。这使该服务看起来似乎 24x7 可用。

反向协议

WS-Polling 可以看作是反向协议。一旦发送了最初的 WS-Polling GetMessage，请求消息就可以在 HTTP 响应流中进行传递。然后，这些请求的响应可以通过请求端新的 HTTP 连接进行传递。这使得 WS-Polling 能够在请求端不能正常建立自己的连接的情况下，作为一种启动两端点之间的连接的方法。

优化：

WS-Polling 通过定义附加的 SOAP Header（可以包含在非 WS-Polling 消息中，用作两端点对需要传递的消息的存在状态进行通信的一种方法）来优化轮询行为。这可以显著降低通常与周期性轮询有关的网络开销。

实现：

如同其他 WS-* 规范（例如 WS-MetadataExchange），WS-Polling 也可使用两种不同的方式。客户机应用程序可以自己发出 GetMessage 请求，然后期望手动处理任何可能的响应。或者，SOAP 堆栈可以自己通过其基础代码发出 GetMessage 请求。例如，如果客户机应用程序表明它希望为其 wsa:ReplyTo 使用邮箱，则当响应流不包括答复消息时，SOAP 堆栈可以自动轮询该邮箱。这对客户机应用程序隐藏了大部分 WS-Polling 的使用。（是的，它仍需指明使用哪个邮箱，但客户机应用程序本身不再处理轮询了。）同样地，该客户机 SOAP 堆栈也可以使用该“hold it” URI 来代替匿名 URI（无论是否具有客户机应用程序的知识），这使得它能够轮询响应，而无需应用程序对其进行显式处理。

这些只是 WS-Polling 可能的用法和功能中的一部分。要全面了解 WS-Polling，请参阅 WS-Polling 规范（请参阅[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html#resources]参考资料[/URL]）。

[URL=http://www-128.ibm.com/developerworks/cn/webservices/ws-pollingpaper.html#main]回页首[/URL]

结束语

目前存在多个轮询解决方案以及各种规范，这种现象清楚地说明了人们迫切地需要这种类型的解决方案。虽然这些解决方案只对各个规范的特定问题空间有效，但是 WS-Polling 不仅提供了一种更为通用的解决方案来解决所有这些问题，而且还提供了一种所有这些解决方案都可以重用的单一基础实现。整个 WS-* 规范中存在的功能重复可能会使实现人员及其客户更加茫然不知所措。

本文探究了 WS-Polling 如何用于支持真正的异步消息传递模型（即使存在防火墙阻碍），以及 WS-Addressing 如何使这些都成为可能。WS-Polling 已作为“Member Submission”提交给 W3C 组织，而且如果您想实际操作一番，IBM 的外部 WS-RM 互操作端点为您提供了使用 WS-Polling 的机会。该端点使用一个 WS-Polling SOAP 消息主机（位于 http://mailbox.soaphub.org）。要了解更多有关这一新规范的信息，请随时联系本文作者。

参考资料

您可以参阅本文在 developerWorks 全球站点上的 [URL=http://www.ibm.com/developerworks/webservices/library/ws-pollingpaper.html?S_TACT=105AGX52&S_CMP=cn-a-ws]英文原文[/URL] 。

[URL=http://www.ibm.com/developerworks/webservices/library/ws-address.html?S_TACT=105AGX52&S_CMP=cn-a-ws]The hidden impact of WS-Addressing on SOAP[/URL]

您可以通过以下链接获得这些 Web 服务规范的更多信息：
[URL=http://www.ibm.com/developerworks/cn/webservices/specification/ws-polling/]Web 服务轮询 (WS-Polling)[/URL]
[URL=http://www.ibm.com/developerworks/webservices/library/specification/ws-add/?S_TACT=105AGX52&S_CMP=cn-a-ws]Web 服务寻址 (WS-Addressing)[/URL]
[URL=http://www.ibm.com/developerworks/webservices/library/specification/ws-rm/?S_TACT=105AGX52&S_CMP=cn-a-ws]Web 服务可靠消息传递 (WS-Reliable Messaging)[/URL]
[URL=http://www.ibm.com/developerworks/webservices/library/specification/ws-notification/?S_TACT=105AGX52&S_CMP=cn-a-ws]Web 服务通知 (WS-Notification )[/URL]
[URL=http://wsi.alphaworks.ibm.com:8080/wsrm/index.html]Web 服务可靠消息传递演示 (WS-Reliable Messaging Demo)[/URL]

关于作者

Doug Davis 是 IBM Software Standards 部门的架构师。他以前担任过的职务包括 Emerging Technologies Toolkit、WebSphere Machine Translation、Team Connection 和 IBM Fortran 90 的技术总监。您可以通过 [URL=mailto:dug@us.ibm.com?cc=]dug@us.ibm.com[/URL] 与 Doug 联系。

[此贴子已经被作者于2006-10-19 12:02:25编辑过]


	W 3 C h i n a ( since 2003 ) 旗下站点苏ICP备05006046号《全国人大常委会关于维护互联网安全的决定》《计算机信息网络国际联网安全保护管理办法》	156.250ms