kapok

內(nèi)容： 將您的服務(wù)設(shè)置為使用文檔樣式 文檔樣式的好處 何時(shí)使用文檔樣式 結(jié)束語 參考資料 關(guān)于作者 對(duì)本文的評(píng)價(jià) 相關(guān)內(nèi)容： 使用 WSDL 部署 Web 服務(wù) 訂閱: developerWorks 時(shí)事通訊

http://www-128.ibm.com/developerworks/cn/webservices/ws-docstyle/

James McCarthy
總裁兼首席技術(shù)執(zhí)行官, Symmetry Solutions，Inc.
2002 年 6 月

大部分 Web 服務(wù)都是圍繞著遠(yuǎn)程過程調(diào)用而構(gòu)建的，而 WSDL 規(guī)范允許另外一種 Web 服務(wù)體系結(jié)構(gòu)：文檔樣式（document style）。在該體系結(jié)構(gòu)中，整個(gè)文檔在服務(wù)客戶端和服務(wù)器之間進(jìn)行交換。在本文中，James McCarthy 將向您解釋文檔樣式以及應(yīng)該何時(shí)使用它。

在 Web 服務(wù)描述語言（Web Service Definition Language，WDSL）規(guī)范中隱含著一個(gè)非常巧妙的轉(zhuǎn)換開關(guān)，它可以將 Web 服務(wù)的 SOAP 綁定從遠(yuǎn)程過程調(diào)用轉(zhuǎn)換成 pass-through 文檔。在 SOAP 協(xié)議綁定中的樣式屬性可以包含這兩個(gè)值中的一個(gè)： rpc 或 document 。當(dāng)屬性被設(shè)定為文檔樣式時(shí)，客戶端知道應(yīng)該使用 XML 模式而不是遠(yuǎn)程過程調(diào)用約定。本文將提供對(duì)這個(gè) WSDL 轉(zhuǎn)換開關(guān)的說明，描述它的好處，并將解釋應(yīng)該何時(shí)使用 pass-through 文檔。

將您的服務(wù)設(shè)置為使用文檔樣式
首先，讓我們簡(jiǎn)要地談?wù)?WSDL 的一些要點(diǎn)，來理解這個(gè)巧妙的轉(zhuǎn)換是如何發(fā)生的。 WSDL 是一項(xiàng) XML 規(guī)范，它被用來描述網(wǎng)絡(luò)服務(wù)以及對(duì)于到達(dá)端點(diǎn)（服務(wù)）的協(xié)議相關(guān)的需求。WSDL 用抽象術(shù)語來描述服務(wù)；通過可擴(kuò)展的綁定定義，它能夠?yàn)槭褂镁唧w術(shù)語調(diào)用服務(wù)定義協(xié)議和數(shù)據(jù)格式規(guī)范。下面的語法是直接從 WSDL 規(guī)范中摘錄出來的，展示了在綁定中所包含的可擴(kuò)展性元素：

<wsdl:definitions .... >
    <wsdl:binding name="nmtoken" type="qname"> *
        <-- extensibility element (1) --> *
        <wsdl:operation name="nmtoken"> *
           <-- extensibility element (2) --> *
           <wsdl:input name="nmtoken"? > ?
               <-- extensibility element (3) --> 
           </wsdl:input>
           <wsdl:output name="nmtoken"? > ?
               <-- extensibility element (4) --> *
           </wsdl:output>
           <wsdl:fault name="nmtoken"> *
               <-- extensibility element (5) --> *
           </wsdl:fault>
        </wsdl:operation>
    </wsdl:binding>
</wsdl:definitions>

WSDL 規(guī)范（請(qǐng)參閱 參考資料部分以獲得相關(guān)鏈接）通常描述三種綁定擴(kuò)展：HTTP GET/POST、MIME 以及 SOAP version 1.1。HTTP GET/POST 和 MIME 中定義的綁定擴(kuò)展用來定義與標(biāo)準(zhǔn)的 Web 應(yīng)用程序進(jìn)行通信的需求，這些應(yīng)用程序可能返回（也可能不返回）XML 文檔。在發(fā)送或返回 XML 文檔時(shí)，HTTP GET/POST 綁定的擴(kuò)展是隱式的文檔樣式。

SOAP 綁定擴(kuò)展用來定義支持 SOAP 信封協(xié)議的服務(wù)。SOAP 信封是一種簡(jiǎn)單模式，它設(shè)計(jì)成能包含 XML 消息，提供特定于應(yīng)用程序的消息頭和消息體。SOAP 綁定的擴(kuò)展使 WSDL 文檔能夠聲明 SOAP 消息的需求，這樣應(yīng)用程序就能夠與服務(wù)正確通信。SOAP 擴(kuò)展允許將 SOAP 消息的樣式聲明為文檔或 RPC。如果在 soap:binding 元素中聲明了樣式屬性，那么該樣式將成為所有沒有顯式聲明的樣式屬性的 soap:operation 元素的缺省值。如果在 soap:binding 元素中沒有聲明樣式屬性，那么缺省的樣式就是文檔。下面是文檔樣式的顯式聲明：

