Web 服務描述語言 （WSDL）

《Web 服務描述語言 （WSDL）》由會員分享，可在線閱讀，更多相關《Web 服務描述語言 （WSDL）（45頁珍藏版）》請在裝配圖網上搜索。

1、Web 服務描述語言 (WSDL) 1.0 2000年9月25日 作者（按姓氏字母順序排列）： Erik Christensen，Microsoft Francisco Curbera，IBM Greg Meredith，Microsoft Sanjiva Weerawarana，IBM 版權所有? 2000 Ariba，International Business Machines Corporation，Microsoft 摘要 WSDL 是一種 XML 格式，用于將網絡服務描述為一組端點，這些端點對包含面向文檔信息或面向過程信息的消息進行操作。這種格式首先

2、對操作和消息進行抽象描述，然后將其綁定到具體的網絡協(xié)議和消息格式上以定義端點。相關的具體端點即組合成為抽象端點（服務）?？梢詫?WSDL 進行擴展，這樣無論通信時使用何種消息格式或網絡協(xié)議，都可以對端點及其消息進行描述。但是，本文檔中所述的綁定只涉及有關如何將 WSDL 與 SOAP 1.1、HTTP GET/POST 和 MIME 一起使用的問題。 此版本的 WSDL 語言尚處于初步階段，沒有提供框架來說明端點的撰寫過程。描述這些約定的完整框架應包含撰寫服務的方式和表達服務行為的方式（即相應的用于發(fā)送和接收消息的規(guī)則）。服務的撰寫應滿足兩個要求：(1) 確保類型的安全性，(2) 允許在運行

3、時通過交換和綁定服務引用來傳遞引用。后面的這一條對于在運行期協(xié)商約定以及捕獲引用服務和代理服務的行為至關重要。 WSDL 規(guī)范的作者希望及時發(fā)布 WSDL 的修訂版和/或一些附加文檔，包括：(1) 撰寫服務的框架；(2) 描述服務行為的框架。 狀態(tài) 本草案介紹了 Ariba、IBM 和 Microsoft 當前在服務描述方面的一些思路。它對 NASSL、SCL 和 SDL（有關這方面的早期建議）中的一些概念進行了整理合并。 目錄 1. 簡介 2. 服務定義 o 文檔結構 o 類型 o 消息 o 端口類型 o 綁定 o 端口 o 服務 3. SO

4、AP 綁定 o SOAP 示例 o SOAP 綁定如何擴展 WSDL o soap:binding o soap:operation o soap:body o soap:fault o soap:header o soap:address 4. HTTP GET 和 POST 綁定 o HTTP GET/POST 示例 o HTTP GET/POST 綁定如何擴展 WSDL o http:address o http:binding o http:operation o http:urlEncoded o http:urlRep

5、lacement 5. MIME 綁定 o MIME 綁定示例 o MIME 綁定如何擴展 WSDL o mime:content o mime:multipartRelated o soap:body o mime:mimeXml 6. 參考資料 o 有關 URI 的說明 o WSDL 示例的線上格式 o 擴展性元素的位置 o 架構 簡介 由于通信協(xié)議和消息格式在 Web 社區(qū)中已經過標準化，因而有可能以某種結構化的方式對通信加以描述，而且實現這一點也顯得日益重要。WSDL 定義了一種 XML 語法，將網絡服務描述為能夠進行消息

6、交換的通信端點的集合，從而滿足了這種需求。WSDL 服務定義為分布式系統(tǒng)提供了文檔，并且可用于自動執(zhí)行應用程序通信中所涉及的細節(jié)。 WSDL 文檔將服務定義為網絡端點或端口的集合。在 WSDL 中，由于端點和消息的抽象定義已從具體的網絡部署或數據格式綁定中分離出來，因此可以對抽象定義進行再次使用：消息，指對交換數據的抽象描述；而端口類型，指操作的抽象集合。用于特定端口類型的具體協(xié)議和數據格式規(guī)范構成了可以再次使用的綁定。將網絡地址與可再次使用的綁定相關聯(lián)，可以定義一個端口，而端口的集合則定義為服務。因此，WSDL 文檔在網絡服務的定義中使用下列元素： · Types - 數據類型定義的容器

