使用基于 SOAP 的中介体构建 Web 服务功能链

文档选项 未显示需要 JavaScript 的文档选项

级别： 初级

Anbazhagan Mani, 软件工程师, IBM Software Labs
Arun Nagarajan, 软件工程师, IBM Global Services

2002 年 9 月 01 日

中介体（intermediary）是一个实体，它位于客户机和服务提供者之间并向客户机提供额外的服务。在本文中，Anbazhagan Mani 和 Arun Nagarajan 介绍了 Web 服务的 SOAP 中介体。您将了解到中介体在 Web 服务环境下可以提供哪些种类的服务，并深入了解如何将中介体的有关信息存储到 SOAP 头中。您还将看到这项技术中仍然存在的一些潜在的隐患，开发者需要解决这些隐患以加快这项技术的广泛采用。

中介体是 位于客户机和服务提供者之间的实体，它提供额外的功能和增值服务。基于 Web 的中介体正在广泛使用中，当数据在 Web 客户机和服务器之间流动时，中介体通过对其进行修改和改进提供诸如定制、个性化、高速缓存、过滤和代码转换之类的功能。中介体的工作流程是：解释消息、执 行消息的功能并将更改后的消息转发给最终接收方。客户机和服务之间可以有许多个中介体，在其中，消息从一个中介体转发到另一个中介体，直至到达最终目的地 为止。

中介体提供不干扰的（nonintrusive）方式来扩展客户机和服务器的功能。中介体还提供了灵活性，因为可以动态添加或删除它们。中介体在现实世界中得到了广泛使用；请参阅下面的 侧栏来看一个示例。在本文中，我们将介绍 SOAP 中介体的细节问题，特别是要详细讲解一种方法，消息的 SOAP 头用这种方法可以确定消息在各个中介体之间进行传递时经过的路径。我们还将简要地看一看您在工程中可以使用 SOAP 中介体的一些方式。

用 SOAP 增加可扩展性

中介体在 Web 服务世界中意义重大。Web 服务协议（特别是 SOAP）为中介体提供简洁的、分散的和模块化的支持。中介体本身可以作为 SOAP 服务实现。可扩展性一直以来都是 SOAP 的主要设计目标之一，通过使用 SOAP 可扩展性模型可以支持中介体。SOAP 的可扩展性是由它的头（特别是 actor 属性和 mustUnderstand 属性）产生的。有些人认为，因为 SOAP 可以利用 HTTP 可扩展性，所以它不需要定义自己的可扩展性机制。但是，从 Web 服务栈和定义 SOAP 和 HTTP 的各层的设计来看，这个观点没有多大意义。

在 图 1（摘自 IBM 的 Web Services Conceptual Architecture 白皮书；请参阅 参考资料以 获得到这篇白皮书的链接）中，您可以看到 HTTP 是传输层协议，SOAP 是消息传递层协议。SOAP 可以和各种传输协议一起使用 — 除 HTTP 之外还包括 SMTP、JMS 和其它协议 — 并且不依赖于任何特定的网络协议。虽然 HTTP 是一个被广泛使用的 SOAP 协议，但是 SOAP 工具箱供应商也已经开始提供对其它协议（如 SMTP）的支持了。尽管 SOAP 可以利用像 HTTP 的传输层可扩展性机制这样的传输层可扩展性机制，但是我们不应该忘记 SOAP 消息在到达最终目的地之前可能在几个不同的传输层协议上传输。在这样的情况下，我们就不希望使用 HTTP 扩展框架。

SOAP 中介体的目的是提供一种机制，该机制允许 SOAP 应用程序提供并访问增值服务和功能。SOAP 中介体可以处理传送给它们的消息，然后将这些消息转发给下一个目的地。这些中介体可以沿 SOAP 消息在服务客户机和服务提供者之间所经过的路径放置（请参见 图 2）。