<soap:binding style="document" transport="uri">

不管 soap:binding 元素中的聲明如何， soap:operation 元素可以覆蓋每個(gè)操作的聲明，就像這樣的：

<soap:operation soapAction="uri" style="document">

在聲明了文檔樣式的 SOAP 消息中，原始（as-is）或編碼（encoded）的消息被直接放置在 SOAP 信封的體部。如果樣式聲明為 RPC，消息就封裝在包裝器元素中，同時(shí)帶有從操作名屬性中提取的的元素的名稱以及從操作名稱空間屬性中提取的名稱空間。

文檔樣式的好處
勿庸置疑，使用 XML 調(diào)用跨平臺(tái)的遠(yuǎn)程過程調(diào)用的能力是非常有用的，它是使用 Web 服務(wù)的非常有說服力的理由。但是如果 Web 服務(wù)僅僅局限于 RPC 消息傳遞，這項(xiàng)技術(shù)的影響將是有限的。幸運(yùn)的是，開發(fā)人員可以選擇是使用 RPC 還是文檔樣式的消息傳遞，并且能夠使用適合的技術(shù)來完成他們面臨的任務(wù)。

使用文檔樣式，您可以充分利用 XML
XML 規(guī)范開發(fā)用來使通常鎖定于專有格式的常規(guī)數(shù)據(jù)可以以一種人易讀的、自描述的、自驗(yàn)證的開放格式來描述。當(dāng) Web 服務(wù)使用文檔消息傳遞時(shí)，它可以利用 XML 的全部能力來描述和驗(yàn)證高級(jí)業(yè)務(wù)文檔。當(dāng)服務(wù)使用 RPC 消息格式化時(shí)，XML 描述方法以及為方法調(diào)用編碼的參數(shù)，但是卻不能用來執(zhí)行高級(jí)業(yè)務(wù)規(guī)則。為了執(zhí)行這些規(guī)則，RPC 消息必須包含 XML 文檔作為字符串參數(shù)并且在被調(diào)用的方法中隱藏驗(yàn)證。出于這個(gè)原因，XML 的某些好處就喪失了，或者至少是被隱藏在后臺(tái)應(yīng)用程序里了。

文檔樣式無需嚴(yán)格的契約
使用文檔消息傳遞的另外一個(gè)原因在于，遠(yuǎn)程過程調(diào)用必須是相對(duì)靜態(tài)的，并且對(duì)接口的任何變化都將破壞服務(wù)和應(yīng)用程序之間的契約。如果服務(wù)是廣泛分布的，那么很可能大量的應(yīng)用程序已經(jīng)從它的 WSDL 文檔中產(chǎn)生了存根代碼。改變 WSDL 將會(huì)導(dǎo)致所有依賴于特定方法簽名的應(yīng)用程序被破壞，而且許多支持行產(chǎn)生問題。好的設(shè)計(jì)要求 RPC 消息服務(wù)的方法簽名不應(yīng)該改變。使用文檔消息傳遞，規(guī)則更不嚴(yán)格，并且可以使 XML 模式得到顯著增強(qiáng)和改變，同時(shí)又不會(huì)破壞調(diào)用應(yīng)用程序。

文檔樣式更適合于異步處理
當(dāng)業(yè)務(wù)使用基于 Web 的應(yīng)用程序通過 Internet 交換信息時(shí)，應(yīng)用程序應(yīng)該能夠使用有保證的交付機(jī)制來提高它的可靠性、可伸縮性和性能。為了達(dá)到這個(gè)目的，應(yīng)用程序通常將使用異步消息隊(duì)列。由于文檔消息通常是自包含的，所以它更適合于異步處理，并且可以直接放到隊(duì)列中。之所以說應(yīng)用程序的可靠性得到了提高，是因?yàn)榧词鼓繕?biāo)應(yīng)用程序當(dāng)前不是活動(dòng)的，消息隊(duì)列也可以保證消息的交付；之所以說性能得到了提高，是因?yàn)?Web 應(yīng)用程序只是把文檔發(fā)送到隊(duì)列中，然后便可以自由地執(zhí)行其他的任務(wù)；之所以說可擴(kuò)展性得到了提高，是因?yàn)槲臋n被下傳到一個(gè)或多個(gè)應(yīng)用程序的實(shí)例以進(jìn)行處理。

