防火墙：Web服务不可逾越的障碍？

    本文介绍如何使用 Web 服务轮询(Web Services Polling，WS-Polling)来解决异步消息传递中的难题。这种基于 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 响应消息仍无法异步返回给他们。那么，您该如何做呢?

　　他山之石，可以攻玉

　　如果您看到其他基于 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 服务调用结果的标准方式，而且不需要编写大量的代码来执行该操作。

　　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>