WSDL 文档

为什么使用WSDL?像Internet协议之类的标准有没有为权威所利用，或者人们这样看待它是因为顺之所获的好处远远超出了代价？曾经有许多试图建立的标准都流产了。有时候，那些还没有普遍使用的标准甚至由法令或政府规定强行推出：Ada语言就是一例。我相信正是跟随标准所带来的好处使它广泛接受。例如，对于铁路服务来说，真正重要的是，不同公司所铺设的铁路结合到一起，或者是来自好几个公司的产品协调的工作在一起。几家大的企业合力建立了SOAP标准。WebService描述语言(WSDL)向这种WebService的提供商和用户推出了方便的协调工作的方法，使我们能更容易的获得SOAP的种种好处。几家公司的铁道并在一起不算什么难事，他们所需遵循的只是两轨间的标准距离。对WebService来说，这要复杂得多。我们必须先制定出指定接口的标准格式。曾经有人说SOAP并不真需要什么接口描述语言。如果SOAP是交流纯内容的标准，那就需要一种语言来描述内容。SOAP消息确实带有某些类型信息，因此SOAP允许动态的决定类型。但不知道一个函数的函数名、参数的个数和各自类型，怎么可能去调用这个函数呢？没有WSDL，我可以从必备文档中确定调用语法，或者检查消息。随便何种方法，都必须有人参与，这个过程可能会有错。而使用了WSDL，我就可以通过这种跨平台和跨语言的方法使WebService代理的产生自动化。就像COM和CORBA的IDL文件，WSDL文件由客户和服务器约定。注意由于WSDL设计成可以绑定除SOAP以外的其他协议，这里我们主要关注WSDL在HTTP上和SOAP的关系。同样，由于SOAP目前主要用来调用远程的过程和函数，WSDL支持SOAP传输的文档规范。WSDL1.1已经作为记录递交给W3C（见）WSDL文档结构若要理解XML文档，将之看作块状图表非常有用。下图以XML的文档形式说明了WSDL的结构，它揭示了WSDL文档五个栏之间的关系。WSDL文档可以分为两部分。顶部分由抽象定义组成，而底部分则由具体描述组成。抽象部分以独立于平台和语言的方式定义SOAP消息，它们并不包含任何随机器或语言而变的元素。这就定义了一系列服务，截然不同的网站都可以实现。随网站而异的东西如序列化便归入底部分，因为它包含具体的定义。l抽象定义Types独立与机器和语言的类型定义Messages包括函数参数（输入与输出分开）或文档描述PortTypes引用消息部分中消息定义来描述函数签名（操作名、输入参数、输出参数）2具体定义BindingsPortTypes部分的每一操作在此绑定实现Services确定每一绑定的端口地址下面的图中，箭头连接符代表文档不同栏之间的关系。点和箭头代表了引用或使用关系。双箭头代表修改关系。3-D的箭头代表了包含关系。这样，各Messages栏使用Types栏的定义，PortTypes栏使用Messages栏的定义；Bindings栏引用了PortTypes栏，Services栏引用Bindings栏，PortTypes和Bindings栏包含了operation元素，而Services栏包含了port元素。PortTypes栏里的operation元素由Bindings栏里的operation元素进一步修改或描述。在此背景中，我将使用标准的XML术语来描述WSDL文档。Element是指XML的元素，而attribute指元素的属性。于是：＜elementattribute=attribute-value＞contents＜/element＞内容也可能由一个或多个元素以递归的方式组成。根元素是所有元素之中最高级的元素。子元素总是从属于另一个元素，父元素。注意，文档之中可能只有一个Types栏，或根本没有。所有其他的栏可以只有零元素、单元素或是多元素。WSDL的列表要求所有的栏以固定的顺序出现：import,types,message,portType,binding,service。所有的抽象可以是单独存在于别的文件中，也可以从主文档中导入。图一：抽象定义和具体定义WSDL文件示例让我们来研究一下WSDL文件，看看它的结构，以及如何工作。请注意这是一个非常简单的WSDL文档实例。我们的意图只是说明它最显著的特征。以下的内容中包括更加详细的讨论。＜?xmlversion=1.0encoding=UTF-8?＞＜definitionsname=FooSampletargetNamespace=:wsdlns=:typens=:xsd=:soap=:stk==＞＜types＞＜schematargetNamespace==:SOAP-ENC=:wsdl==qualified＞＜/schema＞＜/types＞＜messagename=Simple.foo＞＜partname=argtype=xsd:int/＞＜/message＞＜messagename=Simple.fooResponse＞＜partname=resulttype=xsd:int/＞＜/message＞＜portTypename=SimplePortType＞＜operationname=fooparameterOrder=arg＞＜inputmessage=wsdlns:Simple.foo/＞＜outputmessage=wsdlns:Simple.fooResponse/＞＜/operation＞＜/portType＞＜bindingname=SimpleBindingtype=wsdlns:SimplePortType＞＜stk:bindingpreferredEncoding=UTF-8/＞＜soap:bindingstyle=rpctransport=＞＜operationname=foo＞＜soap:operationsoapAction=＞＜input＞＜soap:bodyuse=encodednamespace==＞＜/input＞＜output＞＜soap:bodyuse=encodednamespace==＞＜/output＞＜/operation＞＜/binding＞＜servicename=FOOSAMPLEService＞＜portname=SimplePortbinding=wsdlns:SimpleBinding＞＜soap:addresslocation=＞＜/port＞＜/service＞＜/definitions＞以下是该实例文档的总述：稍后我将详细讨论每一部分的细节。第一行申明该文档是XML。尽管这并不是必需的，但它有助于XML解析器决定是否解析WSDL文件或只是报错。第二行是WSDL文档的根元素：＜definitions＞。一些属性附属于根元素，就像＜schema＞子元素对于＜types＞元素。＜types＞元素包含了Types栏。如果没有需要声明的数据类型，这栏可以缺省。在WSDL范例中，没有应用程序特定的types声明，但我仍然使用了Types栏，只是为了声明schemanamespaces。＜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函数等效：intfoo(intarg);这个例子足见XML和C相比要冗长的多。（包括＜message＞元素，XML在示例中共使用了12行代码来表达相同的单行函数声明。）Bindings栏可以有零个、一个或者多个＜binding＞元素。它的意图是制定每个＜operation＞通过网络调用和回应。Services栏同样可以有零个、一个、多个＜service＞元素。它还包含了＜port＞元素，每个＜port＞元素引用一个Bindings栏里的＜binding＞元素。Bindings和Services栏都包含WSDL文档。Namespace＜definitions＞和子节点＜schema＞都是namespace属性：＜definitionsname=FooSampletargetNamespace=:wsdlns=:typens=:xsd=:soap=:stk=