Web Service描述語言 WSDL 詳解1Carlos C. TapangInfotects 為什么使用WSDL?
像Internet協議之類的標準有沒有為權威所利用，或者人們這樣看待它是因為順之所獲的好處遠遠超出了代價？曾經有許多試圖建立的標準都流產了。有時候，那些還沒有普遍使用的標準甚至由法令或政府規定強行推出：Ada語言就是一例。
我相信正是跟隨標準所帶來的好處使它廣泛接受。例如，對于鐵路服務來說，真正重要的是，不同公司所鋪設的鐵路結合到一起，或者是來自好幾個公司的產品協調的工作在一起。幾家大的企業合力建立了SOAP標準。Web Service描述語言(WSDL)向這種Web Service的提供商和用戶推出了方便的協調工作的方法，使我們能更容易的獲得SOAP的種種好處。幾家公司的鐵道并在一起不算什么難事，他們所需遵循的只是兩軌間的標準距離。對Web Service來說，這要復雜得多。我們必須先制定出指定接口的標準格式。
曾經有人說SOAP并不真需要什么接口描述語言。如果SOAP是交流純內容的標準，那就需要一種語言來描述內容。SOAP消息確實帶有某些類型信息，因此SOAP允許動態的決定類型。但不知道一個函數的函數名、參數的個數和各自類型，怎么可能去調用這個函數呢？沒有WSDL，我可以從必備文檔中確定調用語法，或者檢查消息。隨便何種方法，都必須有人參與，這個過程可能會有錯。而使用了WSDL，我就可以通過這種跨平臺和跨語言的方法使Web Service代理的產生自動化。就像COM和CORBA的IDL文件，WSDL文件由客戶和服務器約定。
注意由于WSDL設計成可以綁定除SOAP以外的其他協議，這里我們主要關注WSDL在HTTP上和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欄，PortTypes和Bindings欄包含了operation元素，而Services欄包含了port元素。PortTypes欄里的operation元素由Bindings欄里的operation元素進一步修改或描述。???????????? 圖一：抽象定義和具體定義
在此背景中，我將使用標準的XML術語來描述WSDL文檔。Element是指XML的元素，而"attribute"指元素的屬性。于是：
以下是該實例文檔的總述：稍后我將詳細討論每一部分的細節。
第一行申明該文檔是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函數等效：
這個例子足見XML和C相比要冗長的多。（包括<message>元素，XML在示例中共使用了12行代碼來表達相同的單行函數聲明。）
Bindings欄可以有零個、一個或者多個<binding>元素。它的意圖是制定每個<operation>通過網絡調用和回應。Services欄同樣可以有零個、一個、多個<service>元素。它還包含了<port>元素，每個<port>元素引用一個Bindings欄里的<binding>元素。Bindings和Services欄都包含WSDL文檔。Namespace<definitions>和子節點<schema>都是namespace屬性：
每個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屬性，其值為 http://tempuri.org/xsd ，在<schma>元素中定義的所有名字都屬于這個namespace而不是main的target namespace。
<schema>元素的以下這行聲明了默認的namespace。Schema中所有有效的名字都屬于這個namespace。