什么是 WSDL？

WSDL（网络服务描述语言，Web Services Description Language）是一门基于 XML 的语言，用于描述 Web Services 以及如何对它们进行访问。

WSDL，被称作网络服务描述语言，是一门基于 XML 的语言，用于描述 Web Services ，以及如何对其进行访问

 

WSDL 使用 XML 编写
	
WSDL 是一种 XML 文档
	
WSDL 用于描述网络服务
	
WSDL 也可用于定位网络服务
	
WSDL 还不是 W3C 标准
。

2001年，微软提交了WSDL 1.1 草案。2002年，w3c发布了WSDL 1.2 工作草案。

WSDL具体用于什么地方呢?你可以写一套WSDL文档，向别人介绍你的 web service 有什么功能，以及它的各项函数、参数和返回值。因为WSDL是基于XML之上的，因此不仅仅是人可以阅读参考，机器也是可以阅读的。而一些最新的开发工具已经能够根据你的 web service 生成 WSDL 文档，还能导入 WSDL 文档，生成调用相应 web service 的代码。

 

WSDL 元素介绍

Types - 数据类型定义的容器，它使用某种类型系统(一般地使用XML Schema中的类型系统)。

Message - 通信消息的数据结构的抽象类型化定义。使用Types所定义的类型来定义整个消息的数据结构。

Operation - 对服务中所支持的操作的抽象描述，一般单个Operation描述了一个访问入口的请求/响应消息对。

PortType - 对于某个访问入口点类型所支持的操作的抽象集合，这些操作可以由一个或多个服务访问点来支持。

Binding - 特定端口类型的具体协议和数据格式规范的绑定。

Port - 定义为协议/数据格式绑定与具体Web访问地址组合的单个服务访问点。

Service - 相关服务访问点的集合。

WSDL 元素介绍

Types - 数据类型定义的容器，它使用某种类型系统(一般地使用XML Schema中的类型系统)。

Message - 通信消息的数据结构的抽象类型化定义。使用Types所定义的类型来定义整个消息的数据结构。

Operation - 对服务中所支持的操作的抽象描述，一般单个Operation描述了一个访问入口的请求/响应消息对。

PortType - 对于某个访问入口点类型所支持的操作的抽象集合，这些操作可以由一个或多个服务访问点来支持。

Binding - 特定端口类型的具体协议和数据格式规范的绑定。

Port - 定义为协议/数据格式绑定与具体Web访问地址组合的单个服务访问点。

Service - 相关服务访问点的集合。

WSDL 文档结构

WSDL 文档是利用这些主要的元素来描述某个 web service 的：

元素
			
定义
		
<portType>
			
web service 执行的操作
		
<message>
			
web service 使用的消息
		
<types>
			
web service 使用的数据类型
		
<binding>
			
web service 使用的通信协议
		
一个 WSDL 文档的主要结构是类似这样的：

<definitions>


<types>

  data type definitions........

</types>


<message>

  definition of the data being communicated....

</message>


<portType>

  set of operations......

</portType>


<binding>

  protocol and data format specification....

</binding>


</definitions>

WSDL 文档可包含其它的元素，比如 extension 元素，以及一个 service 元素，此元素可把若干个 web services 的定义组合在一个单一的 WSDL 文档中。

WSDL 端口

<portType> 元素是最重要的 WSDL 元素。

 

它可描述一个 web service、可被执行的操作，以及相关的消息。

 

可以把 <portType> 元素比作传统编程语言中的一个函数库（或一个模块、或一个类）。

 

WSDL 消息

<message> 元素定义一个操作的数据元素。

 

每个消息均由一个或多个部件组成。可以把这些部件比作传统编程语言中一个函数调用的参数。

 

WSDL types

<types> 元素定义 web service 使用的数据类型。

 

为了最大程度的平台中立性，WSDL 使用 XML Schema 语法来定义数据类型。

 

WSDL Bindings

<binding> 元素为每个端口定义消息格式和协议细节。

 

WSDL 实例

这是某个 WSDL 文档的简化的片段：

 

<message name="getTermRequest">

  <part name="term" type="xs:string"/>

</message>


<message name="getTermResponse">

  <part name="value" type="xs:string"/>

</message>


<portType name="glossaryTerms">

  <operation name="getTerm">

    <input message="getTermRequest"/>

    <output message="getTermResponse"/>

  </operation>

</portType>