7、，它使用某種類型系統(tǒng)（如 XSD）。 · Message - 通信數據的抽象類型化定義。 · Operation - 對服務所支持的操作的抽象描述。 · Port Type - 操作的抽象集合，這些操作由一個或多個端點支持。 · Binding - 特定端口類型的具體協(xié)議和數據格式規(guī)范。 · Port - 定義為綁定和網絡地址組合的單個端點。 · Service - 相關端點的集合。 將在第二節(jié)中對這些元素進行詳細說明。應該注意的是，WSDL 并沒有引入新的類型定義語言。雖然 WSDL 知道，要描述消息格式需要豐富的類型系統(tǒng)，并且它也支持“XML 架構規(guī)范 (XSD

8、)”作為其標準類型系統(tǒng)，但是，由于不可能只用一種類型系統(tǒng)語法來描述現在和將來的所有消息格式，因此 WSDL 允許通過擴展來使用其它類型定義語言。 此外，WSDL 還定義了通用的綁定機制。通過該機制可使特定的協(xié)議、數據格式或結構與抽象的消息、操作或端點相關聯(lián)。該機制還允許對抽象定義進行再次使用。 雖然本文檔定義了上述語言擴展，但這些擴展均位于核心服務定義框架的上部。所以一定能將 WSDL 與其它綁定擴展一起使用。 WSDL 文檔示例 下例是一個提供股票報價的簡單服務的 WSDL 定義。該服務支持名為 GetLastTradePrice 的單一操作，這個操作是通過在 HTTP 上運行 S

9、OAP 1.1 協(xié)議來實現的。該請求接受一個類型為字符串的 ticker 符號，并返回類型為浮點數的價格。有關此定義中所用元素的詳細說明，請參見第 2 節(jié)（核心語言）和第 3 節(jié)（SOAP 綁定）。 示例 1 通過 HTTP 運行的 SOAP 1.1 請求/響應

10、mas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">

11、

12、

13、"xsd1:TradePriceResult"/>

14、inding name="StockQuoteSoapBinding" type="tns:StockQuotePortType">

15、eral" namespace=" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>

<

16、/output> 我的第一次服務 * ? ? ? * <-- extensibility element --> *

22、 * * ? *

23、> ? ? ? ? ?

24、ge="qname"> * ? * ? <-- extensibility element --> * *

25、 ? <-- extensibility element --> * ? ? <-- extensibility element --> ?

26、l:documentation…/> ? <-- extensibility element --> * * ? <-- extensibility element --> *

27、 * ? * ? <-- extensibility element --> <-- extensibility element --> <--

28、 extensibility element --> * 服務是使用以下五個主要元素來定義的： · types：提供用于描述所交換消息的數據類型定義。 · message：代表所傳輸數據的抽象定義。消息由一些邏輯片段構成，每個邏輯片段分別與某個類型系統(tǒng)中的定義相關聯(lián)。 · portType：指抽象操作的集合。每個操作引用一條輸入消息和一條輸出消息。 · binding：為由特定 portType 定義的操作和消息指定具體的協(xié)議和數據格式規(guī)范。 · port：為綁定指定一個地址，從而定義一個通信端點。 · service：用

29、于聚合一組相關端口。 將在第 2.2 至 2.7 節(jié)中對這些元素進行詳細說明。本節(jié)的其余部分將介紹 WSDL 中有關文檔命名、引用文檔定義、使用語言擴展和添加上下文文檔等方面的規(guī)則。 文檔命名和鏈接 可以為 WSDL 文檔分配一個類型為 NCNAME 的可選 name 屬性（該屬性將作為文檔的一種輕量級形式）?；蛘?，也可以指定一個類型為 URI 的 targetNamespace 屬性。該 URI 不能是相對 URI。 WSDL 允許使用 import 語句將名稱空間與文檔位置相關聯(lián)：

