当您初次登录到 developerWorks 时，将会为您创建一份概要信息。您在 developerWorks 概要信息中选择公开的信息将公开显示给其他人，但您可以随时修改这些信息的显示状态。您的姓名（除非选择隐藏）和昵称将和您在 developerWorks 发布的内容一同显示。

所有提交的信息确保安全。

当您初次登录到 developerWorks 时，将会为您创建一份概要信息，您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。您的昵称在 developerWorks 社区中必须是唯一的，并且出于隐私保护的原因，不能是您的电子邮件地址。

所有提交的信息确保安全。

My developerWorks:

我的通知：

退出

选择语言：

在 SOAP 应用程序中使用 WSDL

面向 SOAP 编程人员的 WSDL 简介

Uche Ogbuji, 合作伙伴, Zepheira, LLC

Uche Ogbuji 是 Zepheira, LLC 的合伙人，这家公司专门提供下一代 Web 技术解决方案。Ogbuji 是 4Suite 的首席开发人员，这是一种用于 XML、RDF 和知识管理应用程序的开放源代码平台；也是 Versa RDF 查询语言的首席开发人员。他是一位出生在尼日利亚的计算机工程师和技术作家，目前定居在科罗拉多的博尔德。可以通过他的 Weblog Copia 进一步了解 Ogbuji 先生。

简介： Web 服务描述言（Web Services Description Language，WSDL）是用来描述基于网络化 XML 的服务的规范。它为服务提供商提供了一种简单的方法来便描述用于这些服务提供商系统的基本请求格式，无论他们使用的基础协议（如简单对象访问协议或 XML）或编码（如多用途 Internet 邮件扩展）是什么。WSDL 是通用说明、发现和集成（Universal Description, Discovery and Integration，UDDI）倡导的关键部分，用于为电子商务提供联机服务的目录和说明。本文提供了 WSDL 的背景和技术的简要介绍。XML 和 XML 命名空间的知识是读者应必备的知识，熟悉 XML 架构和 SOAP 也很有用。

标记本文！

发布日期： 2011 年 10 月 24 日
级别： 初级
原创语言： 英文
访问情况： 6235 次浏览
评论：

在过去的几年中，出现了一些标准协议，它们提供了 XML 中间件的一个重要组成部分：网络化服务的要求。这些网络化服务要求是通过网络（如 Internet）请求获得来自远程计算机的 XML 相关功能的一种方式。

这导致了 David Winer、IBM、Microsoft 和其他公司之间的标准竞赛 (standards race)，其中包括一些重要条目，如 Allaire 公司的 Web 分布式数据 eXchange（Web Distributed Data eXchange，WDDX）（参见参考资料）、UserLand 公司的 XML 远程过程调用（XML Remote Procedure Call，XML-RPC）、Microsoft 的简单对象访问协议（Microsoft Simple Object Access Protocol，SOAP）（参见参考资料）。与此同时，一些开发人员在通过老式 HTTP 构建应用程序方面做得相当好。这种基于 XML 的网络化服务的最大增长领域是内容交换和联合中。

同样，这里也有一些关于定义这种内容的说明和结构的建议。其中一些重要建议包括来自 Vignette 公司和其合作伙伴的信息内容交换（Information Content Exchange，ICE）（参见参考资料），以及来自 Netscape 和其合作伙伴的 RDF（Resource Description Framework，资源说明框架）站点摘要（RDF (Resource Description Framework) Site Summary，RSS）（参见参考资料）。许多开发人员还可以很好地使用多用途 Internet 邮件扩展（Multipurpose Internet Messaging Extensions，MIME）的通用 Internet 标准。

除此之外，还有其他许多 XML 协议资源；足以使 W3C 拥有全新的 XML 协议工作组来处理这些问题（参见参考资料）。观赏这样的政治争斗非常有趣，因为 W3C 可以尝试着从这种混乱中获取相关的利益。