在这个例子中，<portType> 元素把 "glossaryTerms" 定义为某个端口的名称，把 "getTerm" 定义为某个操作的名称。

操作 "getTerm" 拥有一个名为 "getTermRequest" 的输入消息，以及一个名为 "getTermResponse" 的输出消息。

<message> 元素可定义每个消息的部件，以及相关联的数据类型。

对比传统的编程，glossaryTerms 是一个函数库，而 "getTerm" 是带有输入参数 "getTermRequest" 和返回参数 getTermResponse 的一个函数。

 

WSDL 端口

<portType> 元素是最重要的 WSDL 元素。

它可描述一个 web service、可被执行的操作，以及相关的消息。

可以把 <portType> 元素比作传统编程语言中的一个函数库（或一个模块、或一个类）。

操作类型

请求-响应是最普通的操作类型，不过 WSDL 定义了四种类型：

类型
			
定义
		
One-way
			
此操作可接受消息，但不会返回响应。
		
Request-response
			
此操作可接受一个请求并会返回一个响应
		
Solicit-response
			
此操作可发送一个请求，并会等待一个响应。
		
Notification
			
此操作可发送一条消息，但不会等待响应。
		
 

One-Way 操作

一个 one-way 操作的例子：

<message name="newTermValues">

  <part name="term" type="xs:string"/>

  <part name="value" type="xs:string"/>

</message>


<portType name="glossaryTerms">

  <operation name="setTerm">

    <input name="newTerm" message="newTermValues"/>

  </operation>

</portType >

在这个例子中，端口 "glossaryTerms" 定义了一个名为 "setTerm" 的 one-way 操作。

这个 "setTerm" 操作可接受新术语表项目消息的输入，这些消息使用一条名为 "newTermValues" 的消息，此消息带有输入参数 "term" 和 "value"。不过，没有为这个操作定义任何输出。

Request-Response 操作

一个 request-response 操作的例子：

<message name="getTermRequest">

  <part name="term" type="xs:string"/>

</message>


<message name="getTermResponse">

  <part name="value" type="xs:string"/>

</message>


<portType name="glossaryTerms">

  <operation name="getTerm">

    <input message="getTermRequest"/>

    <output message="getTermResponse"/>

  </operation>

</portType>

在这个例子中，端口 "glossaryTerms" 定义了一个名为 "getTerm" 的 request-response 操作。

"getTerm" 操作会请求一个名为 "getTermRequest" 的输入消息，此消息带有一个名为 "term" 的参数，并将返回一个名为 "getTermResponse" 的输出消息，此消息带有一个名为 "value" 的参数。

以上就是关于 WSDL 端口的全部介绍。

WSDL 绑定

WSDL 绑定可为 web service 定义消息格式和协议细节。

绑定到 SOAP

一个 请求 - 响应 操作的例子：

<message name="getTermRequest">

  <part name="term" type="xs:string"/>

</message>


<message name="getTermResponse">

  <part name="value" type="xs:string"/>

</message>


<portType name="glossaryTerms">

  <operation name="getTerm">

    <input message="getTermRequest"/>

    <output message="getTermResponse"/>

  </operation>

</portType>


<binding type="glossaryTerms" name="b1">

   <soap:binding style="document"

   transport="http://schemas.xmlsoap.org/soap/http" />

   <operation>

     <soap:operation soapAction="http://example.com/getTerm"/>

     <input><soap:body use="literal"/></input>

     <output><soap:body use="literal"/></output>

  </operation>

</binding>

binding 元素有两个属性 - name 属性和 type 属性。

name 属性定义 binding 的名称，而 type 属性指向用于 binding 的端口，在这个例子中是 "glossaryTerms" 端口。

soap:binding 元素有两个属性 - style 属性和 transport 属性。

style 属性可取值 "rpc" 或 "document"。在这个例子中我们使用 document。transport 属性定义了要使用的 SOAP 协议。在这个例子中我们使用 HTTP。

operation 元素定义了每个端口提供的操作符。

对于每个操作，相应的 SOAP 行为都需要被定义。同时您必须如何对输入和输出进行编码。在这个例子中我们使用了 "literal"。

WSDL UDDI

UDDI 是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。

UDDI，英文为 "Universal Description, Discovery and Integration"，可译为"通用描述、发现与集成服务"。

什么是 UDDI？

UDDI 是一个独立于平台的框架，用于通过使用 Internet 来描述服务，发现企业，并对企业服务进行集成。