使用 SOAP 头沿 SOAP 消息路径放置 SOAP 中介体。SOAP 头条目的属性 — actor 和 mustUnderstand — 确定了谁应该处理头以及处理是否是必选的。

SOAP actor 属性在标识 SOAP 头条目的哪一部分将被传送给接收方时起了关键作用。接收方可以是一个中介体，也可以是 SOAP 消息的最终目的地。中介体和最终目的地都是用 URI 标识的。当没有 actor 属性时，头条目的 SOAP 处理器就是 SOAP 消息的最终目的地。

WebSphere 和基于 Web 的中介体 IBM WebSphere Transcoding Publisher 使用基于 Web 的中介体（使用 WBI 技术）来执行它的代码转换。 代码转换（Transcoding）是一个改变数据格式（例如，通过应用样式表将 XML 文档转换成 HTML）的过程。如需更多关于 WebSphere 的信息，请参阅下面的 参考资料部分。

SOAP mustUnderstand 属性用于指出一个头条目是必选的还是可选的。这个属性的值可以为 1 或 0。1 表示必须由头中所指出的参与者来处理这个头条目，0 表示这种处理是可选的。在头中不包含 mustUnderstand 等同于将其值设置为 0。

SOAP 中介体（或称 SOAP 处理节点）应该遵循用来处理头条目的 SOAP 规范所规划的处理模型。这个处理模型规定：

• 中介体仅可以处理传送给它的 SOAP 消息的头条目。
• 中介体在将消息转发给下一个接收方之前，应该删除传送给它的头条目。
• 中介体可以通过在头中添加新的 actor 条目和 mustUnderstand 条目从而将新的中介体添加到消息的路径上。
• 每当中介体发生故障时，都应该生成错误消息。生成的 SOAP Fault 元素必须包含一个 faultactor 元素（它的值指出发生故障的中介体）。

回页首

实现基于 SOAP 的中介体

迄今为止，我们已经知道了 SOAP 中介体是沿 SOAP 消息路径分布的 SOAP 处理节点，它们可以处理和转发 SOAP 消息。现在，让我们来看一些实现该功能所涉及的技术问题，包括：

• 路由
• 安全性
• 了解服务提供者所支持的中介体

路由

路由是经由一系列 SOAP 中介体传递 SOAP 消息的过程。SOAP 指定了一种为 SOAP 消息设定目标的机制，但是没有指定路由这些消息的机制。

例如，我们来考虑这样一条 SOAP 消息，它从一台服务客户机经由中介体 A 和 B 传送到服务提供者（请参见 图 2）。从服务客户机发送来的 SOAP 消息使用 SOAP actor 属性把该消息的一部分的 目标设为中介体 A，另一部分的目标设为中介体 B，但它并不包含 SOAP 消息的路由信息。换言之，它并不说哪个中介体应该第一个进入消息路径。

因为 SOAP 消息被绑定到诸如 SMTP 和 HTTP 这样的传输协议上，所以您可以说：可以使用这些协议的消息路径模型来定义 SOAP 消息路径。但是这些协议缺少到 SOAP 目标模型的映射。所以，这些协议定义的消息路径仅可用于描述 SOAP 消息路径中一个单独的跳转，并不足以描述 图 2中所说明的从服务客户机到服务提供者的 SOAP 消息路径。

WS-Routing（Web 服务路由）

被 提议的 WS-Routing 规范定义了一个消息路径模型，该模型与 SOAP 消息模型完全兼容并使得描述 SOAP 消息从服务客户机到服务提供者的完整交换成为可能。WS-Routing 还使用 SOAP 可扩展性模型描述 SOAP 消息路径。这个规范定义了一个单独的 SOAP 头条目，为了沿 SOAP 消息路径交换消息，该条目描述了 SOAP 消息的正向 — 也可以选择反向的 — 消息路径。WS-Routing 通过定义一个可选的反向路径来启用双向消息交换模式，如请求／响应模式。

