| 級別： 初級 Russell Butek, 軟件工程師, IBM
2003 年 11 月 01 日 WSDL 綁定樣式可以是 RPC 樣式或文檔樣式。用法可以是編碼的，也可以是文字的。您如何決定使用哪一種樣式/用法的組合呢？本文將幫助您解決這個(gè)問(wèn)題。 Web 服務(wù)是通過(guò) WSDL 文檔來(lái)描述的。WSDL 綁定描述了如何把服務(wù)綁定到消息傳遞協(xié)議（特別是 SOAP 消息傳遞協(xié)議）。WSDL SOAP 綁定可以是 RPC 樣式的綁定，也可以是文檔樣式的綁定。同樣，SOAP 綁定可以有編碼的用法，也可以有文字的用法。這給我們提供了四種樣式/用法模型： - RPC/編碼
- RPC/文字
- 文檔/編碼
- 文檔/文字
除了這些樣式之外，還有一種樣式也很常見(jiàn)，它稱(chēng)為文檔/文字包裝的樣式，算上這一種，在創(chuàng )建 WSDL 文件時(shí)您就有了五種綁定樣式可以從中選擇。您應該選擇哪一種呢？ 對于本文的討論，讓我們從 清單1中的 Java 方法開(kāi)始，并且對其應用 JAX-RPC Java-to-WSDL 規則（請參見(jiàn) 參考資料）。 清單 1. Java 方法
public void myMethod(int x); |
RPC/編碼 采用 清單1中的方法并且使用您喜歡的 Java-to-WSDL 工具來(lái)運行它，指定您想讓它生成 RPC/編碼的 WSDL。您最后應該得到如 清單2所示的 WSDL 片斷。 清單 2. 用于 myMethod 的 RPC/編碼的 WSDL
<message name="myMethodRequest"> <part name="x" type="xsd:int"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's RPC/encoded. --> |
現在用“5”作為參數 x 的值來(lái)調用此方法。我們將發(fā)送一個(gè)與 清單3類(lèi)似的 SOAP 消息。 清單 3. 用于 myMethod 的 RPC/編碼的 SOAP 消息
<soap:envelope> <soap:body> <myMethod> <x xsi:type="xsd:int">5</x> </myMethod> </soap:body> </soap:envelope> |
| 關(guān)于前綴和名稱(chēng)空間的注意事項
為了簡(jiǎn)單起見(jiàn)，在本文的大部分 XML 示例中，我省略了名稱(chēng)空間和前綴。不過(guò)，我還是使用了少數前綴，您可以假定它們是用下列名稱(chēng)空間進(jìn)行定義的。 - xmlns:xsd="http://www.w3.org/2001/XMLSchema"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
| | 對于這個(gè) RPC/編碼的示例中的 WSDL 和 SOAP 消息，有許多需要注意的事項： 優(yōu)點(diǎn)
- WSDL 基本達到了盡可能地簡(jiǎn)單易懂的要求。
- 操作名出現在消息中，這樣接收者就可以很輕松地把消息發(fā)送到方法的實(shí)現。
缺點(diǎn)
- 類(lèi)型編碼信息（比如
xsi:type="xsd:int" ）通常就是降低吞吐量性能的開(kāi)銷(xiāo)。 - 您不能簡(jiǎn)單地檢驗此消息的有效性，因為只有
<x xsi:type="xsd:int">5</x> 行包含在 Schema 中定義的內容；其余的 soap:body 內容都來(lái)自 WSDL 定義。 有沒(méi)有一種方法能夠保留這些優(yōu)點(diǎn)而消除其中的缺點(diǎn)呢？或許有。讓我們來(lái)看一看 RPC/文字的樣式。
RPC/文字 用于我們的方法的 RPC/文字的 WSDL 看起來(lái)與 RPC/編碼的 WSDL 幾乎一樣（請參見(jiàn) 清單4）。只是綁定的用法由 編碼改為 文字。僅此而已。 清單
4. 用于 myMethod 的 RPC/文字的 WSDL
<message name="myMethodRequest"> <part name="x" type="xsd:int"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's RPC/ literal. --> |
RPC/文字的 SOAP 消息又是怎樣的呢（請參見(jiàn) 清單 5）？這里的更改要多一點(diǎn)。去掉了類(lèi)型編碼。 清單 5. 用于 myMethod 的
RPC/文字的 SOAP 消息
<soap:envelope> <soap:body> <myMethod> <x>5</x> </myMethod> </soap:body> </soap:envelope> |
下面是這種方法的優(yōu)點(diǎn)和缺點(diǎn)： 優(yōu)點(diǎn)
- WSDL 還是基本達到了盡可能地簡(jiǎn)單易懂的要求。
- 操作名仍然出現在消息中。
- 去掉了類(lèi)型編碼。
缺點(diǎn)
- 您仍然不能簡(jiǎn)單地檢驗此消息的有效性，因為只有
<x xsi:type="xsd:int">5</x> 行包含在 Schema 中定義的內容；其余的 soap:body 內容都來(lái)自 WSDL 定義。 文檔樣式如何呢？它們能夠幫助克服這些困難嗎？
文檔 我不知道有誰(shuí)懂得這種方法的真正含義。我也不知道這種方法的任何實(shí)現。它將可能從 WSDL 的后續版本中消失。所以我們還是討論別的吧。
文檔 文檔/文字的 WSDL 對 RPC/文字的 WSDL 作了一些更改。它們之間的不同之處顯示在 清單6中。
清單6. 用于 myMethod 的文檔/文字的 WSDL
<types> <schema> <element name="xElement" type="xsd:int"/> </schema> </types> <message name="myMethodRequest"> <part name="x" element="xElement"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's document/literal. --> |
而現在的 SOAP 應該如 清單 7所示：
清單7. 用于 myMethod 的文檔/文字的 SOAP 消息
<soap:envelope> <soap:body> <xElement>5</xElement> </soap:body> </soap:envelope> |
| 關(guān)于消息組成部分的注意事項
我本來(lái)可以只更改綁定，就像我從 RPC/編碼轉到 RPC/所做的那樣。它將是合法的 WSDL。然而，WS-I 基本概要（WS-I Basic Profile）（請參見(jiàn) 參考資料）規定文檔/文字的消息的組成部分引用元素而不是類(lèi)型，所以我遵循了 WS-I（并且此處使用元素部分可以很好地把我們帶到關(guān)于文檔/文字包裝的樣式的討論）。 | | 下面是這種方法的優(yōu)點(diǎn)和缺點(diǎn)： 優(yōu)點(diǎn)
- 沒(méi)有編碼信息
- 您可以在最后用任何 XML 檢驗器檢驗此消息的有效性。
soap:body （ <xElement>5</xElement> ）中每項內容都定義在 Schema 中。 缺點(diǎn)
- WSDL 變得有些復雜。不過(guò)，這是一個(gè)非常小的缺點(diǎn)，因為 WSDL 并沒(méi)有打算由人來(lái)讀取。
- SOAP 消息中缺少操作名。而如果沒(méi)有操作名，發(fā)送就可能比較困難，并且有時(shí)變得不可能。
文檔/文字的樣式看起來(lái)似乎只是重新安排了 RPC/文字的模型的優(yōu)點(diǎn)和缺點(diǎn)。您可以檢驗消息的有效性，但是您失去了操作名。有沒(méi)有一種方法可以改進(jìn)這一點(diǎn)呢？有的。它就是文檔/文字包裝的樣式。
文檔 在我說(shuō)明文檔/文字包裝的樣式的含義之前，讓我給您展示 清單 8和 清單9中的 WSDL 和 SOAP 消息。
清單8. 用于 myMethod 的文檔/文字包裝的 WSDL
<types> <schema> <element name="myMethod"/> <complexType> <sequence> <element name="x" type="xsd:int"/> </sequence> </complexType> </element> </schema> </types> <message name="myMethodRequest"> <part name=" parameters" element=" myMethod"/> </message> <message name="empty"/> <portType name="PT"> <operation name="myMethod"> <input message="myMethodRequest"/> <output message="empty"/> </operation> </portType> <binding .../> <!-- I won't bother with the details, just assume it's document/literal. --> |
WSDL Schema 現在把參數放在包裝中（請參見(jiàn) 清單9）。
清單:9. 用于 myMethod 的文檔/文字包裝的 SOAP 消息
<soap:envelope> <soap:body> <myMethod> <x>5</x> </myMethod> </soap:body> </soap:envelope> |
注意到此 SOAP 消息看起來(lái)非常類(lèi)似于 RPC/文字的 SOAP 消息。您可能會(huì )說(shuō)，它看起來(lái)與 RPC/文字的 SOAP 消息是完全一樣的，不過(guò)，這兩種消息之間存在著(zhù)微妙的區別。在 RPC/文字的 SOAP 消息中， <soap:body> 的 <myMethod> 子句是操作的名稱(chēng)。在文檔/文字包裝的 SOAP 消息中， <myMethod> 子句是單個(gè)輸入消息的組成部分引用的元素的名稱(chēng)。因此，包裝的樣式具有這樣的一個(gè)特征，輸入元素的名稱(chēng)與操作的名稱(chēng)是相同的。此樣式是把操作名放入 SOAP 消息的一種巧妙方式。 文檔/文字包裝的樣式的特征有： - 輸入消息只有一個(gè)組成部分。
- 該部分就是一個(gè)元素。
- 該元素有與操作相同的名稱(chēng)。
- 該元素的復雜類(lèi)型沒(méi)有屬性。
下面是這種方法的優(yōu)點(diǎn)和缺點(diǎn)： 優(yōu)點(diǎn)
- 沒(méi)有編碼信息。
- 出現在 soap:body 中的每項內容都是由 Schema 定義的，所以您現在可以很容易地檢驗此消息的有效性。
- 方法名又出現在 SOAP 消息中。
缺點(diǎn)
- WSDL 甚至更復雜，但是這仍然是一個(gè)非常小的缺點(diǎn)。
如您所見(jiàn)，文檔/文字包裝的樣式還是有一些缺點(diǎn)，不過(guò)與優(yōu)點(diǎn)比起來(lái)，它們都顯得無(wú)足輕重。 | RPC/文字包裝的樣式?
從 WSDL 的角度來(lái)看，沒(méi)有理由只是把把包裝的樣式和文檔/文字綁定聯(lián)系在一起。它可以很容易地應用于 RPC/文字綁定。但是這樣做是相當不明智的。SOAP 將包含操作的一個(gè) myMethod 元素和元素名稱(chēng)的子 myMethod 元素。另外，即使它是一個(gè)合法的 WSDL，RPC/文字元素部分也不遵循 WS-I。 | | 文檔/文字的樣式在哪里定義
這種包裝的樣式來(lái)源于 Microsoft。沒(méi)有定義這種樣式的規范；所以雖然這種樣式是一個(gè)好的東西，但不幸的是，為了與 Microsoft 和其他公司的實(shí)現進(jìn)行互操作，現在惟一的選擇就是根據 Microsoft WSDL 的輸出來(lái)猜測它是如何工作的。文檔/文字包裝的樣式也實(shí)現在 IBM WebSphere SDK for Web Services 中（請參見(jiàn) 參考資料）。在這個(gè)示例中，樣式是相當明顯的；但是也存在個(gè)別情況，在這些情況中，由于缺少定義而導致需要操作的適當事項不夠特別清晰。我們希望看到的最理想的情況就是將來(lái)能有像 Web 服務(wù)互操作組織（Web Services Interoperability Organization）這樣的獨立團體來(lái)幫助對此進(jìn)行穩定化和標準化。
為什么不始終采用文檔/文字包裝的樣式 至此，本文已經(jīng)給了您這樣的一個(gè)印象，文檔/文字包裝的樣式是最好的方法。而實(shí)際的情況往往確實(shí)如此。不過(guò)，仍然存在著(zhù)一些情況，在這些情況下，您最好是換一種別的樣式。 采用文檔/文字非包裝的樣式的理由
如果您已經(jīng)重載了操作，就不能采用文檔/文字包裝的樣式。
想象一下，除了我們一直在使用的方法之外，還有另一種方法，請參見(jiàn) 清單10。
清單10. 用于文檔/文字包裝的問(wèn)題方法
public void myMethod(int x); public void myMethod(int x, String y); |
WSDL 允許重載的操作。但是當您添加包裝的樣式到 WSDL 時(shí)，需要元素有與操作相同的名稱(chēng)，并且在 XML 中不能有兩個(gè)名稱(chēng)相同的元素。所以您必須采用文檔/文字非包裝的樣式或某種 RPC 樣式。 采用 RPC/文字的樣式的理由
由于文檔/文字非包裝的樣式?jīng)]有提供操作名，所以在有些情況下，您將需要采用某種 RPC 樣式。比如說(shuō) 清單11中的一組方法。
清單11. 用于文檔/文字非包裝的樣式的問(wèn)題方法
public void myMethod(int x); public void myMethod(int x, String y); public void someOtherMethod(int x); |
現在假定您的服務(wù)器接收到文檔/文字的 SOAP 消息（您可以回過(guò)頭在 清單 7中看一看它）。服務(wù)器應該發(fā)送哪一種方法呢？所有您能確切知道的就是，它一定不是 myMethod(int x, String x) ，因為消息只有一個(gè)參數，而這種方法需要兩個(gè)參數。它可能是其他兩種方法中的一種。采用文檔/文字的樣式，您沒(méi)有辦法知道是哪一種方法。 假定服務(wù)器接收到一個(gè) RPC/文字的消息（比如 清單5中的），而不是文檔/文字的消息。對于這種消息，服務(wù)器很容易決定把它發(fā)送到哪一種方法。您知道操作名是 myMethod，并且也知道只有一個(gè)參數，所以它必定是 myMethod(int x) 。 采用
采用 RPC/編碼的理由有很多。其中兩個(gè)主要的原因是：
數據圖形
設想您有一個(gè)二進(jìn)制樹(shù)，其中的節點(diǎn)定義在 清單12中。
清單12. 二進(jìn)制樹(shù)節點(diǎn) Schema
<complexType name="Node"> <sequence> <element name="name" type="xsd:string"/> <element name="left" type="Node" xsd:nillable="true"/> <element name="right" type="Node" xsd:nillable="true"/> </sequence> </complexType> |
根據這種節點(diǎn)定義，我們可以構造一個(gè)樹(shù)形結構，它的根節點(diǎn) A 通過(guò)它左邊和右邊的的鏈接可以指向節點(diǎn) B（請參見(jiàn) 圖1）。
發(fā)送數據圖形的標準方式是使用 href 標記，它是 RPC/編碼的樣式（ 清單13）的一部分。
清單:13. RPC/編碼的二進(jìn)制樹(shù)
<A> <name>A</name> <left href="12345"/> <right href="12345"/> </A> <B id="12345"> <name>B</name> <left xsi:nil="true"/> <right xsi:nil="true"/> </B> |
在任何文字的樣式中，href 屬性都是不可用的，這樣圖形鏈接就不再起作用了（ 清單14和 圖2）。您仍然有一個(gè)根節點(diǎn) A，它從左邊指向一個(gè)節點(diǎn) B，從右邊指向另一個(gè)節點(diǎn) B。這兩個(gè) B 節點(diǎn)是等同的，但它們不是相同的節點(diǎn)。是復制了數據而不是引用了兩次數據。
14. 文字二進(jìn)制樹(shù)
<A> <name>A</name> <left> <name>B</name> <left xsi:nil="true"/> <right xsi:nil="true"/> </left> <right> <name>B</name> <left xsi:nil="true"/> <right xsi:nil="true"/> </right> </A> |
在文字樣式中，您可以通過(guò)各種方法構造圖形，但是卻沒(méi)有標準的方法；所以您做的任何事情很可能不能與網(wǎng)絡(luò )中其他端點(diǎn)上的服務(wù)進(jìn)行互操作。 多態(tài)性
看一看 清單15中使用多態(tài)性 Schema 的 WSDL。 清單
15. 一個(gè)多態(tài)性 WSDL 的示例
<types> <schema> <complexType name="animal"> <sequence> <element name="name" type="xsd:string"/> </sequence> </complexType> <complexType name="dog"> <complexContent mixed="false"> <extension base="animal"> <sequence> <element name="breed" type="xsd:string"/> </sequence> </extension> </complexContent> </complexType> </schema> </types> <message name="in"> <part name="trainee" type="animal"/> </message> <message name="empty"/> <portType name="AnimalTrainer"> <operation name="train"> <input message="in"/> <output message="empty"/> </operation> </portType> |
當您把一個(gè) dog 的實(shí)例傳送給 train 操作時(shí)，所生成的 SOAP 消息必須包含類(lèi)型編碼信息，這樣接收終端才能知道它所接收的是 animal 的哪一個(gè)擴展（請參見(jiàn) 清單16）。這種類(lèi)型編碼信息可用在 RPC/編碼的樣式中。 清單
16. 一個(gè)多態(tài)性 SOAP 消息
<soap:envelope> <soap:body> <train> <trainee xsi:type="Dog"> <name>Bob</name> <breed>Bloodhound</breed> </trainee> </train> </soap:body> </soap:envelope> |
總結 有四種綁定樣式（其實(shí)真正有五種，不過(guò)文檔/編碼的樣式?jīng)]有什么意義）。雖然每種樣式都有自己的用武之地，但是在大多數情況下，最好的樣式是文檔/文字包裝的樣式。
參考資料
關(guān)于作者 | | | | Russell Butek 是 IBM WebSphere Web 服務(wù)引擎的一名開(kāi)發(fā)人員。他同時(shí)也是 JAX-RPC Java Specification Request（JSR）專(zhuān)家組中 IBM 的代表。他參與實(shí)現了 Apache 的 AXIS SOAP 引擎，并且推動(dòng) AXIS 1.0 遵循 JAX-RPC 1.0。此前，他是 IBM CORBA ORB 的一名開(kāi)發(fā)人員和許多 OMG 特別工作組（他擔任主席職務(wù)）、核心特別工作組和互操作性特別工作組中 IBM 的代表。您可以通過(guò) butek at us.ibm.com 與 Russell 聯(lián)系。 | | 