UDDI 指的是通用描述、发现与集成服务
	
UDDI 是一种用于存储有关 web services 的信息的目录。
	
UDDI 是一种由 WSDL 描述的 web services 界面的目录。
	
UDDI 经由 SOAP 进行通信
	
UDDI 被构建入了微软的 .NET 平台
UDDI 基于什么？

UDDI 使用 W3C 和 IETF* 的因特网标准，比如 XML、HTTP 和 DNS 协议。

UDDI 使用 WSDL 来描述到达 web services 的界面

此外，通过采用 SOAP，还可以实现跨平台的编程特性，大家知道，SOAP 是 XML 的协议通信规范，可在 W3C 的网站找到相关的信息。

*注释：IETF - Internet Engineering Task Force

UDDI 的好处

任何规模的行业或企业都能得益于 UDDI。

在 UDDI 之前，还不存在一种 Internet 标准，可以供企业为它们的企业和伙伴提供有关其产品和服务的信息。也不存在一种方法，来集成到彼此的系统和进程中。

UDDI 规范帮助我们解决的问题：

使得在成百万当前在线的企业中发现正确的企业成为可能
	
定义一旦首选的企业被发现后如何启动商业
	
扩展新客户并增加对目前客户的访问
	
扩展销售并延伸市场范围
	
满足用户驱动的需要，为在全球 Internet 经济中快速合作的促进来清除障碍
UDDI 如何被使用

假如行业发布了一个用于航班比率检测和预订的 UDDI 标准，航空公司就可以把它们的服务注册到一个 UDDI 目录中。然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。当此界面被找到后，旅行社就能够立即与此服务进行通信，这样由于它使用了一套定义良好的预订界面。

谁在支持 UDDI？

UDDI 是一个跨行业的研究项目，由所有主要的平台和软件提供商驱动，比如：Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, 以及 Sun, 它既是一个市场经营者的团体，也是一个电子商务的领导者。

已有数百家公司参与了这个 UDDI 团体。

WSDL 语法

描述于 W3C 工作草案的完整 WSDL 1.2 语法已列在下面：

 


<wsdl:definitions name="nmtoken"? targetNamespace="uri">

    <import namespace="uri" location="uri"/> 

    <wsdl:documentation .... /> ?

    <wsdl:types> ?
        <wsdl:documentation .... /> ?
        <xsd:schema .... /> 
    </wsdl:types>

    <wsdl:message name="ncname"> 
        <wsdl:documentation .... /> ?
        <part name="ncname" element="qname"? type="qname"?/> 
    </wsdl:message>

    <wsdl:portType name="ncname"> 
        <wsdl:documentation .... /> ?
        <wsdl:operation name="ncname"> 
            <wsdl:documentation .... /> ?
            <wsdl:input message="qname"> ?
                <wsdl:documentation .... /> ?
            </wsdl:input>
            <wsdl:output message="qname"> ?
                <wsdl:documentation .... /> ?
            </wsdl:output>
            <wsdl:fault name="ncname" message="qname"> 
                <wsdl:documentation .... /> ?
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:portType>

    <wsdl:serviceType name="ncname"> 
        <wsdl:portType name="qname"/> +
    </wsdl:serviceType>

    <wsdl:binding name="ncname" type="qname"> 
        <wsdl:documentation .... /> ?
        <-- binding details --> 
        <wsdl:operation name="ncname"> 
            <wsdl:documentation .... /> ?
            <-- binding details --> 
            <wsdl:input> ?
                <wsdl:documentation .... /> ?
                <-- binding details -->
            </wsdl:input>
            <wsdl:output> ?
                <wsdl:documentation .... /> ?
                <-- binding details --> 
            </wsdl:output>
            <wsdl:fault name="ncname"> 
                <wsdl:documentation .... /> ?
                <-- binding details --> 
            </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>

    <wsdl:service name="ncname" serviceType="qname"> 
        <wsdl:documentation .... /> ?
        <wsdl:port name="ncname" binding="qname"> *
            <wsdl:documentation .... /> ?
            <-- address details -->
        </wsdl:port>
    </wsdl:service>

</wsdl:definitions>

 

啥是wsdl？到现在也不知道。java项目里的wsdl怎么用？也不知道。总之就是能通过下面的地址获取到一个xml格式的list。

遇到的问题？通过http://域名/wsdl所在的目录？wsdl的时候，报404.

解决思路：一顿google，统一的说法是端口不正确，没当回事是最大的错误。绕了一圈。