WS-Routing 将 SOAP 消息发起者（消息开始的地方）描述为初始 WS-Routing 发送方。前面提到过，WS-Routing 用一个头条目描述消息路径。WS-Routing 头条目指出了正向消息路径中的最终 WS-Routing 接收方以及零个或更多的 WS-Routing 中介体。最终 WS-Routing 接收方是初始 WS-Routing 发送方发送的消息的最终目的地。使用适当的头条目，您可以定义一条可选的反向消息路径，为消息指出返回初始 WS-Routing 发送方的可能路径。在返回的途中，反向路径变成正向消息路径。对于转发消息路径和反向消息路径来说，消息交换规则是相同的。这意味着消息的发起者总是初始 WS-Routing 发送方，最终目的地总是最终 WS-Routing 接收方。

WS-Routing 定义了一组确定的规则来描述从 WS-Routing 发送方到 WS-Routing 接收方的消息路径。

• 初始 WS-Routing 发送方必须生成一个 WS-Routing path 头以指出 WS-Routing 消息路径。应该用 via 元素指出消息路径中的中介体。这个元素应该作为 fwd 元素或 rev 元素的子元素出现。 fwd 描述转发消息路径， rev 描述反向消息路径；后者是可选的。如果出现了 rev 元素，当消息沿转发消息路径传送时，动态构建反向消息路径。可以用 to 元素指出 WS-Routing 消息的最终目的地。如果 to 元素没出现在 path 头条目中，则由最后一个 via 元素指明最终目的地。 to 元素和 via 元素通过 URI 标识接收方和中介体。
  
  
• WS-Routing 接收方应该一接收到消息就检查 path 元素，以验证它确实是消息的指定接收方。如果 fwd 元素中没有 via 子元素，或者根本就没有 fwd 元素，则应该检查 to 元素以查找该信息。当 to 元素为空或者它标识的是另一个接收方时，应该生成一个 WS-Routing 错误。如果出现了包含一个或多个 via 元素的 fwd 元素，接收方应该删除并检查 fwd 元素的第一个 via 子元素，并验证它是不是消息意想中的接收方。如果不是，接收方应该生成一个错误。当 (1) 删除第一个 via 元素后 fwd 元素中不列有 via 元素，以及 (2) 没有 to 元素的时候，这个接收方将变成最终目的地。
  
  
• WS-Routing 中介体应该检查 fwd 元素以查找 via 元素。如果有 via 元素，中介体应该把 WS-Routing 消息转发给消息路径中的下一个中介体，下一个中介体的身份可以从 via 元素处获得。如果没有 via 元素，则应该将消息转发给最终目的地，最终目的地由 to 元素标识。如果有 rev 元素，那么中介体应该添加一个 via 元素作为该 rev 元素的第一个子元素。这个 via 元素的值应该指出反向路径。当转发过程失败或者无法提供反向路径信息时，应该生成错误。
  
  
• 如果将 WS-Routing 消息的反向消息路径用于发送另一条消息，那么 rev 元素中有序的 via 元素列表将被用作 fwd 元素中的 via 元素列表。
  
  
• 只有一个初始 WS-Routing 发送方可以插入用于描述反向消息路径的 rev 元素。

WS-Routing 消息和 SOAP 消息以相同的方式传送。WS-Routing 消息通过底层协议被传递给转发消息路径中的第一个 WS-Routing 接收方。如果这个接收方是一个中介体，则消息被转发给转发消息路径中的下一个接收方，下一个接收方可以是另一个中介体，也可以是最终目的地。