30、ocation="uri"/> * WSDL 中的 QNames 解析方法與 XML 架構規(guī)范中所述的 QNames 解析方法相似。 使用 QName 可以創(chuàng)建對 WSDL 定義的引用?？梢砸?WSDL 文檔中的以下各類定義： · WSDL 定義：service、port、message、bindings 和 portType · 其它定義：如果通過擴展添加了其它定義，這些定義應使用 QName 鏈接。 上面列出的每種 WSDL 定義類型都有自己的名稱范圍（也就是說，端口名稱和消息名稱絕對不會發(fā)生沖突）。同一個名稱范圍內的名稱在 WSDL 文檔中

31、必須是唯一的。 撰寫樣式 使用 import 元素可以將服務定義的不同元素分別放入單獨的文檔中，需要時再將其導入。這種技術可以根據定義的抽象級別將其分開，這樣有助于編寫更為清晰的服務定義。使 用這種技術還可以對各種服務定義進行最大限度的再利用。因此，具有這種結構的 WSDL 文檔更易于使用和維護。在示例 2 中，我們將定義分為數據類型定義、抽象定義和特定服務綁定三類，并將其分別放入三個文檔中。當然，這種機制的使用并不僅限于此例中明確出現的定義（這些定 義只使用了本規(guī)范中所定義的語言元素），也可以使用類似的方式對基于其它語言擴展的其它定義類型進行編碼和再利用。 示例 2. 示例 1 中

32、所述服務的另一種撰寫樣式。

33、

34、tNamespace=" xmlns:tns=" xmlns:xsd1=" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns="http://schemas.xmlsoap.org/wsdl/">

35、element="xsd1:GetLastTradePrice"/>

36、"tns:GetLastTradePriceRequest"/>

38、 > 我的第一個服務

39、on="http://my.org/stockquote"/> 語言的擴展性和綁定 在 WSDL 中，術語“綁定”表示將協(xié)議或數據格式信息與某個抽象實體（如 message、operation 或 portType 等）相關聯(lián)的過程。WSDL 允許將代表特定技術的元素（此處稱為擴展性元素）放置在 WSDL 所定義的各種元素之下。這些可擴展點通常用于指定特定協(xié)議或消息格式的綁定信息，但也可用于其它用途。擴展性元素所用的 XML 名稱空間不能與 WSDL 的名稱空間相同。附錄 A3 中詳細說明了

40、擴展性元素可在文檔中的哪些位置出現。 擴展性元素通常用于指定某種特定技術的綁定。為了區(qū)分特定技術綁定的語義對通信是必需的還是可選的，可以在擴展性元素上設置一個布爾型的 wsdl:required 屬性。該屬性的默認值為假 (false)。定義該屬性的名稱空間為“http://schemas.xmlsoap.org/wsdl/soap/”。 有關擴展性元素的示例，請參見第 3 節(jié)、第 4 節(jié)和第 5 節(jié)。 文檔 WSDL 使用可選的 wsdl:document 元素作為可閱讀文檔的容器。該元素的內容可以是任意文本和元素（混雜在 XSD 中）。在所有 WSDL 語言元素中，都允許使用文檔

41、元素。 類型 types 元素包含與交換的消息相關的數據類型定義。為了獲得最大程度的互操作性和平臺中立性，WSDL 選用 XSD 作為標準類型系統(tǒng)，并將其當作固有類型系統(tǒng)。 * 可以使用 XSD 類型系統(tǒng)來定義消息中的類型，無論所得到的線上格式是否為 XML，也無論所得到的 XSD 架構是否驗證了該特定線上格式。如果同一消息具有多個綁定，或者雖然只有一個綁定，但該綁定類型的類型系統(tǒng)不通用，則會出現非常有趣的情況。在這種情況