正确思路：首先到部署app所在的tomcat下，使用上面的地址直接wget一下，看是否能拉到那个xml，当地址后面没有那个？wsdl的时候，拉到的会是Perhaps there will be a form for invoking the service here 还有一句话：hello ，this is……。重点来了，地址和端口使用localhost:8080，端口使用你设置的端口。如果拉的结果也报404，说明在application就设置了错误的端口。排查一下。具体是在哪里设置的这个端口呢？我也不知道，等待后续看到了再说。

 

如果上面的拉取是正确的接下来就要查看在各层转发中是否正确，比如loadbalabcer，如果是在k8s内，具体查看一下service的配置，ingress的配置。在ingress内查看有几个地址，一般会有多个。一个是给http的，一个是给api的，一个是给ssl的。

本次定位到的是就是前辈用错了地址，害我找了一大通，也怪自己太菜。mark一下。

 

总结：技术终归是死的，解决问题的思路非常重要，即使是白痴，思路对了就能快速解决或者虽然慢但是一定能解决。

 

   

WSDL 可描述网络服务（Web Services）
WSDL 指网络服务描述语言 (Web Services Description Language)。
WSDL 是一种使用 XML 编写的文档。这种文档可描述某个 Web service。它可规定服务的位置，以及此服务提供的操作（或方法）。


在 W3C 的 WSDL 发展史
在 2001 年 3 月，WSDL 1.1 被 IBM、微软作为一个 W3C 纪录（W3C note）提交到有关 XML 协议的 W3C XML 活动，用于描述网络服务。
（W3C 纪录仅供讨论。一项 W3C 纪录的发布并不代表它已被 W3C 或 W3C 团队亦或任何 W3C 成员认可。）
在 2002 年 7 月，W3C 发布了第一个 WSDL 1.2 工作草案。
请在我们的 W3C 教程 阅读更多有关规范的状态及时间线。

WSDL 文档仅仅是一个简单的 XML 文档。
它包含一系列描述某个 web service 的定义。


WSDL 文档结构
WSDL 文档是利用这些主要的元素来描述某个 web service 的：
元素
            
定义
        
<portType>
            
web service 执行的操作
        
<message>
            
web service 使用的消息
        
<types>
            
web service 使用的数据类型
        
<binding>
            
web service 使用的通信协议
        
一个 WSDL 文档的主要结构是类似这样的：

WSDL 文档可包含其它的元素，比如 extension 元素，以及一个 service 元素，此元素可把若干个 web services 的定义组合在一个单一的 WSDL 文档中。
如需完整的语法概述，请访问 WSDL 语法 这一节。


WSDL 端口
<portType> 元素是最重要的 WSDL 元素。 

它可描述一个 web service、可被执行的操作，以及相关的消息。 

可以把 <portType> 元素比作传统编程语言中的一个函数库（或一个模块、或一个类）。 



WSDL 消息
<message> 元素定义一个操作的数据元素。 

每个消息均由一个或多个部件组成。可以把这些部件比作传统编程语言中一个函数调用的参数。 



WSDL types
<types> 元素定义 web service 使用的数据类型。 

为了最大程度的平台中立性，WSDL 使用 XML Schema 语法来定义数据类型。 



WSDL Bindings
<binding> 元素为每个端口定义消息格式和协议细节。 



WSDL 实例
这是某个 WSDL 文档的简化的片段： 


在这个例子中，<portType> 元素把 "glossaryTerms" 定义为某个端口的名称，把 "getTerm" 定义为某个操作的名称。
操作 "getTerm" 拥有一个名为 "getTermRequest" 的输入消息，以及一个名为 "getTermResponse" 的输出消息。
<message> 元素可定义每个消息的部件，以及相关联的数据类型。
对比传统的编程，glossaryTerms 是一个函数库，而 "getTerm" 是带有输入参数 "getTermRequest" 和返回参数 getTermResponse 的一个函数。
 

WSDL 端口可描述由某个 web service 提供的界面（合法操作）。


WSDL 端口
<portType> 元素是最重要的 WSDL 元素。
它可描述一个 web service、可被执行的操作，以及相关的消息。
端口定义了指向某个 web service 的连接点。可以把它元素比作传统编程语言中的一个函数库（或一个模块、或一个类），而把每个操作比作传统编程语言中的一个函数。


操作类型
请求-响应是最普通的操作类型，不过 WSDL 定义了四种类型：
类型
            