下面的 清单 1和 2中的简单示例说明了如何使用 WS-Routing 指定转发消息路径。 图 3说明了流程：WS-Routing 服务客户机是初始 WS-Routing 发送方，WS-Routing 服务提供者是最终 WS-Routing 接收方。通过 WS-Routing 中介体传送消息。

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <mp:path xmlns:mp="http://schemas.xmlsoap.org/rp/" 
      SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="1">
     <mp:action>http://www.ibm.com/quotes</mp:action>
      <mp:to>http://www.ibm.com/quotesservice</mp:to>
      <mp:fwd>
         <mp:via>http://www.compress.com/compress</mp:via>
      </mp:fwd>
      <mp:rev>
         <mp:via/>
      </mp:rev>
      <mp:from/>
         <mp:id>uuid:AS2324S4-CE2A-F9DC-BCB7-AS42B16F61E1</mp:id>
    </mp:path>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
        ...
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

rev 元素的 via 子元素包含一个空值。该值表示使用隐式反向路径，该路径将由底层协议提供。除了我们已经讨论过的元素之外，消息还定义了一些元素。 action 元素用于指出消息的意图； from 元素用于指出消息的发送方； id 元素表示消息独一无二的标识，并且它应该仅由初始 WS-Routing 发送方生成。

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Header>
    <mp:path xmlns:mp="http://schemas.xmlsoap.org/rp/"
       SOAP-ENV:actor="http://schemas.xmlsoap.org/soap/actor/next" SOAP-ENV:mustUnderstand="1">
<mp:action>http://www.ibm.com/quotes</mp:action>
      <mp:to>http://www.ibm.com/quotesservice</mp:to>
      <mp:fwd/>
      <mp:rev>
        <mp:via/>
      </mp:rev>
      <mp:from/>
      <mp:id>uuid:AS2324S4-CE2A-F9DC-BCB7-AS42B16F61E1</mp:id>
    </mp:path>
  </SOAP-ENV:Header>
  <SOAP-ENV:Body>
        ...
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

因为您可以用 WS-Routing 描述一条完整的消息路径，所以 SOAP 消息不需要到传输层协议（如 HTTP）的绑定来描述消息路径。

安全性

SOAP 消息有可能经过沿消息路径分布的一组中介体从它们的初始发送者传送到最终目的地。根据定义，SOAP 中介体位于中间且易受攻击。运行中介体的系统上出现的安全性违规会导致严重的安全性问题，如丢失安全信息和消息完整性，这将引起信任问题。目前，安全套接 字层（Secure Socket Layer，SSL）协议和传输层安全性（Transport Layer Security，TLS）协议被用于为 Web 服务提供传输层安全性。尽管 SSL／TLS 可以确保那些不经过中介体传送的 SOAP 消息的安全性，但是中介体上的安全性违规将导致不安全的端到端通信。为了改善这种情况，开发者需要将应用程序级别的安全性引入到 Web 服务世界中。另外，当跨不同的协议传输 SOAP 消息时，有潜在的安全性危险。当需要将消息的初始发送者的关于可靠性的指示从一种安全传输协议翻译到另一种安全性传输协议时，可能会发生安全性违规。

将安全性功能集成到应用程序中以保护端到端通信，并避免从一个安全协议到另一个安全协议传送安全性信息过程中的安全性违规，这并不是一个容易的任务。应该在 SOAP 层用现有的安全传输机制（如 SSL）解决这些安全性问题以提供最强大的保护。

WS-Security（Web 服务安全性）
IBM 和 Microsoft 提议的 Web 服务安全性模型支持结合 WS-Security 规范使用现有的安全传输机制（如 SSL/TLS）和其它规范，以便提供跨多次传送、多个中介体和多个传输协议的消息完整性和机密性。WS-Security 规范定义了用于保护消息的完整性和机密性的核心功能程序，以及用于把与安全性相关的声明和消息关联起来的机制。（请参阅下面的 参考资料部分以获得更多关于 WS-Security 的信息。）

了解服务提供者所支持的中介体

服务客户机应该了解服务提供者所支持的中间体的情况。具体说来就是服务客户机应该知道在消息到达最终目的地之前哪个中介体正在处理消息路径内的请求；客户 机应该信任所有这些中介体。应该有一个查询和检查服务提供者以获得关于它所支持的中介体的信息的标准方法。这是开发者需要改善适当的标准以鼓励使用中介体 的另一个领域。