42、下，如果使用 XSD 對抽象類型進行編碼，建議遵循下列原則： · 使用元素形式（不要使用屬性）。 · 不要使用對線上編碼非常特殊的屬性或元素（也就是說，與消息的抽象內容無關的屬性或元素），例如，soap:root、soap:encodingStyle、xmi:id 和 xmi:name 等。 · 使用 Soap:Array 類型來為數組類型建模（無論最終形式是否實際使用 SOAP 1.1 版文檔的第 5 節(jié)中指定的編碼方式）。使用 ArrayOfXXX 作為數組類型的名稱（其中，XXX 表示數組中項的類型）。 但是，由于不可能使用一種類型系統(tǒng)語法來描述現在和將來的所有抽象類型，因

43、此，WSDL 允許通過擴展性元素來添加類型系統(tǒng)。擴展性元素可能出現在 types 元素之下，它標識正在使用的類型定義系統(tǒng)并為類型定義提供 XML 容器元素。該元素的作用與 XML 架構語言的 schema 元素的作用相似。 <-- type-system extensibility element --> * 消息 消息由一個或多個邏輯片段構成。每個片段使用一個消息類型屬性與某個類型系統(tǒng)的類型相關聯(lián)。消息類型屬性的集合是可擴展的。WSDL 定義了以下幾個

44、消息類型屬性，與 XSD 一起使用： · element：使用 QName 引用一個 XSD 元素。 · type：使用 QName 引用一個 XSD simpleType 或 complexType。 如果使用的名稱空間與 WSDL 所用的名稱空間不同，還可以定義其它消息類型屬性。綁定擴展性元素也可以使用消息類型屬性。 定義消息的語法如下所示。其中，消息類型屬性以粗體顯示（消息類型屬性因所用類型系統(tǒng)而異）。 *

45、"qname" type="qname"?/> * 消息 name 屬性所指定的名稱在其所在 WSDL 文檔定義的全部消息中是唯一的。 片段 name 屬性所指定的名稱在其所在消息的所有片段中是唯一的。 消息片段 片段是一種用于描述消息的邏輯抽象內容的靈活機制。綁定可以引用片段的名稱來指定有關該片段的綁定專用信息。例如，如果定義用于 RPC 的消息，片段可以代表消息中的參數。但是，為了確定該片段的實際含義，必須對綁定進行檢查。 如果消息有多個邏輯單元，則使用多個片段元素。例如，以下消息包括“訂單”和“客戶”兩個片段元

46、素。

47、

48、

49、types> 但是，如果消息內容十分復雜，則需要使用另一種語法，通過直接使用類型系統(tǒng)來指定消息的復合結構。在下例中，主體是一個訂單或一組客戶。

50、xType name="POType">

51、

53、s="0" maxOccurs="unbounded" type="tns:CustomerType"/> 抽象消息與具體消息 消 息定義始終被當作消息內容的抽象定義。消息綁定描述如何將抽象內

54、容映射為具體的格式。但是，在某些情況下，抽象定義可能與一個或多個綁定的具體表示方式完 全相符或十分接近，致使這些綁定不能提供任何映射信息或只能提供少量信息；而同一消息定義的另一個綁定可能需要大量的映射信息。因此，只有在對綁定進行檢 查之后，才能確定消息的實際“抽象程度”。 端口類型 端口類型是一組指定的抽象操作，以及所涉及的抽象消息。 *

55、sdl:definitions> 端口類型 name 屬性所指定的名稱在其所在 WSDL 文檔定義的所有端口類型中是唯一的。 操作是通過 name 屬性來命名的。 WSDL 提供以下四個可得到端點支持的傳輸原語： · 單向 (One-way)：端點接收消息。 · 請求響應 (Request-response)：端點接收消息，然后發(fā)送相關消息。 · 要求響應 (Solicit-response)：端點發(fā)送消息，然后接收相關消息。 · 通知 (Notification)：端點發(fā)送消息。 WSDL 稱這些原語為操作。雖然可以使用兩條單向消息抽象地模擬請求/響應或要求/響應，但