定义
        
One-way
            
此操作可接受消息，但不会返回响应。
        
Request-response
            
此操走可接受一个请求并会返回一个响应
        
Solicit-response
            
此操作可发送一个请求，并会等待一个响应。
        
Notification
            
此操作可发送一条消息，但不会等待响应。
        

One-Way 操作
一个 one-way 操作的例子：

在这个例子中，端口 "glossaryTerms" 定义了一个名为 "setTerm" 的 one-way 操作。
这个 "setTerm" 操作可接受新术语表项目消息的输入，这些消息使用一条名为 "newTermValues" 的消息，此消息带有输入参数 "term" 和 "value"。不过，没有为这个操作定义任何输出。


Request-Response 操作
一个 request-response 操作的例子：

在这个例子中，端口 "glossaryTerms" 定义了一个名为 "getTerm" 的 request-response 操作。
"getTerm" 操作会请求一个名为 "getTermRequest" 的输入消息，此消息带有一个名为 "term" 的参数，并将返回一个名为 "getTermResponse" 的输出消
绑定到 SOAP
一个 请求 - 响应 操作的例子：

binding 元素有两个属性 - name 属性和 type 属性。
name 属性定义 binding 的名称，而 type 属性指向用于 binding 的端口，在这个例子中是 "glossaryTerms" 端口。
soap:binding 元素有两个属性 - style 属性和 transport 属性。
style 属性可取值 "rpc" 或 "document"。在这个例子中我们使用 document。transport 属性定义了要使用的 SOAP 协议。在这个例子中我们使用 HTTP。
operation 元素定义了每个端口提供的操作符。
对于每个操作，相应的 SOAP 行为都需要被定义。同时您必须如何对输入和输出进行编码。在这个例子中我们使用了 "literal"。

UDDI 是一种目录服务，企业可以使用它对 Web services 进行注册和搜索。
UDDI，英文为 "Universal Description, Discovery and Integration"，可译为“通用描述、发现与集成服务”。


什么是 UDDI？
UDDI 是一个独立于平台的框架，用于通过使用 Internet 来描述服务，发现企业，并对企业服务进行集成。
UDDI 指的是通用描述、发现与集成服务 
    
UDDI 是一种用于存储有关 web services 的信息的目录。 
    
UDDI 是一种由 WSDL 描述的 web services 界面的目录。 
    
UDDI 经由 SOAP 进行通信 
    
UDDI 被构建入了微软的 .NET 平台 


UDDI 基于什么？
UDDI 使用 W3C 和 IETF* 的因特网标准，比如 XML、HTTP 和 DNS 协议。
UDDI 使用 WSDL 来描述到达 web services 的界面
此外，通过采用 SOAP，还可以实现跨平台的编程特性，大家知道，SOAP 是 XML 的协议通信规范，可在 W3C 的网站找到相关的信息。
*注释：IETF - Internet Engineering Task Force


UDDI 的好处
任何规模的行业或企业都能得益于 UDDI。
在 UDDI 之前，还不存在一种 Internet 标准，可以供企业为它们的企业和伙伴提供有关其产品和服务的信息。也不存在一种方法，来集成到彼此的系统和进程中。
UDDI 规范帮助我们解决的问题：
使得在成百万当前在线的企业中发现正确的企业成为可能 
    
定义一旦首选的企业被发现后如何启动商业 
    
扩展新客户并增加对目前客户的访问 
    
扩展销售并延伸市场范围 
    
满足用户驱动的需要，为在全球 Internet 经济中快速合作的促进来清除障碍 


UDDI 如何被使用
假如行业发布了一个用于航班比率检测和预订的 UDDI 标准，航空公司就可以把它们的服务注册到一个 UDDI 目录中。然后旅行社就能够搜索这个 UDDI 目录以找到航空公司预订界面。当此界面被找到后，旅行社就能够立即与此服务进行通信，这样由于它使用了一套定义良好的预订界面。


谁在支持 UDDI？
UDDI 是一个跨行业的研究项目，由所有主要的平台和软件提供商驱动，比如：Dell, Fujitsu, HP, Hitachi, IBM, Intel, Microsoft, Oracle, SAP, 以及 Sun, 它既是一个市场经营者的团体，也是一个电子商务的领导者。
已有数百家公司参与了这个 UDDI 团体。
述于 W3C 工作草案的完整 WSDL 1.2 语法已列在下面：

