注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

0与1构筑世界,程序员创造时代

软件架构设计 Java编程

 
 
 

日志

 
 

WDSL详解(收藏)  

2006-06-19 08:54:58|  分类: WebService |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

为什么使用WSDL?

  像Internet协议之类的标准有没有为权威所利用,或者人们这样看待它是因为顺之所获的好处远远超出了代价?曾经有许多试图建立的标准都流产了。有时候,那些还没有普遍使用的标准甚至由法令或政府规定强行推出:Ada语言就是一例。

  我相信正是跟随标准所带来的好处使它广泛接受。例如,对于铁路服务来说,真正重要的是,不同公司所铺设的铁路结合到一起,或者是来自好几个公司的产品协调的工作在一起。几家大的企业合力建立了SOAP标准。Web Service描述语言(WSDL)向这种Web Service的提供商和用户推出了方便的协调工作的方法,使我们能更容易的获得SOAP的种种好处。几家公司的铁道并在一起不算什么难事,他们所需遵循的只是两轨间的标准距离。对Web Service来说,这要复杂得多。我们必须先制定出指定接口的标准格式。

  曾经有人说SOAP并不真需要什么接口描述语言。如果SOAP是交流纯内容的标准,那就需要一种语言来描述内容。SOAP消息确实带有某些类型信息,因此SOAP允许动态的决定类型。但不知道一个函数的函数名、参数的个数和各自类型,怎么可能去调用这个函数呢?没有WSDL,我可以从必备文档中确定调用语法,或者检查消息。随便何种方法,都必须有人参与,这个过程可能会有错。而使用了WSDL,我就可以通过这种跨平台和跨语言的方法使Web Service代理的产生自动化。就像COMCORBAIDL文件,WSDL文件由客户和服务器约定。

  注意由于WSDL设计成可以绑定除SOAP以外的其他协议,这里我们主要关注WSDLHTTP上和SOAP的关系。同样,由于SOAP目前主要用来调用远程的过程和函数,WSDL支持SOAP传输的文档规范。WSDL 1.1已经作为记录递交给W3C(见http://www.w3.org/TR/wsdl.html

  WSDL文档结构

  若要理解XML文档,将之看作块状图表非常有用。下图以XML的文档形式说明了WSDL的结构,它揭示了WSDL文档五个栏之间的关系。

  WSDL文档可以分为两部分。顶部分由抽象定义组成,而底部分则由具体描述组成。抽象部分以独立于平台和语言的方式定义SOAP消息,它们并不包含任何随机器或语言而变的元素。这就定义了一系列服务,截然不同的网站都可以实现。随网站而异的东西如序列化便归入底部分,因为它包含具体的定义。

  l 抽象定义

    Types

    独立与机器和语言的类型定义

    Messages

    包括函数参数(输入与输出分开)或文档描述

    PortTypes

    引用消息部分中消息定义来描述函数签名(操作名、输入参数、输出参数)

  2 具体定义

    Bindings

    PortTypes部分的每一操作在此绑定实现

    Services

    确定每一绑定的端口地址

  下面的图中,箭头连接符代表文档不同栏之间的关系。点和箭头代表了引用或使用关系。双箭头代表"修改"关系。3-D的箭头代表了包含关系。这样,各Messages栏使用Types栏的定义,PortTypes栏使用Messages栏的定义;Bindings栏引用了PortTypes栏,Services栏引用Bindings栏,PortTypesBindings栏包含了operation元素,而Services栏包含了port元素。PortTypes栏里的operation元素由Bindings栏里的operation元素进一步修改或描述。

  在此背景中,我将使用标准的XML术语来描述WSDL文档。Element是指XML的元素,而"attribute"指元素的属性。于是:

element attribute="attribute-value"contents/element


  内容也可能由一个或多个元素以递归的方式组成。根元素是所有元素之中最高级的元素。子元素总是从属于另一个元素,父元素。

  注意,文档之中可能只有一个Types栏,或根本没有。所有其他的栏可以只有零元素、单元素或是多元素。WSDL的列表要求所有的栏以固定的顺序出现:import, types, message, portType, binding, service。所有的抽象可以是单独存在于别的文件中,也可以从主文档中导入。

 

 

WSDL文件示例

  让我们来研究一下WSDL文件,看看它的结构,以及如何工作。请注意这是一个非常简单的WSDL文档实例。我们的意图只是说明它最显著的特征。以下的内容中包括更加详细的讨论。

?xml version="1.0" encoding="UTF-8" ?
definitions name="FooSample"
 targetNamespace="http://tempuri.org/wsdl/"
 xmlns:wsdlns="http://tempuri.org/wsdl/"
 xmlns:typens="http://tempuri.org/xsd"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:stk="http://schemas.microsoft.com/soap-toolkit/wsdl-extension"
 xmlns="http://schemas.xmlsoap.org/wsdl/"

types
schema targetNamespace="http://tempuri.org/xsd"
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
  elementFormDefault="qualified"
/schema
/types

message name="Simple.foo"
 <part name="arg" type="xsd:int"/
/message

message name="Simple.fooResponse"
 <part name="result" type="xsd:int"/
/message

portType name="SimplePortType"
 <operation name="foo" parameterOrder="arg"
  <input message="wsdlns:Simple.foo"/
  <output message="wsdlns:Simple.fooResponse"/
 </operation
/portType

binding name="SimpleBinding" type="wsdlns:SimplePortType"
 <stk:binding preferredEncoding="UTF-8" /
 <soap:binding style="rpc"
  transport="http://schemas.xmlsoap.org/soap/http"/
 <operation name="foo"
  <soap:operation soapAction="http://tempuri.org/action/Simple.foo"/
  <input
   <soap:body use="encoded" namespace="http://tempuri.org/message/"
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /
  </input
  <output
   <soap:body use="encoded" namespace="http://tempuri.org/message/"
    encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /
  </output
 </operation
/binding

service name="FOOSAMPLEService"
 <port name="SimplePort" binding="wsdlns:SimpleBinding"
  <soap:address location="http://carlos:8080/FooSample/FooSample.asp"/
 </port
/service
/definitions


  以下是该实例文档的总述:稍后我将详细讨论每一部分的细节。

  第一行申明该文档是XML。尽管这并不是必需的,但它有助于XML解析器决定是否解析WSDL文件或只是报错。第二行是WSDL文档的根元素:<definitions>。一些属性附属于根元素,就像<schema>子元素对于<types>元素。

  <types>元素包含了Types栏。如果没有需要声明的数据类型,这栏可以缺省。在WSDL范例中,没有应用程序特定的types声明,但我仍然使用了Types栏,只是为了声明schema namespaces

  <message>元素包含了Messages栏。如果我们把操作看作函数,<message>元素定义了那个函数的参数。<message>元素中的每个<part>子元素都和某个参数相符。输入参数在<message>元素中定义,与输出参数相隔离--输出参数有自己的<message>元素。兼作输入、输出的参数在输入输出的<message>元素中有它们相应的<part>元素。输出<message>元素以"Response"结尾,就像以前所用的"fooResponse"。每个<part>元素都有名字和类型属性,就像函数的参数有参数名和参数类型。

  用于交换文档时,WSDL允许使用<message>元素来描述交换的文档。

  <part>元素的类型可以是XSD基类型,也可以是SOAP定义类型(soapenc)WSDL定义类型(wsdl)或是Types栏定义的类型。

  一个PortTypes栏中,可以有零个、单个或多个<portType>元素。由于抽象PortType定义可以放置在分开的文件中,在某个WSDL文件中没有<portType>元素是可能的。上面的例子里只是用了一个<portType>元素。而一个<portType>元素可在<operation>元素中定义一个或是多个操作。示例仅使用了一个名为"foo"的<operation>元素。这和某个函数名相同。<operation>元素可以有一个、两个、三个子元素:<input, output> 和<fault>元素。每个<input>和<output>元素中的消息都引用Message栏中的相关的<message>元素。这样,示例中的整个<portType>元素就和以下的C函数等效:

 

 int foo(int arg);


  这个例子足见XMLC相比要冗长的多。(包括<message>元素,XML在示例中共使用了12行代码来表达相同的单行函数声明。)

  Bindings栏可以有零个、一个或者多个<binding>元素。它的意图是制定每个<operation>通过网络调用和回应。Services栏同样可以有零个、一个、多个<service>元素。它还包含了<port>元素,每个<port>元素引用一个Bindings栏里的<binding>元素。BindingsServices栏都包含WSDL文档。

 

 

 

Namespace

  <definitions>和子节点<schema>都是namespace属性:

definitions name="FooSample"
 targetNamespace="http://tempuri.org/wsdl/"
 xmlns:wsdlns="http://tempuri.org/wsdl/"
 xmlns:typens="http://tempuri.org/xsd"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 xmlns:stk="http://schemas.microsoft.com/soap-toolkit/wsdl-extension"
 xmlns="http://schemas.xmlsoap.org/wsdl/"

types
 <schema targetNamespace="http://tempuri.org/xsd"
  xmlns="http://www.w3.org/2001/XMLSchema"
  xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/"
  xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/"
  elementFormDefault="qualified"
 </schema
/types


  每个namespace属性都声明了一个缩略语,用在文档中。例如"xmlns:xsd"就为 http://www.w3.org/2001/XMLSchema定义了一个缩略语(xsd)。这就允许对该namespace的引用只需简单的在名字前加上前缀就可以了,如:"xsd:int"中的"xsd"就是合法的类型名。普通范围规则可运用于缩略前缀。也就是说,前缀所定义的元素只在元素中有效。

  Namespace派什么用?namespace的作用是要避免命名冲突。如果我建立一项Web Service,其中的WSDL文件包含一个名为"foo"的元素,而你想要使用我的服务与另一项服务连接作为补充,这样的话另一项服务的WSDL文件就不能包含名为"foo"的元素。两个服务器程序只有在它们在两个事例中表示完全相同的东西时,才可以取相同的名字。如果有了表示区别的namespace,我的网络服务里的"foo"就可以表示完全不同于另一个网络服务里"foo"的含义。在你的客户端里,你只要加以限制就可以引用我的"foo"

  见下例:http://www.infotects.com/fooService#foo 就是完全限制的名字,相当于"carlos:foo",如果我声明了carlos作为http://www.infotects.com/fooService的快捷方式。请注意namespace中的URL是用来确定它们的唯一性的,同时也便于定位。URL所指向的地方不必是实际存在的网络地址,也可以使用GUID来代替或补充URL。例如,GUID"335DB901-D44A-11D4-A96E-0080AD76435D"就是一个合法的namespace指派。

  targetNamespace属性声明了一个namespace,元素中所有的声明的名字都列于其内。在WSDL示例中,<definitions>的targetNamespace http://tempuri.org/wsdl。这意味着所有在WSDL文档中声明的名字都属于这个namespace。<schema>元素有自己的targetNamespace

  评论这张
 
阅读(1271)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017