了解 Web 服务规范: 第 1 部分：SOAP

 首先，让我们从总体上了解一下什么是 Web 服务，以及它们为何对软件开发重要。
究竟为什么重要呢？

如 果您没有听说过有关面向服务的体系结构 (SOA) 和 Web 服务的大量信息，您就不会阅读本文，那么问题就应该是，为什么此内容这样重要？答案是，此内容之所以重要，是因为这是应用程序彼此进行通信的方式的典型变 化。SOAs 已经存在很长很长时间了。SOA 最初主要由中间件应用程序组成，至少进行连接的两端都属于同一种类型的中间件。另一方面，Web 服务由一组标准组成，用于在不需要特定类型的中间件、编程语言甚至操作系统的前提下让各种不同的系统进行通信。接下来，让我们了解一下其发展的历程。

传统应用程序

首先从计算机发明开始，当时给人感觉非常不错。计算机能执行奇迹般的任务，可实现很多手动工作的自动化，包括复杂的计算、财务工作等等很多其他任务。

但 传统应用程序是“竖井”(Silo) 型的。人力资源应用程序无法与财务应用程序真正通信，而后者又无法和分布应用程序进行真正的通信。所有这些应用程序都有独立的领域，在独立的计算机上运 行，尽管很有用，但并不能很好地在彼此间共享数据。当时可以选择对批处理流程进行连接，以将数据从一个系统移动到另一个系统，但这并不适合进行实时集成。

分布式计算

在 我们的进化链中的第二步是分布式计算。分布式计算允许不同的应用程序彼此进行通信（即使位于不同的计算机上也是如此）。CORBA、MTS 和 Enterprise Java Bean (EJB) 等技术提供了包含各种类别的注册中心的系统，因此应用程序可以找到其希望与之进行交互的组件，然后像调用本地的组件一样调用这些组件。

这些系统由可同时满足这两个要求的中间件（或更具体一些，面向消息的中间件）提供支持。现在能以特定的方式构建应用程序，即使位于不同的地理位置，也能访问其他系统上的资源。

但仍然有一个问题。虽然系统可以自由地与系统内的任何对象进行通信，但仍然是一个封闭的系统。至少，客户机应用程序必须与服务器应用程序使用相同的技术。另外，通常并不会将系统设计为从创建其的个体组织外进行访问。

Web 服务

此进化链中下一个几乎不可避免的链接点就是 Web 服务。“Web 服务”基于 XML 和 HTTP（大多数情况下），对很多人具有不同的含义，但在此处，我们要将 Web 服务作为系统间基于 SOAP 的消息交换进行讨论。

这 些消息由 XML 组成（XML 是一个基于文本的开放标准），可由来自任何应用程序（任何设计为接收此类消息的应用程序）的任何人进行访问。这就扩展了应用程序的范围，从而包含任何可通 过网络对其进行访问的任何人。（如果这让您开始考虑安全问题，不要紧，您将在本系列的第 4 部分了解如何处理这方面的问题。）

基于 SOAP 的 Web 服务将要发送与清单 1 中所示类似的 XML 消息。

清单 1. 基于 SOAP 的 Web 服务

<SOAPenv:Envelope xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <SOAPenv:Body> <req:getNumberOfArticles xmlns:req="http://daily-moon.com/CMS/"> <req:category>classifieds</req:category> </req:getNumberOfArticles> </SOAPenv:Body> </SOAPenv:Envelope>

这些消息将从一个系统进入另一个系统（通常通过 HTTP）。接收系统对消息进行解释，进行应该进行从处理，然后发送另一个 SOAP 消息作为响应。

这个系统很简单，正因为如此，有很多企业级计算方面的内容都尚未涉及。幸运的是，其中的很多方面已被纳入考虑范畴，且具有自己的相关规范来确定此事务应如何进行，以包含传统的面向消息的中间件的很多安全和其他方面的内容。

其他类型的 Web 服务

如 果我没有说明 SOAP 并不是唯一的处理 Web 服务的方法，那就有些失职了。有很多其他基于 XML 的方法用于在系统间发送信息，其中一些适用于企业环境，而另一些则不适合此用途。例如，Amazon 是为公众提供对其系统的 Web 服务访问的第一批基于 Web 服务的公司之一。Amazon 包含了一个基于 SOAP 的服务，但也提供了一个基于 Representational State Transfer (REST) 的服务。

REST 是一种 Web 服务类型，其中，用户直接访问 URL，相应的响应是与清单 2 中所示类似的简单 XML 文档。

清单 2. REST 响应