（转自）http://www.ibm.com/developerworks/cn/webservices/ws-intwsdl/part1/
在“使用 WSDL 部署 Web 服务”系列中，Bilal 将研究创建、部署和发布 Web 服务的所有主要技术方面 ― 从 Web 服务描述语言（WSDL），到简单对象访问协议（SOAP）以及通用描述、发现和集成（UDDI）注册中心。第 1 部分集中讲述了 WSDL 创建：您将学习如何手工创建 WSDL 接口，然后将您的成果与 WSDL 编写工具的输出作比较。


可互操作的基于 Web 分布式应用程序的思想并非新近出现。仅举一例，电子数据交换（EDI）市场需求早在 B2B 在线电子商务获得任何有意义的实现之前就存在了 ― 并且随着 B2B 电子市场的普及，互操作性已经成为最迫切的 EDI 需求。
以任何在线电子市场为例。存在着许多企业，各自提供特有的“服务（ services ）”（让我们称之为“Web 服务（ Web services ）”）。在当今的电子商务中，尚不存在一种机制，使一个业务能自动发现其预期伙伴提供的服务。所谓的 下一代 .com还是提供这种自动的发现机制。 
什么是 WSDL？
这种新的 .com 需要一种解决方案来描述它所提供的服务（Web 服务）。具体而言，这意味着您需要一种格式或某种类型的语法，使您可以通过使用它们来描述下列问题的答案：
您的在线业务提供什么服务？ 
您如何调用业务服务？ 
当用户调用您的业务服务时，该业务服务需要他／她提供什么信息？ 
用户将如何提供这些必需信息？ 
服务将以什么格式发送返回给用户的信息？ 
很幸运，WSDL 提供了完成所有这些作业的机制。
 
 
WSDL 和 SOAP
为更好理解 WSDL 是如何工作的，我将首先描述 SOAP 和 HTTP 是如何使用 WSDL 工作的。WSDL 的用途是“描述”您的 Web 服务。业务之间将通过交换 WSDL 文件来理解对方的服务。一旦知道您伙伴的服务并希望调用它们，SOAP 就派上用场了。可以将服务看作是通过 SOAP 访问的对象。
最有可能的情况是，您将通过因特网或电子邮件与潜在伙伴通信。当然，因特网使用 HTTP 而电子邮件以 SMTP 方式工作，这使得 HTTP 和 SMTP 成为作为 SOAP 的“传输服务提供者”的有利候选人。
 
WSDL 编写
现在，我将讲述为 Web 服务编写 WSDL 的过程。目的是公开现有的 Web 服务。您所处的情况也许就是下列情况之一：
您有一个现存的服务（例如，一个网站），并希望表示它的功能性。 
您有一个 WSDL，并且希望依照已经决定表示的功能性来实现 Web服务器端的逻辑。（有些人也许会认为这是一个不可能的方案，但是 UDDI 的指纹概念使它变得极为可能；我将在本系列的第四部分讨论 UDDI）。 
您正在从零开始，并且既无网站又无 WSDL 界面。 
本文中所涵盖的信息适用于这些可能性中的任意一种或全部。
 
