[WCF]从WCF生成的WSDL学习笔记（一）
使用WCF发布的Web服务可以被各种技术平台远程调用，关键就是WCF发布了符合业界标准的WSDL（Web Service Description Language），各种技术平时使用各自的工具将这种WSDL解释成自身所能接受的编程对象，让后对其进行服务调用。本系列文章旨在学习控制WCF生成WSDL。
为了实验之用，我首先写了一个很简单的WCF应用程序，同样由契约类库、服务实现类库、服务宿主程序、客户端程序组成。（项目文件在下载区，文章中只贴出关键代码）
以下是服务契约的定义：
代码
{
[ServiceContract]
public interface IContract
{
[OperationContract]
void NoArgsOperation();
[OperationContract]
void OneArgOperation(int arg1);
[OperationContract]
void TwoArgOperation(int arg1, string arg2);
[OperationContract]
void MultiArgsOperation(params double[] args);
[OperationContract]
object OperationWithReturnArg(object argObj1);
}
}
契约中定义的方法签名都是一些比较典型的例子，不过在这里没有涉及以自定义类型为参数或返回值的方法签名，因为我还不想马上就要进行数据契约的内容。注意到我在以上的例子中没有添加任何附加的WSDL元数据（例如Name、Namespace等等），这些元数据在后面加入，我觉得这样可以更加清晰地看出这些元数据在WCF中被加入后，如何反映到WSDL。我对这个服务契约的实现非常简单（几乎跟没实现一样。。），因此就不发出来了，同样，部署服务宿主的代码暂时与本文主题无关，因此也不发了，如果想要知道怎么部署服务细节，请参考我的其他文章。以下就是这个服务契约生成的部分WSDL（顺带一句，本人愚钝，想了快10分钟才知道怎么可以看到WSDL的内容，因此在这里分享一下，就是在浏览器中输入发布元数据的URL。。）：
代码
<wsdl:operation name="NoArgsOperation">
<wsdl:input wsaw:Action="http://tempuri.org/IContract/NoArgsOperation"
<wsdl:output wsaw:Action="http://tempuri.org/IContract/NoArgsOperationResponse"
</wsdl:operation>
<wsdl:operation name="OneArgOperation">
<wsdl:input wsaw:Action="http://tempuri.org/IContract/OneArgOperation"
<wsdl:output wsaw:Action="http://tempuri.org/IContract/OneArgOperationResponse"
</wsdl:operation>
<wsdl:operation name="TwoArgOperation">
<wsdl:input wsaw:Action="http://tempuri.org/IContract/TwoArgOperation"
<wsdl:output wsaw:Action="http://tempuri.org/IContract/TwoArgOperationResponse"
</wsdl:operation>
<wsdl:operation name="MultiArgsOperation">
<wsdl:input wsaw:Action="http://tempuri.org/IContract/MultiArgsOperation"
<wsdl:output wsaw:Action="http://tempuri.org/IContract/MultiArgsOperationResponse"
</wsdl:operation>
<wsdl:operation name="OperationWithReturnArg">
<wsdl:input wsaw:Action="http://tempuri.org/IContract/OperationWithReturnArg"
<wsdl:output wsaw:Action="http://tempuri.org/IContract/OperationWithReturnArgResponse"
</wsdl:operation>
</wsdl:portType>
这就是全部定义了吗？它甚至连每个服务操作的签名信息都不齐全呢，很明显这不是全部的内容，更多细节的WSDL马上就发出来，但在此之前，首先看下这部分的WSDL有什么有趣的地方也好。
1.最外层的节点<wsdl:portType>，在上面的WSDL中，它只有一个属性name被设置为"IContract”，没错，这个节点就是代表这我所发布的服务契约，而它的name属性被默认的设置为接口的直接名称（而不是连同命名空间的完整名称）。
2.在portType节点内部的5个<wsdl:operation>节点，很明显，它们的name属性的值，就告知所有人，它们代表着我在服务契约中定义的5个被公开做服务操作的方法。
3.在operation节点里面的<wsdl:input>和<wsdl:output>节点。在WSDL中，这两个节点的顺序就可以代表着一种消息交换模式（Message Exchange Pattern MEP），例如这里使用的是一个input，一个output的标准请求-响应模式。这个定义就意味着，当调用这个服务操作的时候，会首先从客户端发送一个"input"消息；操作结束后服务端会生成一个"output"消息，并返回到客户端，往后还会看到其他的MEP，但它们都是利用这些input、output节点的定义来说明的。
4.无论是input还是output节点，都设置了Action属性，这个属性很重要，它代表了调用服务过程中，往来的消息（可能从Server到Client，也可能相反）各自代表了怎么样的“动作”。例如OperationWithReturnArg这个操作，当一个发送到服务端的消息的首部设置有Action="http://tempuri.org/IContract/OperationWithReturnArg"的时候，WCF知道如果把该消息分发到相应的服务操作中，这也就说明了，这个Action首部可以被用于消息筛选。而作为响应的消息，它的Action首部的值被默认设置为：请求消息的Action首部值 + "Response"。
同样在input和output节点中，均有一个message属性，被设置为："tns:<portType名称>_<operation名称>_<(Input/Ouput)Message>"，这是什么呢？这就是对定义这些操作的细节的XML Schema的引用。接下来就发出这些XML Schema的内容：（为了避免太难看，我以操作为单位，逐个发出它们的XML Schema代码段，but keep it in mind，这些代码是在同一份XML Schema文件中的。）
首先是NoArgsOperation，它的XML Schema代码是最简单的，因为没有返回值，也没有参数：
void NoArgsOperation();
代码
<xs:complexType>
<xs:sequence/>
</xs:complexType>
</xs:element>
<xs:element name="NoArgsOperationResponse">
<xs:complexType>
<xs:sequence/>
</xs:complexType>
</xs:element>
这段XML代码中，定义了两个<xs:element>节点，从它们的name属性马上就可以推断出，它们是对应操作NoArgsOperation的一种XML自定义元素（我先把它们分别称作负载元素）。这两个负载元素中没有任何有趣的内容，因为这个操作本来就没有返回值和参数。
接下来看一下为OneArgOperation操作所定义的XML元素：
void OneArgOperation(int arg1);
代码
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="arg1" type="xs:int"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="OneArgOperationResponse">
<xs:complexType>
<xs:sequence/>
</xs:complexType>
</xs:element>
这个操作只有一个参数，同样没有返回值。在代表请求负载的负载元素中的<xs:sequence>孙节点中（因为中间还有个<xs:complexType）子节点），又出现了一个XML自定义元素（这个我称作参数元素），参数元素有三个属性——minOccurs、name、type，回顾一下前面的服务契约C#代码，就会知道，这三个属性都是对操作方法中参数的描述，分别是：请求消息中，代表该参数的XML节点至少出现多少个、该参数的名称（很明显默认是使用了程序代码中的名称arg1）、该参数的类型。这里有一个很奇怪的地方，那就是允许参数最少出现的次数为0，而事实上这个参数是必须要提供的，在生成的客户端代理中，也必须提供这个参数。
接下来是两个参数的操作TwoArgOperation对应的消息元素定义：
void TwoArgOperation(int arg1, string arg2);
代码
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0" name="arg1" type="xs:int"/>
<xs:element minOccurs="0" name="arg2" nillable="true" type="xs:string"/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="TwoArgOperationResponse">
<xs:complexType>
<xs:sequence/>
</xs:complexType>
</xs:element>
从该操作的负载元素定义可以看出，<xs:sequence>节点所包含的就是负载携带的参数的列表。这个操作中，arg2的CLR类型为string，由于默认可以为null，因此设置了参数元素的nillable属性为true。这个操作在响应消息元素中同样没有什么有趣的地方。
下面是MultiArgsOperation操作的消息元素定义：
void MultiArgsOperation(params double[] args);
代码
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MultiArgsOperationResponse">
<xs:complexType>
<xs:sequence/>
</xs:complexType>
</xs:element>
在服务契约的C#代码中，我使用了C#的params关键字来定义该操作的参数可以为任意多个double类型的值。其实最后这个可变长参数只是作为一个数组来使用（或者说它其实就是一个数组），当然这在元数据中需要特殊对待，但在编程的时候真的使用一个数组参数没什么区别。因此，在XML中定义的负载元素，也是把该参数元素的类型定义为一个"ArrayOfdouble"，这个名字很奇怪，很明显，它不是微软提供的XML预定义数据类型，那这样就必定在某处WSDL中存在这个XML数据类型的定义。关于这个内容，在后面再研究。
继续看下一个操作——OperationWithReturnArg：
object OperationWithReturnArg(object argObj1);
代码
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="OperationWithReturnArgResponse">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
</xs:sequence>
</xs:complexType>
</xs:element>
这个操作是具有一个参数和CLR的object类型返回值的，参数已经没有什么值得研究的地方，看下该操作的响应负载元素的定义，所携带的参数的类型为xs:anyType，在CLR中，object类型是一切类型的基类，任何类型（值类型或引用类型）的对象都可以安全转换为object类型来处理，因此在XML标准数据类型中，可以使用这个anyType来代表object类型的数据。
值得一提的是，服务操作的返回值的定义方式，跟之前看到的操作参数定义方式完全一样。前面已经提到，WSDL标准中，使用input、output两个XML元素来表示一个服务操作的MEP，所以尽管我在服务契约的C#代码中只是定义了一个方法，它具有参数和返回值，但参数跟返回值只是程序语言上的概念；当我为服务操作定义的MEP是请求-响应模式时，在WSDL中就已经把这个单一的方法分解成两个消息传输模式（一个input,一个output），无论是哪个消息传输模式，它所代表的都是消息的传输，而对于消息来说，没有所谓的返回值，只有携带的参数。因此在服务操作对应的负载元素（请求消息负载和响应消息负载）定义中，操作中的参数和返回值都是以一致的方式被定义，因为它们都只是消息所携带的参数（内容）。
还记得刚才的"ArrayOfdouble" ，现在来研究下这个数据类型到底怎么出来的。相信有XML基础的读者都知道，XML具有高扩展性，可以自定义各种标记和XML数据类型，而通常由XML Schema来描述XML文件中各种标记或XML数据类型的细节。那么在所生成WSDL中，在哪里引用外部的（或者生成的）XML Schema呢？先看下下面的WSDL代码：
代码
<xsd:schema targetNamespace="http://tempuri.org/Imports">
<xsd:import schemaLocation="http://localhost:8090/mex?xsd=xsd0" namespace="http://tempuri.org/"/>
<xsd:import schemaLocation="http://localhost:8090/mex?xsd=xsd1" namespace="http://schemas.microsoft.com/2003/10/Serialization/"/>
<xsd:import schemaLocation="http://localhost:8090/mex?xsd=xsd2" namespace="http://schemas.microsoft.com/2003/10/Serialization/Arrays"/>
</xsd:schema>
</wsdl:types>
在<wsdl:types>节点中定义了所有该WSDL所引用的XML Schema，其中包括根据服务契约生成的XML Schema（上面代码中的第一个<xsd:import>）和微软预定义的XML Schema（上面代码中的后两个<xsd:import>）。同时这个被定义的XML Schema通过targetNamespace属性，被导入到http://tempuri.org/Imports命名空间中。命名空间为http://tempuri.org/的XML Schema文件其实就是定义之前所有负载元素的文件，里面根据每个服务操作的MEP，定义所需的负载元素。而第二个<xsd:import>所导入的XML Schema就是微软定义的一些基础XML数据类型。而最后一个<xsd:import>所导入的XML Schema就是"ArrayOfdouble"的定义，下面发出其代码：
代码
<xs:schema elementFormDefault="qualified"
<xs:complexType name="ArrayOfdouble">
<xs:sequence>
<xs:element minOccurs="0" maxOccurs="unbounded" name="double" type="xs:double"/>
</xs:sequence>
</xs:complexType>
<xs:element name="ArrayOfdouble" nillable="true" type="tns:ArrayOfdouble"/>
</xs:schema>
一个值得注意的地方是，这个XML Schema定义了"ArrayOfdouble"后，是把它的定义放入到http://schemas.microsoft.com/2003/10/Serialization/Arrays中，而不是本服务的命名空间中（例如http://tempuri.org/）。
前面说过，WCF自动为每个服务操作生成对应的负载元素，那在WSDL中是怎么把服务操作元素<wsdl:operation>与负载元素<xs:element>关联起来呢？答案是通过<wsdl:message>元素。以MultiArgsOperation为例：
代码
<wsdl:input wsaw:Action=http://tempuri.org/IContract/MultiArgsOperation
<wsdl:output wsaw:Action=http://tempuri.org/IContract/MultiArgsOperationResponse
</wsdl:operation>
<wsdl:message name="IContract_MultiArgsOperation_InputMessage">
<wsdl:part name="parameters" element="tns:MultiArgsOperation"/>
</wsdl:message>
<wsdl:message name="IContract_MultiArgsOperation_OutputMessage">
<wsdl:part name="parameters" element="tns:MultiArgsOperationResponse"/>
</wsdl:message>
<xs:element name="MultiArgsOperation">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="0"
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name="MultiArgsOperationResponse">
<xs:complexType>
<xs:sequence/>
</xs:complexType>
</xs:element>
从上面的WSDL代码，简单总结就是：服务操作定义了消息的输入管道元素、输出管道元素及其顺序；每个输入/输出管道元素引用了一个消息元素；每个消息元素包装着它的负载元素。
这篇文章还没有提及对各种契约进行元数据配置的情况，还记得我用的服务契约（包括其操作契约）是完全没有经过定制配置的。下一篇文章将尝试进行一些定制配置，然后研究一下WSDL会有什么相应的变化。