<currentArticles> <category>classifieds</category> <subcategory>forsale</subcategory> <article id="888204"> <articleHeadline></articleHeadline> <articleText>30 ft ladder, only used once. Willing to let go for half it's worth. Has slight dent near the middle. Harder than a human head. $150 OBO.</articleText> </article> <article id="888242"> <articleHeadline></articleHeadline> <articleText>Vintage 1963 T-Bird. Less than 300 miles. Driven by my daughter until I took it away. Serious inquires only. 555-3264 after 7 PM.</articleText> </article> </currentArticles>

这些消息并没有特定的格式。可以为任何数据。

另一种 Web 服务类型要使用 XML-RPC 之类的标准。在这种情况下，命令将通过与清单 3 中所示类似的 XML 发送到系统。

清单 3. XML-RPC

<?xml version="1.0"?> <methodCall> <methodName>CMS.getNumberOfArticles</methodName> <params> <param> <value><string>classifieds</string></value> </param> <param> <value><string>forsale</string></value> </param> </params> </methodCall>

其响应将采用类似的格式。

在 学习使用 SOAP 的过程中，您可以会打心底里认为 REST 和 XML-RPC 比基于 SOAP 的系统要简单得多。的确如此。在某些情况下 REST 和 XML-RPC 比 SOAP 系统简单。不过，我们讨论的不是在网站上显示天气的简单应用程序。我们此处讨论的是企业级应用程序，而企业级的应用程序需要企业级的属性，如安全、互操作 性等等。这些功能在有关基于 SOAP 的 Web 服务的其他规范中进行了定义，因而，从长期来看，SOAP 更适合用于企业级应用程序。

让我们了解一下这些规范。

基本 Web 服务规范

Web 服务规范通常归为两类：基本 Web 服务规范和扩展 Web 服务规范。基本规范有：

SOAP：SOAP 规范是所有基于 SOAP 的 Web 服务的基础，详细说明了实际消息的格式。其中还详细说明了应用程序应如何对待消息的特定方面（如“Header”中的元素），从而可以创建特定类型的应用 程序，使其中的消息在达到最终的目的地前在多个中间层之间进行传递。本教程将涵盖 SOAP 规范的内容。

WDSL：Web 服务描述语言是详细说明描述基于 SOAP 的 Web 服务的标准方式的规范，包括消息应采用的形式以及应将其发送到何处。其中还详细说明了此类消息的响应。当与相应的工具结合使用时，WSDL 允许以编程方式创建对 Web 服务的调用，甚至不用知道所查找的 Web 服务是什么；应用程序可以从 WSDL 文件中提取这些详细信息，并提供要使用的编程接口。我们将在本系列的第 2 部分讨论 WSDL。

UDDI： 统一描述、发现和集成 (Universal Description, Discovery and Integration) 是一项从最初提出后发生了一系列变化的标准。其最初的目的是为了给各个公司提供在全球注册中心中注册服务并在此注册中心中搜索可能想使用的服务的机制。不 过，由于很多公司对于将其系统对外开放的问题上都相当保守，这个目标并没有完全实现。但是，很多公司已将 UDDI 作为内部的服务及服务信息注册中心使用，本系列第 3 部分将对其使用进行详细论述。

以上是一些基础知识。另外差不多还有数十种扩展标准，可进一步扩展基于 SOAP 的服务的用途。

扩展 Web 服务规范

总共有数十种 WS-* 规范，其中几种对企业尤为有用。即：

WS-Security：此规范处理加密和数字签名，允许创建特定类型的应用程序，以防止窃听消息，且能实现不可否认功能。本系列的第 4 部分将讨论 WS-Security。

WS-Policy：此规范对 WS-Security 进行了扩展，允许更具体地说明谁可以采用何种方式使用服务。本系列的第 5 部分将讨论 WS-Policy。

WS-I：尽管 Web 服务应设计成具有互操作性，但在实际中，各个规范对不同实现的解释的灵活性常常足以导致出现问题。WS-I 提供了一组可用于防止出现各种问题的标准和实践，并提供了标准化测试来检查问题。WS-I 是本系列的第 6 部分将要讨论的主题。

WS-BPEL：单个服务很好处理，但应用程序在大多数情况下则较难处理。企业级计算要求至少将多个服务组合为一个完整的系统，而 WS-BPEL 提供了用于指定创建此类系统所必需的交互（如分支和并发处理）。本系列的第 7 部分将讨论 WS-BPEL。

在 Web 服务中扮演重要角色的其他规范将不在本系列中讨论，其中包括

WS-ReliableMessaging

（允许确定检索一个且仅一个消息副本）、Web 服务资源框架 (WSRF)（允许使用在无状态环境中非常重要的状态）和 Web 服务分布式管理 (WSDM)（讨论 Web 服务的管理和使用问题）。可以在本教程的参考资料中获得有关这些规范及其他规范的更多信息。