在 Web 应用程序之间的众多令人眼花缭乱的通信方式中，用户对描述基于 XML 网络服务的机制的需要已经很明确，无论他们使用通信协议和请求结构是什么。借助这种机制，许多高级 Web 开发任务都可以获得额外的自动化措施。例如：

门户工具包可为内容部分提供插件系统，以便在没有深入钻研许多技术细节的情况下，使设计人员从大量联机服务中挑选服务时变得更容易。
产业团体和服务经纪公司都可以发布全面的联机 XML 服务白皮书和黄皮书，允许开发人员迅速做出技术评估和比较。
服务提供商可快速发布其请求结构的标准格式的更新和版本，以帮助通过开发人员自动采用这种格式。

IBM、Ariba 和 Microsoft 打算开发这样一种机制，并打算在 9 月 25 日将它与 Web 服务说明语言（Web Services Description Language，WSDL）1.0 版一起发布（参见参考资料）。令人感到相当奇怪的是，此 “1.0” 版规范几乎是从那时起才开始包装的；因此在发布之前，没有为 XML 社区留下任何评价的机会。无论如何，WSDL 都是一种用于描述网络化 XML 服务的格式，满足了我早前描述过的大部分需求。

背景知识

WSDL 以前的一些重叠的规范占据了一些空间。让我们简单回顾一下 menagerie，提供一些背景知识。WebMethod 的 Web 界面定义语言（Web Interface Definition Language，WIDL）（远程 Web 服务说明的最新规范之一）是一种 XML 格式，它采用了远程过程技术（如 RPC 和 CORBA）的用户熟悉的一些方法（在远程计算机上进行访问就像在本地计算机上一样）。有一些方法适合在 WIDL 与 UserLand 提供的 XML-RPC 系统之间使用。前者已经逐渐退出舞台，因为实践已经证明，基于消息的 XML 技术比其程序替代品更受欢迎。后者似乎将让位给 SOAP，SOAP 支持面向消息的方法和过程方法。

SOAP 描述了信封和消息格式，并且有一个基本请求/响应握手协议。此外，Microsoft 在今年的早些时候开发了 SOAP 合同语言（SOAP Contract Language，SCL），为基于 SOAP 的应用程序提供联机服务说明系统。在 SCL 中，此协议的功能（来自 IBM 和 Ariba 的其他协议和相关功能除外）已经非常类似于 WSDL。

在 WSDL 出现以前，一个由 36 家公司结成的联盟（包括 IBM、Ariba 和 Microsoft）启动了通用说明、发现和集成 (UDDI) 系统（参见参考资料），这是一个管理计划，为查询目录和服务供应商提供包含详细 API 的联机业务服务的标准目录。

在 WSDL 出现以前，Microsoft 一直忙于 Web 服务说明领域方面的工作。它创建了另一个参与者，即 Web 服务发现（Discovery of Web Services，DISCO）（参见参考资料），DISCO 目前位于 limbo 中（属于 Microsoft 官方的 .NET 战略计划以外的产物）。DISCO 描述了如何为特殊要求寻找（“发现”）服务的 SCL 说明。坦率地说，虽然通过阅读 DISCO 规范很难想象或了解它所提供的价值，但是 UDDI 和 WSDL 已经采用了这种用法。

与 Microsoft 在 SCL 上的做过努力一样，IBM 也正在创建网络访问服务规范语言（Network Accessible Service Specification Language，NASSL）（参见参考资料）。人们还可以看到，IBM 将其想法完全融入到了 WSDL 以及其 NASSL 编辑器中。IBM 还利用服务的广告和发现（Advertisement and Discovery of Services，ADS）进入服务发现行为的研究。似乎从来都没有正式的 ADS 规范，尽管来自 IBM alphaWorks 项目的 Web 服务工具包中包含 ADS 的参考实现（参见参考资料）。

