盡管是轉載的，但是原文中幾處錯誤或者不規范的表達，我已經進行了修改。
大部分 Web 服務都是圍繞著遠程過程調用而構建的，而 WSDL 規范允許另外一種 Web 服務體系結構：文檔樣式（ document style ）。在該體系結構中，整個文檔在服務客戶端和服務器之間進行交換。在本文中， James McCarthy 將向您解釋文檔樣式以及應該何時使用它。
在 Web 服務描述語言（ Web Service Definition Language ， WDSL ）規范中隱含著一個非常巧妙的轉換開關，它可以將 Web 服務的 SOAP 綁定從遠程過程調用轉換成 pass-through 文檔。在 SOAP 協議綁定中的樣式屬性可以包含這兩個值中的一個： rpc 或 document 。當屬性被設定為文檔樣式時，客戶端知道應該使用 XML 模式而不是遠程過程調用約定。本文將提供對這個 WSDL 轉換開關的說明，描述它的好處，并將解釋應該何時使用 pass-through 文檔。
首先，讓我們簡要地談談 WSDL 的一些要點，來理解這個巧妙的轉換是如何發生的。 WSDL 是一項 XML 規范，它被用來描述Web服務以及對于到達端點（服務）的協議相關的需求。 WSDL 用抽象術語來描述服務；通過可擴展的綁定定義，它能夠為使用具體術語調用服務定義協議和數據格式規范。下面的語法是直接從 WSDL 規范中摘 錄出來的，展示了在綁定中所包含的可擴展性元素：
|
<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 規范通常描述三種綁定擴展： HTTP GET/POST 、 MIME 以及 SOAP version 1.1 。 HTTP GET/POST 和 MIME 中定義的綁定擴展用來定義與標準的 Web 應用程序進行通信的需
求，這些應用程序可能返回（也可能不返回） XML 文檔。在發送或返回 XML 文檔時， HTTP GET/POST 綁定的擴展是隱式的文檔樣式。
SOAP 綁定擴展用來定義支持 SOAP 信封協議的服務。 SOAP 信封是一種簡單模式，它設計成能包含 XML 消息，提供特定于應用程序的消息頭和消息體。 SOAP 綁定的擴展使 WSDL 文檔能夠聲明 SOAP 消息的需求，這樣應用程序就能夠與服務正確通信。 SOAP 擴展允許將 SOAP 消息的樣式聲明為文檔或 RPC 。如果在 soap:binding 元素中聲明了樣式屬性，那么該樣式將成為所有沒有顯式聲明的樣式屬性的 soap:operation 元素的缺省值。如果在 soap:binding 元素中沒有聲明樣式屬性，那么缺省的樣式就是文檔。下面是文檔樣式的顯式聲明：
|
<soap:binding style="document" transport="uri"> |
不管 soap:binding 元素中的聲明如何， soap:operation 元素可以覆蓋每個操作的聲明，就像這樣的：
|
<soap:operation soapAction="uri" style="document"> |
在聲明了文檔樣式的 SOAP 消息中，原始（ as-is ）或編碼（ encoded ）的消息被直接放置在 SOAP 信封的體部。
如果樣式聲明為 RPC ，消息就封裝在包裝器元素中，同時帶有從操作名屬性中提取的的元素的名稱以及從操作名稱空間屬性中提取的名稱空間。
勿庸置疑，使用 XML 調用跨平臺的遠程過程調用的能力是非常有用的，它是使用 Web 服務的非常有說服力的理由。但是如果 Web 服務僅僅局限于 RPC 消息傳遞，這項技術的影響將是有限的。幸運的是，開發人員可以選擇是使用 RPC 還是文檔樣式的消息傳遞，并且能夠使用適合的技術來完成他們面臨的任務。
XML 規范開發用來使通常鎖定于專有格式的常規數據可以以一種人易讀的、自描述的、自驗證的開放格式來描述。當 Web 服務使用文檔消息傳遞時，它可以利用 XML 的全部能力來描述和驗證高級業務文檔。當服務使用 RPC 消息格式化時， XML 描述方法以及為方法調用編碼的參數，但是卻不能用來執行高級業務規則。為了執行這些規則， RPC 消息必須包含 XML 文檔作為字符串參數并且在被調用的方法中隱藏驗證。出于這個原因， XML 的某些好處就喪失了，或者至少是被隱藏在后臺應用程序里了。
使用文檔消息傳遞的另外一個原因在于，遠程過程調用必須是相對靜態的，并且對接口的任何變化都將破壞服務和應用程序之間的契約。如果服務是廣泛分布的，那么很可能大量的應用程序已經從它的 WSDL 文檔中產生了存根代碼。改變 WSDL 將會導致所有依賴于特定方法簽名的應用程序被破壞，而且許多支持行產生問題。好的設計要求 RPC 消息服務的方法簽名不應該改變。使用文檔消息傳遞，規則更嚴格，并且可以使 XML 模式得到顯著增強和改變，同時又不會破壞調用應用程序。
當業務使用基于 Web 的應用程序通過 Internet 交換信息時，應用程序應該能夠使用有保證的交付機制來提高它的可靠性、可伸縮性和性能。為了達到這個目的，應用程序通常將使用異步消息隊列。由于文檔消息通常是自包含的，所以它更適合于異步處理，并且可以直接放到隊列中。之所以說應用程序的可靠性得到了提高，是因為即使目標應用程序當前不是活動的，消息隊列也可以保證消息的交付；之所以說性能得到了提高，是因為 Web 應用程序只是把文檔發送到隊列中，然后便可以自由地執行其他的任務；之所以說可擴展性得到了提高，是因為文檔被下傳到一個或多個應用程序的實例以進行處理。
業務文檔的設計通常很好地適于面向對象的體系結構。結果，兩個應用程序可以設計成通過使用 XML 交換對象的狀態。與對象序列化相比，在對象交換中，交換的每個端點都可以自由地設計它認為合適的對象，只要交換符合達成協議的 XML 文件格式即可。不使用對象序列化的一個原因是為了支持對象在客戶端和服務器端的實現。許多現有的特定于行業的 XML 模式被設計成客戶端 / 服務器體系結構，在這種體系結構中，在客戶端上完成的處理與預定在服務器上完成的處理是分離的。通常的情況是，客戶端僅僅以服務器要求的特定文檔格式請求或保存信息。當然，這種類型的交換也能用 RPC 消息完成，但是這種消息的編碼方式限制了每個端點上的對象的設計。在文檔樣式中就不會出現這些限制問題。
什么時候應該使用文檔樣式呢？簡單地說：只要沒有連接到已存在的遠程過程調用，任何時候都可以使用文檔方式。使用文檔方式比起通常花費額外的工作來連接服務，好處要大得多。不過需要提醒的是：一般來說，構建一個使用文檔消息傳遞的服務的工作量要比構建一個 RPC 消息服務所需的工作量大。這些額外的工作通常包括 XML 模式的設計或對已存在的模式的支持、以及從文檔中提取相關的信息。模式設計是重要的，因為 XML 解析器使用這個模式來驗證文檔，支持預定的業務規則。服務需要進行額外的工作來從文檔中提取用于處理請求的相關信息。相比之下， RPC 消息只需要設計方法的接口，通過方法的接口， RPC 消息就可以自動地編組和解組參數。
當您決定發布一項服務時，您可能應該考慮下列問題。我將在下面的部分中分析您的答案的結果。
- 這項服務是連接到已存在的過程調用，并且這個過程調用是無狀態的嗎？
- 這項服務是僅在您的組織內部使用，還是也可以被外部用戶所使用？
- 參數之一僅僅是 XML 文檔規范嗎？
- 這項服務需要請求 / 響應體系結構嗎？
- 參數表示了可以從用于驗證的 XML 文檔模式受益的復雜結構嗎？
- 所有需要進行交換的信息都能夠合理地存放在內存中嗎？
如果必須以特定的順序調用多個過程來維護應用程序狀態，您應該考慮在您的服務中使用文檔體系結構。如果需要多個過程調用，那么過程就不是無狀態的，并且服務必須維護應用程序狀態。在 Web 服務中維護狀態可能是困難的；在遠程過程調用的情況下，很少有客戶端平臺會產生能夠支持狀態信息的存根代碼。一個可能的解決方案是使用文檔體系結構，并在文檔內部傳送整個事務的內容。在這種情況下，服務將執行調用，以確保服務內部保持正確的順序，并且狀態信息的維護不超出單個事務的范圍。如果仍然需要狀態信息，可以將狀態信息記錄在最終得到的文檔中，客戶端應用程序也可以維護一個用于服務識別它的狀態的令牌。
如果一個應用程序被發布到組織以外，發布者就很難控制誰正依賴于這個服務，以及如果做出任何改動后果會怎樣。在這種情況下，使用文檔消息傳遞和支持像 ebXML 這樣的通用交換協議可能更加有利。通用交換協議正發展成能改善外部交換的管理，因此新的貿易合作伙伴協定就可以快速地部署。同樣，如果您的服務不需要請求 / 響應體系結構，那么通用交換協議就可以更好地設計來處理認證、可靠消息交付以及異步請求 / 響應。
如果您的服務正使用字符串參數來傳遞或返回 XML 文檔，或者它的參數之一是一個具有復雜結構且需要自定義處理的對象，那么文檔消息傳遞就可能是較好的選擇。將參數的真實含義隱藏在字符串里經常會導致帶有無效參數的有效調用。如果服務發布了 XML 文檔模式，那么在調用服務之前根據這個模式進行驗證就會更加容易。復雜結構經常用來傳遞組成完整事務的數百條信息。在處理復雜的結構時，遠程過程服務可能不得不處理自定義的編組代碼，同時應用程序仍然負責仔細地驗證結構的每個元素。如果使用文檔消息傳遞，那么應用程序程序員就可以使用 XML 模式來將驗證下傳到文檔設計器，并且不需要自定義的編組代碼。
擇使用文檔樣式的消息傳遞還是 RPC 樣式的消息傳遞時，需要考慮的最后一個因素是需要處理的信息量大小。由于采用 RPC 樣式的消息傳遞來編組參數的大部分（如果不是全部的話）實現都是在內存中執行這項操作，所以內存約束可能會使得 RPC 消息傳遞行不通。許多文檔消息傳遞服務能夠選擇是用 DOM 還是用 SAX 來處理文檔，因而能夠最小化內存中的處理。這對于 Web 服務尤為關鍵，因為它可能需要處理成千上萬的請求，而且其中許多是同時發生的。
在您設計下一個 Web 服務時，您需要考慮當前的 WSDL 規范為您提供的所有選擇。在開始創建過程性的接口之前，考慮好將如何使用服務，誰將使用它，以及需要交換的數據的類型和數量。設計開發文檔樣式的 Web 服務可能需要稍多一些的工作量，但是在很多情況下，這些額外的工作量將會換取更高的信息質量和更可靠的交換性能。