56、是將其作為原語操作類型模型也很有用，因為： · 經常需要使用這兩個操作。 · 可以使順序相互關聯(lián)，而不必引入更為復雜的流信息。 · 某些端點可以只接收消息（如果它們是同步請求響應的結果）。 · 需要流定義時，可以通過算法從這些原語派生簡單的流。 雖然請求/響應或要求/響應在 WSDL 文檔中是邏輯相關的，仍然有一個特定的綁定描述具體的相關信息。例如，請求消息和響應消息可以作為一兩個實際網絡通信的一部分進行交換。 操作使用類型為 QName 的 message 屬性來引用所涉及的消息。該屬性遵循 WSDL 為鏈接定義的規(guī)則。 單向操作 單向操作的語法是：

57、:definitions…> * input 元素指定單向操作的抽象消息格式。 請求響應操作 請求響應操作的語法是： *

58、 *

59、itions> input 元素和 output 元素分別指定請求和響應的抽象消息格式?？蛇x的 fault 元素為操作可能產生的錯誤消息（協(xié)議所特有的除外）指定抽象消息格式。 請注意，請求響應操作是一個抽象的概念；必須查詢特定的綁定，才能確定消息的實際發(fā)送方式：是在同一個通信中發(fā)送（例如 HTTP 請求/響應），還是作為兩個獨立的通信發(fā)送（例如兩個 HTTP 請求）。 要求響應操作 要求響應操作的語法是： *

60、eterOrder="nmtokens"> * output 元素和 input 元素分別指定所要求的請求和響

61、應的抽象消息格式?？蛇x的 fault 元素為操作可能產生的錯誤消息（協(xié)議所特有的除外）指定抽象消息格式。 請注意，請求響應操作是一個抽象的概念；必須查詢特定的綁定，才能確定消息的實際發(fā)送方式：是在同一個通信中發(fā)送（例如 HTTP 請求/響應），還是作為兩個獨立的通信發(fā)送（例如兩個 HTTP 請求）。 通知操作 單向操作的語法是： *

62、sage="qname"/> output元素指定通知操作的抽象消息格式。 操作中的元素名稱 inuput 元素和 output 元素的 name 屬性所指定的名稱在其所在端口類型的所有 input 元素和 output 元素中是唯一的。 為了避免需要為操作中的每個 input 元素和 output 元素指定名稱，WSDL 提供了一些以操作名稱為基礎的默認值。如果未在單向消息或通知消息中指定 name 屬性，則該屬性默認為操作的名稱；如果未在請

63、求響應或要求響應操作的輸入或輸出消息中指定 name 屬性，則該屬性默認為分別附帶有“Request”/“Solicit”或“Response”的操作名稱。 必須為每個 fault 元素指定名稱，綁定才能指定錯誤消息的具體格式。fault 元素的名稱在為該操作定義的錯誤集合中是唯一的。 操作中的參數順序 操作并不指定它們是否與類似 RPC 這樣的綁定一起使用。但是，當操作與 RPC 綁定一起使用時，能夠捕獲原始 RPC 函數簽名非常有用。因此，請求響應或要求響應操作可以通過類型為 nmtokens 的 parameterOrder 屬性來指定參數名稱列表。該屬性的值是一個由單個空格分隔的消息片段名稱列表。指定的片段必須遵循以下規(guī)則： · 指定片段的順序必須反映 RPC 簽名中的參數順序 · return 值片段不在列表中出現 · 如果片段名稱同時在輸入和輸出消息中出現，則片段是 in/out 參數 · 如果片段名稱只在輸入消息中出現，則片段是 in 參數 · 如果片段名稱只在輸出消息中出現，則片段是 out 參數 請注意，該信息僅作為“提示”，對于那些不關心 RPC 簽名的用戶，完全可以忽略。而且，即使當操作與類似 RPC 這樣的綁定一起使用時，也不是必須使用