如果您现在发现自己已经彻底糊涂了，这是很正常的事情。不止一个人曾打趣说 XML 是一个对大量其他规范没有其他用途的规范。UDDI 组的形成为服务说明领域提供了一些有利因素。摆脱了目前的纷乱之后就会出现一个简单的秩序，并为基于 Web 的服务创建全面的协议。对于服务发现、说明、请求/响应协议、请求结构和数据类型、语义发现以及传输协议来说，这可能是一种既独立但又相互联系的形式。图 1 提供了一张建议图表，展示了这种秩序，并采用适当方式放置了我提到过的各种规范。我们希望，该图有助于澄清我们说明的这种景象。在给图片中，WSDL 处理了特定用途的服务描述机制。

图 1.服务角色和交互
图 1. 服务角色和交互

回页首

示例 WSDL 文档

让我们通过以下示例了解 WSDL 如何使用 SOAP。假设我们是掌管虚构公司 snowboard-info.com 的企业家，snowboard-info.com 是一个滑雪板行业的数据库，它允许其他人从滑雪板制造商那里查询支持情况。使用像清单 1 中那样的 SOAP 请求，客户端可发送请求，请求从服务器检索此信息。用自然的语言，清单 1 封装了问题 “哪些专业滑雪板爱好者支持 K2 FatBob？”

清单 1. SOAP 1.1 请求

				

POST /EndorsementSearch HTTP/1.1
Host: www.snowboard-info.com
Content-Type: text/xml; charset="utf-8"
Content-Length: 261
SOAPAction: "http://www.snowboard-info.com/EndorsementSearch"
<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarder xmlns:m="http://namespaces.snowboard-info.com">    
      <manufacturer>K2</manufacturer>
      <model>Fatbob</model>
    </m:GetEndorsingBoarder>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

作为响应，服务器可为上述请求发送 SOAP 1.1 响应（sans HTTP 头）消息，如清单 2 所示。它用自然的语言封装了简单的字符串响应 “Chris Englesmann”。

清单 2. SOAP 1.1 响应

				

<SOAP-ENV:Envelope
  xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
  SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <m:GetEndorsingBoarderResponse xmlns:m="http://namespaces.snowboard-info.com">
      <endorsingBoarder>Chris Englesmann</endorsingBoarder>
    </m:GetEndorsingBoarderResponse>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

如今，通过 SOAP 规范，请求的整体结构、相关数据类型、所用的 XML 元素架构以及其他相关事宜都留给了贸易伙伴来处理。WSDL 提供了服务规范的标准，统一了处理上述事宜所需的请求和要求的类型。

为了让所有热门滑雪板门户网站和讨论站点都挂接到我们的系统，可能需要定义 WSDL 通信端口。通过发布如清单 3. 滑雪板支持查询的 WSDL 说明所示的一些服务要点的 WSDL 说明，我们可以完成此操作。虽然清单 3 可能看起来很长，但 WSDL 其实非常简单。我们的示例 WSDL 文档几乎涉及了 WSDL 的各个方面，而且还有一大块 XML 架构方面的内容，并且利用绑定了 WSDL 的 SOAP。最后一部分（尽管在相同的服务说明中已提出）从技术上说是一个标准的服务说明扩展。

所有一切都包含在描述一系列相关访问的 <definitions> 元素中。<Types>元素允许对消息或程序内容使用低级的数据分类规范。虽然通过命名空间可扩展性可能允许使用不同的机制，但大多数用户很有可能会选择 XML 架构，我们的示例中也使用了该架构。这指定了一个简单元素内容模型，与您在清单 1 和清单 2 中可以看到的示例交换相一致。WSDL 提供了一个系统，可导入作为独立资源的数据分类规范，在多个使用域中使用的复杂消息中，可能有许多这种资源。