WSDL 编写的四个步骤
我将把 WSDL 编写分成四个简单步骤。遵循每个步骤，您的 Web 服务将准备就绪用于部署。
步骤 1：服务接口
您将构建一个移动电话销售公司的服务接口作为样本项目（我将这个服务称为 MobilePhoneService ）。该公司销售不同型号的移动电话，所以公司 Web 服务的后端数据存储库中将包含一个具有两列（ model number 和 price ）的表格。（为了将焦点保持在 WSDL 本身，我保持该表格的简单性）。有两个关于要使用 WSDL 表示的服务的方法： 
getListOfModels () 
getPrice (modelNumber) 
GetListOfModels 方法提供了一个字符串数组，其中每个字符串表示一种移动电话的型号。 GetPrice 获得型号，然后返回它的价格。WSDL 将这些方法作为操作调用。现在将开始构建“WSDL 接口文件（ WSDL interface file ）”。 
每个 WSDL 文件的根元素都是 <definitions> ，必须在其中提供服务的完整描述。首先，必须在 <definitions> 元素中提供各种名称空间的声明。三个必须做的外部名称空间声明是 WSDL、SOAP 和 XSD（XML 模式定义）。还有一个名称空间 ― TNS，它指您的 MobilePhoneService（这表示 TNS（targetNamespace 的缩写）包含专为 MobilePhoneService 定义的所有元素和属性的名称）。但是 WSDL 是您将在 WSDL 编写中使用得最多的主要名称空间。在本系列文章中使用到其它名称空间时，我将提到它们的效用。 
关于名称空间只要注意一点：WSDL 广泛地使用名称空间这一概念。我鼓励您到 W3C 的官方网站去学习关于名称空间的更多知识（请参阅 参考资料）。WSDL 是这种思想的一种实现，因为名称空间提供了无限的灵活性，而这恰恰是用于电子数据交换的可移植格式所需要的。 
<definitions> 元素包含一个或多个 <portType> 元素，实际上，每个元素都是您希望表示的一系列 operation 。或者，您也可以将单个 portType 元素看作是将各种方法组成类的一个逻辑分组。例如，如果您的供应链管理解决方案需要在客户和供应商之间进行交互，您最可能做的是分别定义与他们交互的功能性；也就是说，您将为用户和供应商各定义一个 portType。应该将每个 portType 称为 服务，因此整个 WSDL 文件将成为一个服务集合。 
必须为每个服务提供一个名称。在本例中，仅有一个服务（因此只有一个 <portType> ）。 需要使用该 portType 元素的 name 属性为移动电话销售服务指定名称。 
在每个服务内可以有几个方法、或者 operation ，WSDL 通过 <operation> 元素来引用它们。样本应用程序有两个要表示的方法： getListOfModels 和 getPrice 。因此，您需要提供两个 <operation> 元素，每个元素有一个 name 。 我已经使用 <operation> 元素的 name 属性命名了每个操作。 
此时，WSDL 文件看上去象 清单 1。
 