文檔樣式使對(duì)象交換更加靈活
業(yè)務(wù)文檔的設(shè)計(jì)通常很好地適于面向?qū)ο蟮捏w系結(jié)構(gòu)。結(jié)果，兩個(gè)應(yīng)用程序可以設(shè)計(jì)成通過使用 XML 交換對(duì)象的狀態(tài)。與對(duì)象序列化相比，在對(duì)象交換中，交換的每個(gè)端點(diǎn)都可以自由地設(shè)計(jì)它認(rèn)為合適的對(duì)象，只要交換符合達(dá)成協(xié)議的 XML 文件格式即可。不使用對(duì)象序列化的一個(gè)原因是為了支持對(duì)象在客戶端和服務(wù)器端的實(shí)現(xiàn)。許多現(xiàn)有的特定于行業(yè)的 XML 模式被設(shè)計(jì)成客戶端/服務(wù)器體系結(jié)構(gòu)，在這種體系結(jié)構(gòu)中，在客戶端上完成的處理與預(yù)定在服務(wù)器上完成的處理是分離的。通常的情況是，客戶端僅僅以服務(wù)器要求的特定文檔格式請(qǐng)求或保存信息。當(dāng)然，這種類型的交換也能用 RPC 消息完成，但是這種消息的編碼方式限制了每個(gè)端點(diǎn)上的對(duì)象的設(shè)計(jì)。在文檔樣式中就不會(huì)出現(xiàn)這些限制問題。

何時(shí)使用文檔樣式
什么時(shí)候應(yīng)該使用文檔樣式呢？簡(jiǎn)單地說：只要沒有連接到已存在的遠(yuǎn)程過程調(diào)用，任何時(shí)候都可以使用文檔方式。使用文檔方式比起通常花費(fèi)額外的工作來連接服務(wù)，好處要大得多。不過需要提醒的是：一般來說，構(gòu)建一個(gè)使用文檔消息傳遞的服務(wù)的工作量要比構(gòu)建一個(gè) RPC 消息服務(wù)所需的工作量大。這些額外的工作通常包括 XML 模式的設(shè)計(jì)或?qū)σ汛嬖诘哪Ｊ降闹С帧⒁约皬奈臋n中提取相關(guān)的信息。模式設(shè)計(jì)是重要的，因?yàn)?XML 解析器使用這個(gè)模式來驗(yàn)證文檔，支持預(yù)定的業(yè)務(wù)規(guī)則。服務(wù)需要進(jìn)行額外的工作來從文檔中提取用于處理請(qǐng)求的相關(guān)信息。相比之下，RPC 消息只需要設(shè)計(jì)方法的接口，通過方法的接口，RPC 消息就可以自動(dòng)地編組和解組參數(shù)。

當(dāng)您決定發(fā)布一項(xiàng)服務(wù)時(shí)，您可能應(yīng)該考慮下列問題。我將在下面的部分中分析您的答案的結(jié)果。

• 這項(xiàng)服務(wù)是連接到已存在的過程調(diào)用，并且這個(gè)過程調(diào)用是無狀態(tài)的嗎？
• 這項(xiàng)服務(wù)是僅在您的組織內(nèi)部使用，還是也可以被外部用戶所使用？
• 參數(shù)之一僅僅是 XML 文檔規(guī)范嗎？
• 這項(xiàng)服務(wù)需要請(qǐng)求/響應(yīng)體系結(jié)構(gòu)嗎？
• 參數(shù)表示了可以從用于驗(yàn)證的 XML 文檔模式受益的復(fù)雜結(jié)構(gòu)嗎？
• 所有需要進(jìn)行交換的信息都能夠合理地存放在內(nèi)存中嗎？

在維護(hù)應(yīng)用程序狀態(tài)時(shí)使用文檔樣式
如果必須以特定的順序調(diào)用多個(gè)過程來維護(hù)應(yīng)用程序狀態(tài)，您應(yīng)該考慮在您的服務(wù)中使用文檔體系結(jié)構(gòu)。如果需要多個(gè)過程調(diào)用，那么過程就不是無狀態(tài)的，并且服務(wù)必須維護(hù)應(yīng)用程序狀態(tài)。在 Web 服務(wù)中維護(hù)狀態(tài)可能是困難的；在遠(yuǎn)程過程調(diào)用的情況下，很少有客戶端平臺(tái)會(huì)產(chǎn)生能夠支持狀態(tài)信息的存根代碼。一個(gè)可能的解決方案是使用文檔體系結(jié)構(gòu)，并在文檔內(nèi)部傳送整個(gè)事務(wù)的內(nèi)容。在這種情況下，服務(wù)將執(zhí)行調(diào)用，以確保服務(wù)內(nèi)部保持正確的順序，并且狀態(tài)信息的維護(hù)不超出單個(gè)事務(wù)的范圍。如果仍然需要狀態(tài)信息，可以將狀態(tài)信息記錄在最終得到的文檔中，客戶端應(yīng)用程序也可以維護(hù)一個(gè)用于服務(wù)識(shí)別它的狀態(tài)的令牌。