<Message> 元素定义了通讯中每一个独立传输的数据格式。在我们的案例中，一条消息代表 EndorsingBoarder 请求和对方的响应。在我们的示例中，这是一个简单的声明，消息的主体是来自类型部分的架构的特殊元素。消息部分的传输破坏与否取决于数据的逻辑视图。例如，如果传输是一个远程过程调用，那么可将消息分为多个部分，其中之一是过程名称和元数据，剩余的为程序参数。数据分类的粒度与是否消息分为多个部分之间有一定的关系。

<PortType>元素可分组形成单一逻辑操作的消息。例如，在我们的案例中，可以有一个 EndorsingBoarder 请求，它触发了一个 EndorsingBoarder 响应，或者在错误或异常的情况下，它触发了 EndorsingBoarderFault 。将这种特殊的交换组合在一起就形成了 WSDL 端口类型。如您所见，我们通过合格名称的引用来确定与消息的关系。

在 WSDL 中只有 4 种有内置支持的操作形式：单向、请求-响应、要求-响应 和通知。后两种与前两种是简单 “对立” 关系，唯一的区别在于有问题的端点是在初始消息的接收端还是发送端。通常，WSDL 支持单项（单项和通知）和双向（请求-响应和要求-响应）端口类型。与 CORBA 模型不同，我们仅支持双向端口类型的错误——现在我将把这两种方法之间不可避免的争论留在这里。

随着上述两种端口类型之间的一些引用的增加，到目前为止，WSDL 文档已经从具体和实际形式（数据类型）转变为抽象和逻辑形式（消息和端口类型）。<Binding> 元素是在逻辑和实际模型之间提供牢固连接的位。在这里，它采用了我们通过抽象端口类型定义的操作，并将其连接到如何通过 SOAP 传输它的具体说明。在这里我们实现了刚刚提过的 SOAP 到 WSDL 的扩展。WSDL 还提供对裸机 HTTP 和 MIME 的绑定，以及其他协议的全面扩展。

我们的示例绑定将 GetEndorsingBoarderPortType 指定为 SOAP “样式” 的 Document 。该样式可能是 RPC 或 Document ，前者更倾向于沟通过程，后者是一种消息交换方向。当然，这两种样式之间的分界线相当宽泛，所以不难猜测，许多给定端口类型属于哪种样式的讨论都毫无结果。对于这类讨论，我的意见是：几乎所有地方都会用到 Document。

我们的绑定也将网络传输指定为 HTTP——SOAP 可通过其他方式（如 SMTP）传输。<soap:operation> 元素开始用于处理细节问题，并将端口类型中的个人消息映射到处理这些个人消息的 SOAP 传输的定义中。请注意，我们指定了 SoapAction，对于 HTTP 上的 SOAP 而言，SoapAction 是必不可少的。给定的值必须用在实际消息的 HTTP 头中，以指示该消息的 “意图”。据推测，将来某一天会允许对 SOAP 流量使用智能代理和防火墙。

最后的元素（<service>）定义了通信端点的物理位置。它使用了先前指定的端点类型和绑定，并大致给出了所描述服务的特殊提供商的 Web 地址或 URI。当然，在我们的示例中，它是我们在滑雪板产品查询中建立的用来处理流量的 SOAP 服务器的地址。

但是，如果启动了该服务，它是否会与用户产生冲突，且开始出现淹没我们的服务器的流量？我们可能会决定在欧洲建立一个镜像。在这种情况下，虽然服务是完全相同的，但是我们会在可以获得该服务的地方提供一个独立的 URI。在 WSDL 架构中，为了应对这种情况，我们要做的事情就是修改我们的 WSDL 文档，以便添加另一个 <service> 元素，如清单 4 中所示。

清单 4. 用于处理多站点的替代 <service> 元素。

				

<service name="EndorsementSearchEuropeanService">
   <documentation>snowboarding-info.com Endorsement Service European
      Mirror</documentation> 
   <port name="GetEndorsingBoarderPort"
      binding="es:EndorsementSearchSoapBinding">
      <soap:address location="http://www.snowboard-info.co.uk/EndorsementSearch"/>
   </port>
