在过去的几年中，出现了一些标准协议，它们提供了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.服务角色和交互

　　示例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      SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>   <SOAP-ENV:Body>     <m:GetEndorsingBoarder >           <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      SOAP-ENV:encodingStyle=”http://schemas.xmlsoap.org/soap/encoding/”>   <SOAP-ENV:Body>     <m:GetEndorsingBoarderResponse >       <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中受益。