回页首

潜在的基于 SOAP 的中介体的真实服务

随着 Web 服务的发展，我们期望有大量基于 SOAP 中介体的应用程序。既然您了解了 SOAP 中介体是如何工作的，那我们就快速看一下 Web 服务设计师可以使用的一些可能的方法。

服务级别协议

将来，Web 服务将要求在服务客户机和服务提供者之间建立 服务级别协议（service-level agreement，SLA）。（如需更多关于 Web 服务和服务级别协议的信息，请参阅下面的 参考资料部 分。）这些 SLA 将包括服务质量（quality of service，QoS）保证（设置响应时间、可靠性等等的保证级别）、异常规则以及违反保证的惩罚。第三方中介体可以提供重要的、与 SLA 有关的服务：协商和验证 SLA、检查 SLA 一致性以及收集客户满意尺度。随着 Web 服务的发展，我们可能会看到一类新型的被称为 SLA 机构的公司的发展，它们类似于目前提供数字证书的认证机构。这些可信的 SLA 机构将使用 SOAP 中介体来提供上述 SLA 服务。

SOAP 压缩

SOAP 用 XML 作为它的有效负载。因为 XML 很冗长，所以存储在 XML 文档中的数据占据的内存通常比以二进制形式存储的相同数据占据的内存大的多。这种消息大小上的增加有效地导致了数据传输时间的增加。SOAP 中介体节点可以被用于压缩和转发 SOAP 消息。在接收端应该有另一个中介体节点，它可以对消息进行解压缩并将消息转发给最终目的地。这些中介体可以保存在 Web 服务网关处。

QoS 中介体

在某些 Web 服务使用情况下，用户将需要高性能、可靠的且安全的方式来传送服务请求和接收响应。这可能涉及到许多基础架构要求，还要使用 VPN；这么高的要求是某些企业所不希望的。这些服务可以由中介体提供，一经要求，感兴趣的企业就可以通过这些中介体发送它们的消息。这些中介体使用私有 网络、消息队列和发布／订阅系统可以提供可靠的服务。它们还可以提供诸如高速缓存、日志记录等等的增值服务。

回页首

结束语

在 本文中，我们了解了 SOAP 和 XML 如何提供一种简洁的、模块化的方法来支持中介体。另外，我们还了解了可以制作中介体模型的潜在增值服务和需要进一步努力才能解决的问题。随着 Web 服务的发展，我们期望这些问题会得到解决（例如，通过 WS-Routing 和 WS-Referral）。企业可以利用上面概述的中介体模型来提供增值服务。Web 服务设计师可以设计他们的系统来利用这个模型，这提供了一种灵巧的方式来通过第三方提供的外包的增值服务来路由服务请求和响应。

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
  
  
• 请阅读 SOAP 规范以了解更多关于 SOAP 头的详细介绍。
  
  
• 想了解更多信息吗？DeveloperWorks SOA 与 Web 服务专区中有数百篇关于如何开发 Web 服务应用程序的初级、中级和高级教程。

• 通过参加 developerWorks blogs 加入 DeveloperWorks 社区。
  
  

作者简介

		Anbazhagan Mani 是印度 IBM Software Labs 的一名软件工程师。他拥有 WebSphere 工具系列、XML、Java 技术、BPM、工作流以及对象技术方面的工作经验。最近，他一直在从事 Web 服务 QoS、P2P 计算和网格技术方面的工作。

		Arun Nagarajan 是印度 IBM Software Labs 的一名软件工程师。他以前曾经使用过 XML 以及诸如 JavaBeans、J2EE 和 WebSphere 这样的 Java 技术。目前，他一直从事不同的 Web 服务技术，包括 SOAP、WSDL、UDDI 和 WSXL。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？