步骤 2：指定参数
定义好操作（或方法）以后，现在需要指定将向它们发送和从它们返回的参数。在 WSDL 术语中，所有参数称为“消息”。认为您是在递送消息而结果得到返回的消息是有用的。方法调用是这样一种操作：它准备返回“消息”来响应进入的消息。
请回忆，在第一步骤中有两个操作要表示。第一个操作 getListOfModels 不必获得任何参数并且返回一个字符串数组，其中每个字符串表示移动电话的型号。因此，必须定义一个包含字符串数组的 <message> 元素。 
看看 清单 2 中的各种 <message> 元素。其中的第一个元素有一个等于 ListOfPhoneModels 的名称属性（该消息的逻辑名称），以及名称为 models 的单个 <part> 元素，这意味着该 ListOfPhoneModels 是一个“只含有一个 part 的”消息，其中仅有的这个 part 的名称是“models”。消息可以有任意多个 part ― 只要为它们起不同的名称，以唯一标识。 
我已包括了 <part> 元素的另一个属性，它就是 type 。将这个“type”属性当作 C++ 或 Java 中的数据类型。我已经将 models 的数据类型指定为 tns：Vector。（请回忆，我在 <definitions> 根元素中指定了一些名称空间，其中之一是 tns 。）这个类型即指 MobilePhoneService 名称空间。这意味着当编写 WSDL 时，您可以创建自己的名称空间。现在您也许会问两个逻辑问题：为什么？和怎么做？ 
要回答 为什么，让我们以 getListOfModels 操作返回的字符串数组为例。WSDL 使用 XML 模式定义（XSD）定义的一些原始数据类型（诸如 int、float、long、short、byte、string、Boolean 等等），并允许您直接使用它们，或者以这些原始数据类型构建复杂数据类型后，在消息中使用它们。这就是为什么当引用复杂数据类型时，您需要定义自己的名称空间。在本例中，需要为 array of strings 构建一个复杂数据类型。 
现在来看 怎么做问题，您将使用 XSD 创建自己的名称空间。为实现这个目的，我在 <types> 元素中使用了 xsd：complexType 元素用来定义称为 Vector 的数据类型。 Vector 使用两个原始数据类型：string（元素数据）和 Integer（元素计数）。因此， Vector 成为名称空间的一部分并可以通过别名 tns 来引用。 
在 清单 2 中，我以类似的方式定义了另外两个消息 PhoneModel 和 PhoneModelPrice 。这两个消息只使用了 xsd 名称空间中的原始数据类型 string，因此您不必为使用它们而定义任何更复杂的数据类型。 
您也许已经注意到当创建 <message> 元素时，没有指定这些消息是进入参数还是返回值。这是一个您将在 <portType> 元素内的 <operation> 元素中完成的工作。因此，正如您在 清单 2 中所看到的，我已经将 <input> 和 <output> 元素都添加到这两个操作中。每个 input 元素通过消息名来引用它并将它当作用户调用该操作时要提供的参数。类似地，每个 <output> 元素引用一个消息；它将该消息当作操作调用的返回值。 
至今， 清单 2准确地限定了目前的讨论的范围。 
步骤 3：消息传递和传输
我以一种抽象方式定义了操作和消息，而不考虑实现的细节。实际上，WSDL 的任务是定义或描述 Web 服务，然后提供一个对外部框架的引用来定义 WSDL 用户将如何实现这些服务。可以将这个框架当作 WSDL 抽象定义和它们的实现之间的“绑定（ binding ）”。 
当前，最流行的绑定（ binding ）技术是使用简单对象访问协议（SOAP）。WSDL 将指定能够访问 Web 服务实际实现的 SOAP 服务器，并且从那时起 SOAP 的整个任务就是将用户从 WSDL 文件带到它的实现。SOAP 是本系列文章中下一部分的主题，所以我将暂时避免讨论 SOAP 细节而继续集中讲述 WSDL 编写。 
WSDL 编写的第三个步骤是描述将 SOAP 与 WSDL 文件绑定到一起的过程。您将把 <binding> 元素包括到 <definitions> 元素内。这个 binding 元素应该有 name 和 type 属性。 name 将标识这个绑定而 type 将标识您希望与这个绑定相关联的 portType（一组操作）。在 清单 3 中，您会发现 <portType> 元素的 name 与 <binding> 元素的 type 属性值相匹配。 
WSDL binding 元素包含您将用于绑定用途的外部技术的声明。因为正在使用 SOAP，所以这里将使用 SOAP 的名称空间。WSDL 术语中，对外部名称空间的使用称为 extensibility 元素。 
在 清单 3 中，您将看见一个空的 <soap:binding/> 元素。该元素的用途是声明将把 SOAP 作为绑定和传输服务使用。 
<soap:binding> 元素有两个属性：style 和 transport。style 是一个可选属性，它描述该绑定内操作的性质。transport 属性指定 HTTP 作为该绑定将使用的级别较低的传输服务。 
SOAP 客户机将从 WSDL 文件中读取 SOAP 结构并与另一端的 SOAP 服务器协调，所以必须特别关注 interoperability 。我打算在本系列文章的第三部分详细讲述该问题。 
在空的 <soap:binding/> 元素后面，有两个 WSDL <operation> 元素，分别表示步骤 1 的操作。每个 <operation> 元素提供各自操作的绑定细节。因此，我提供了另一个 extensibility 元素，即 <soap:operation/> （仍然是一个空元素，与它发生的那个操作相关）。该 <soap:operation/> 元素有一个 soapAction 属性，SOAP 客户机将使用该属性创建 SOAP 请求。 
请回忆步骤 2 中， getListOfModels 操作只有输出而无任何输入。因此，必须为该操作提供一个 <output> 元素。该输出包含 <soap:body/> 元素（仍然是一个空元素，与它发生的那个操作相关）。SOAP 客户机需要该信息来创建 SOAP 请求。 <soap:body/> 的名称空间属性值应该与您将部署到 SOAP 服务器上的 service 的名称相对应，SOAP 服务器将在在本系列文章的下一部分中讲述。 
您已几乎要完成步骤 3 了。只要将下一个操作复制到这个操作的后面，您将完成 清单 3。 
步骤 4：概括
您已经生成了一个完整描述服务 interface 的 WSDL 文件。现在，WSDL 需要一个附加步骤来创建该 WSDL 文件的概要。WSDL 将该文件称为 implementation 文件，在本系列文章的第四部分中，当您在 UDDI 注册中心发布 Web 服务时，会使用它。请看 清单 4― 这个 WSDL 实现文件。它的主要特性如下： 
除了 
清单 4（实现文件）引用不同的 targetNamespace 去引用实现文件以外， <definitions> 根元素和 清单 3（WSDL 接口文件）中的完全相同。 
有一个 
<import> 元素，该元素引用 清单 3的接口文件（文件名 MobilePhoneService-interface.wsdl）和它的名称空间。 
有一个 
<service> 标记，其中有一个表示该服务的逻辑名 name 。在 service 元素内有一个引用在 清单 3中创建的 SOAP 绑定的 port 元素。