</service>

请注意不同的服务名称和地址。现在，对于通过各种服务发现方法来发现此 WSDL 文档的所有用户，都有在哪里执行实际请求的两种选择。

有一些关于我们的 WSDL 示例的一般性评论。您可以看到，WSDL 将大部分注意力放在了 XML 命名空间上。在 <definition> 元素的 targetNameSpace 属性中给出的 XML 命名空间，在默认情况下，会附加到所有用于其他顶层 WSDL 元素的名称上。通过使用来自相应范围内的特殊命名空间声明的前缀，开发人员就可以使用合格的名称来引用这些元素。请注意，在 WSDL 属性中，默认的命名空间并不适用于无前缀的名称。其他地方也是如此（为了在 XML 规范的字符数据中使用没有歧义的名称，借用了 XML 命名空间机制）。还可以使用 XML 命名空间将 WSDL 元素（来自绑定扩展的元素）连接到 <types> 元素中所提供的数据类型。在我们的示例中，我们使用了默认命名空间（http://schemas.xmlsoap.org/wsdl/）来表示 WSDL 的官方元素。但是，当在其他命名空间中使用元素时，该规范显然为扩展核心元素的选择保留了很大的空间。

总体来说，本示例非常简单。它描述了由短 SOAP 传输组成的通信，每一个操作中都有两个输入字符串和一个输出。WSDL 可以很方便地定义由使用了整个 XML 架构的无数消息组成的多个端口类型。然后，至少在短期内，在 XML 服务提供商与用户之间进行简单通信很有可能获得成功。

回页首

总结以及下一个主题

WSDL 在其领域内表现出色。虽然它看起来似乎不是很不起眼，但它却是基于 XML 的业务的重要组成部分。如果不可考虑使用它的那些公司的所取得的成就以及出现的政治动态，WSDL 非常简单。IBM、Microsoft 和 Ariba 提供了一个很好的示例，展示了在构建规范时，如何以正确方式在多个供应商之间完成工作。

WSDL 通过深思熟虑，借鉴了其他人的一些经验来避免重复的工作。它通过 XML 命名空间提供强大的可扩展性，并提供了许多工具来提高描述复杂服务的有用性。总之，尽管人们一直对突然发布的各种 “1.0” 版规范持有怀疑态度，但这似乎有点吹毛求疵。

WSDL 一直未提及的一件事就是它与 RDF 集成所带来的潜力。因为 W3C 常提及的 “语义 Web” 得到了扩展，所以联机服务说明可以从所有必须以评价和信任的网络形式提供的 RDF 中受益。在下一篇有关 WSDL 的文章中，我将探索如何与 WSDL 一起使用 RDF。

参考资料

学习

查看由 Allaire 提供的 Web 分布式数据 eXchange（Web Distributed Data eXchange，WDDX）；它会为基于 XML 消息的通信提供简单的协议。
熟悉信息内容交换（Information Content Exchange，ICE），ICE 适用于分布式内容说明的协议。
RDF 站点摘要（RDF Site Summary，RSS）为描述联机资源中的内容提供了非常简单的规范。
阅读 W3C 简单对象访问协议（Simple Object Access Protocol，SOAP）1.1。
转到 XML 协议建议的 WC3 汇编
访问 XML 协议工作组的主页：XML 协议活动。
阅读完整的 Web 界面定义语言（Web Interface Definition Language，WIDL）文档。
查看 WSDL 规范。
访问通用说明、发现和集成（Universal Description, Discovery and Integration，UDDI）站点，全面了解该项目。
了解有关用于 Web 服务发现（Discovery of Web Services，DISCO）的信息。

获得产品和技术

下载 PDF 文档，其中指定了 IBM 的网络访问服务规范语言（ Network Accessible Service Specification Language，NASSL）。
来自 alphaWorks 的Web 服务工具包软件包实现了服务的广告和发现（Advertisement and Discovery of Services，ADS）。

讨论