使用文檔樣式來發(fā)布可供外部伙伴使用的服務(wù)
如果一個(gè)應(yīng)用程序被發(fā)布到組織以外，發(fā)布者就很難控制誰正依賴于這個(gè)服務(wù)，以及如果做出任何改動(dòng)后果會(huì)怎樣。在這種情況下，使用文檔消息傳遞和支持像 ebXML 這樣的通用交換協(xié)議可能更加有利。通用交換協(xié)議正發(fā)展成能改善外部交換的管理，因此新的貿(mào)易合作伙伴協(xié)定就可以快速地部署。同樣，如果您的服務(wù)不需要請(qǐng)求/響應(yīng)體系結(jié)構(gòu)，那么通用交換協(xié)議就可以更好地設(shè)計(jì)來處理認(rèn)證、可靠消息交付以及異步請(qǐng)求/響應(yīng)。

使用文檔樣式來簡(jiǎn)化復(fù)雜文檔的驗(yàn)證和使用
如果您的服務(wù)正使用字符串參數(shù)來傳遞或返回 XML 文檔，或者它的參數(shù)之一是一個(gè)具有復(fù)雜結(jié)構(gòu)且需要自定義處理的對(duì)象，那么文檔消息傳遞就可能是較好的選擇。將參數(shù)的真實(shí)含義隱藏在字符串里經(jīng)常會(huì)導(dǎo)致帶有無效參數(shù)的有效調(diào)用。如果服務(wù)發(fā)布了 XML 文檔模式，那么在調(diào)用服務(wù)之前根據(jù)這個(gè)模式進(jìn)行驗(yàn)證就會(huì)更加容易。復(fù)雜結(jié)構(gòu)經(jīng)常用來傳遞組成完整事務(wù)的數(shù)百條信息。在處理復(fù)雜的結(jié)構(gòu)時(shí)，遠(yuǎn)程過程服務(wù)可能不得不處理自定義的編組代碼，同時(shí)應(yīng)用程序仍然負(fù)責(zé)仔細(xì)地驗(yàn)證結(jié)構(gòu)的每個(gè)元素。如果使用文檔消息傳遞，那么應(yīng)用程序程序員就可以使用 XML 模式來將驗(yàn)證下傳到文檔設(shè)計(jì)器，并且不需要自定義的編組代碼。

使用文檔樣式來最小化內(nèi)存中的處理
在選擇使用文檔樣式的消息傳遞還是 RPC 樣式的消息傳遞時(shí)，需要考慮的最后一個(gè)因素是需要處理的信息量大小。由于采用 RPC 樣式的消息傳遞來編組參數(shù)的大部分（如果不是全部的話）實(shí)現(xiàn)都是在內(nèi)存中執(zhí)行這項(xiàng)操作，所以內(nèi)存約束可能會(huì)使得 RPC 消息傳遞行不通。許多文檔消息傳遞服務(wù)能夠選擇是用 DOM 還是用 SAX 來處理文檔，因而能夠最小化內(nèi)存中的處理。這對(duì)于 Web 服務(wù)尤為關(guān)鍵，因?yàn)樗赡苄枰幚沓汕先f的請(qǐng)求，而且其中許多是同時(shí)發(fā)生的。

結(jié)束語
在您設(shè)計(jì)下一個(gè) Web 服務(wù)時(shí)，您需要考慮當(dāng)前的 WSDL 規(guī)范為您提供的所有選擇。在開始創(chuàng)建過程性的接口之前，考慮好將如何使用服務(wù)，誰將使用它，以及需要交換的數(shù)據(jù)的類型和數(shù)量。設(shè)計(jì)開發(fā)文檔樣式的 Web 服務(wù)可能需要稍多一些的工作量，但是在很多情況下，這些額外的工作量將會(huì)換取更高的信息質(zhì)量和更可靠的交換性能。

參考資料

• 您可以參閱本文在 developerWorks 全球站點(diǎn)上的 英文原文.
  
  
• Bilal Siddiqui 撰寫的“ Deploying Web services with WSDL”（developerWorks，2001 年 11 月）很好地介紹了 Web 服務(wù)和 Web 服務(wù)描述語言（Web Services Description Language）。
  
  
• 參閱 WSDL和 SOAP 規(guī)范。
  
  
• XMethods 站點(diǎn)托管一個(gè)使用文檔樣式構(gòu)建的 demo Web 服務(wù)。
  
  
• IBM 的 WebSphere支持 Web 服務(wù)。
  
  
• 參閱 IBM 最新的 Web Services initiative。