SOAP 1.2 與 GET 請求 SOAP 1.2 帶來的變化進一步把 Web 服務編織到 Internet 的大網(wǎng)中。變化之一是 GET 方法的引入。GET 之所以重要是因為它支持各種優(yōu)化。這一點已經(jīng)過 Web 自身的驗證，它廣泛地使用 GET 方法。通過本技巧可以進一步了解這一點。 SOAP 1.0

SOAP 1.2 與 GET 請求

SOAP 1.2 帶來的變化進一步把 Web 服務編織到 Internet 的大網(wǎng)中。變化之一是 GET 方法的引入。GET 之所以重要是因為它支持各種優(yōu)化。這一點已經(jīng)過 Web 自身的驗證，它廣泛地使用 GET 方法。通過本技巧可以進一步了解這一點。

SOAP 1.0 發(fā)布以來，很多人曾經(jīng)抱怨它對 HTTP POST 方法的依賴。許多人認為 SOAP 利用了一種流行的協(xié)議（HTTP），但一點也沒有考慮和理解建立在其上的體系結構。

W3C 主持開發(fā)的 1.2 版本解決了這一問題。W3C 曾經(jīng)在抽象該協(xié)議的許多方面花費了大力氣，更容易通過各種不同的技術使用該協(xié)議。通過修訂，SOAP 1.2 除了 HTTP 之外還支持 SMTP，并能更好的利用 HTTP。

關于 POST 方法

POST 有什么問題呢？簡而言之，HTTP 定義了與服務器交互的不同方法，最基本的方法是 GET 和 POST。事實上 GET 適用于多數(shù)請求，而保留 POST 僅用于更新站點。根據(jù) HTTP 規(guī)范，GET 用于信息獲取，而且應該是 安全的和 冪等的。

在這里，所謂 安全的意味著該操作用于獲取信息而非修改信息。換句話說，GET 請求一般不應產(chǎn)生副作用。冪等的意味著對同一 URL 的多個請求應該返回同樣的結果。完整的定義并不像看起來那樣嚴格。從根本上講，其目標是當用戶打開一個鏈接時，她可以確信從自身的角度來看沒有改變資源。

比如，新聞站點的頭版不斷更新。雖然第二次請求會返回不同的一批新聞，該操作仍然被認為是安全的和冪等的，因為它總是返回當前的新聞。反之亦然。

POST 請求就不那么輕松了。POST 表示可能改變服務器上的資源的請求。仍然以新聞站點為例，讀者對文章的注解應該通過 POST 請求實現(xiàn)，因為在注解提交之后站點已經(jīng)不同了（比方說文章下面出現(xiàn)一條注解）。

GET 與 POST 之間的區(qū)別并不總是那么嚴格，也存在一些共性。許多站點在 POST 請求中封裝了簡單的信息獲取，可能是因為開發(fā)人員認為這樣對他來說更簡單。

盡管關于 HTTP 方法的討論看起來似乎是抽象的和理論性的，但并非如此。瀏覽器和中介軟件（代理、防火墻和內(nèi)容提交解決方案 laAkamai）根據(jù)區(qū)分不同請求能力來獲得優(yōu)化的性能（請參閱 參考資料）。

SOAP 結盟 GET

SOAP 最初只支持 POST 請求。Web 服務仍然能夠?qū)崿F(xiàn)上述定義的安全服務。比如，查詢訂單進展情況的服務既是安全的也是冪等的。根據(jù) HTTP 規(guī)范，它應該作為 GET 請求實現(xiàn)。而根據(jù) SOAP 1.0 則必須使用 POST。

SOAP 1.2 引入了消息交換模式（Message Exchange Patterns，MEPs）和一種新的 HTTP 綁定。兩者相結合就能實現(xiàn)答復 GET 請求的 Web 服務。MEP 描述了客戶和服務器之間的交互模式。SOAP Request-Response MEP 是一種典型的 Web 服務交互：客戶向服務器發(fā)出請求，服務器應答。

我將在這里進一步考察 SOAP Response MEP。MEP 只定義了一個響應而沒有請求。在實踐中，這意味著請求已經(jīng)發(fā)出，但不是 SOAP 請求，只有響應是 SOAP。當與新的 HTTP 請求結合時，Response MEP 就可以支持 GET 請求。其工作原理如下：

* 客戶發(fā)出 GET 請求。它把 Accept 頭設為 application/soap+xml ，以便請求一個 SOAP 答復。

* 服務器答復，客戶將響應作為正常的 SOAP 響應處理。

服務器通過 Accept 頭區(qū)分 SOAP 請求和常規(guī)的 HTML 請求?？蛻艨梢栽?Accept 中使用 q 屬性設置不同的 content/type 表明自己的參數(shù)選擇。

根據(jù)服務的需要，客戶可以通過一般的 URL 編碼方法（通常放在 ? 字符后）在 URL 中包含參數(shù)。比如，報告服務器場狀態(tài)的服務可能不需要任何參數(shù)。按照定義，它返回當前服務器的狀態(tài)。相反，報告產(chǎn)品可用性和價格的服務就需要產(chǎn)品標識符（或者名稱）作為參數(shù)。

現(xiàn)在您可能迷惑客戶如何知道調(diào)用哪個 URL 以及傳遞哪個參數(shù)，因為請求并不是 SOAP 的一部分。答案很簡單：SOAP 服務器應該完成常規(guī) Web 服務器所做的工作，并在上一次交互中包含該 URL。沒有什么妨礙 GET 與 POST 的混合與匹配。

作為一個例子，想象一個處理辦公用品（筆、紙、剪刀等等）訂單的服務。該服務通過 SOAP 接收訂單，顯然這樣的請求既不是安全的也不是冪等的，因此作為 POST 發(fā)出。服務器的響應可以包含一個 URL 來跟蹤訂單的處理過程。跟蹤是安全的和冪等的，因此最好通過 GET 來實現(xiàn)。

Web 背后的簡單原理已經(jīng)證明了自身的靈活性與可靠性。作為 Web 服務中最重要的標準之一，SOAP 與這種取得非凡成功的體系結構的更密切結合，這是一種非常積極的進展。

在等待所青睞的工具包升級到 SOAP 1.2 和 WSDL 2.0 之前，先檢查一下您的 Web 服務，識別出那些遷移到 GET 綁定時作為首要目標的安全操作。

SOAP 1.2

從編程模型的角度而言，SOAP 1.1 和 SOAP 1.2 之間并沒有太多的差異。作為 Java 程序員，您只會在使用處理程序時遇到這些差異，我們將在以后的技巧文章中對如何處理這種情況進行討論。SAAJ 1.3 已更新以支持 SOAP 1.2。

XML/HTTP

與 SOAP 1.2 的更改類似，從編程模型的角度而言，SOAP/HTTP 和 XML/HTTP 消息之間并沒有太多的差異。作為 Java 程序員，您只會在使用處理程序時遇到這些差異，我們將在以后的技巧文章中對如何處理這種情況進行討論。HTTP 綁定具有自己的處理程序鏈和自己的一組消息上下文屬性。

WS-I Basic Profiles

JAX-RPC 1.1 支持 WS-I Basic Profile (BP) 1.0。從那時起，WS-I 人員就完成了 BP 1.1（以及關聯(lián)的 AP 1.0 和 SSBP 1.0）的開發(fā)。這些新概要闡明了一些小要點，更明確地定義了附件。JAX-WS 2.0 支持這些較新的概要。在大部分情況下，其間的差異并不會影響 Java 編程模型。不過附件除外。WS-I 不僅處理了有關附件的一些問題，而且還定義了自己的 XML 附件類型：wsi:swaRef。

很多人都被這些概要搞糊涂了。為了弄清楚其間的問題，將需要了解一下其相關歷史。

WS-I 的第一個基本概要 (BP 1.0) 在闡明各個規(guī)范方面做得非常不錯，但它并不完美。尤其對 SOAP with Attachments (Sw/A) 的支持仍然相當不明確。在第二個工作循環(huán)中，WS-I 人員將附件從基本概要 (BP 1.1) 中分離出來，并對第一版中一些沒有討論的內(nèi)容進行了補充。當時他們還添加了兩個互不包括的基本概要補充文檔：AP 1.0 和 SSBP 1.0。AP 1.0 是附件概要 (Attachment Profile)，描述如何使用 Sw/A。SSBP 1.0 是簡單 SOAP 綁定概要 (Simple SOAP Binding Profile)，描述并不支持 Sw/A 的 Web 服務引擎（如 Microsoft 的 .NET）。WS-I 所提供的其他概要文件都是以這些基本概要文件為基礎構建的。

Java 5

對 Java 語言進行了一系列更改。JAX-WS 依賴于：Annotation、通用函數(shù)和執(zhí)行程序。我們將在后續(xù)的技巧文章中具體討論 JAX-WS 如何依賴于這個新功能。有關 Java 的這些新功能的信息，請參見參 考資料中的 Java 5 鏈接。

總結

JAX-WS 2.0 是 JAX-RPC 1.1 的后續(xù)版本。其中有些內(nèi)容保持不變，但大部分編程模型都或多或少有些不同。本技巧文章中介紹的主題將在一系列技巧文章中展開討論，這個系列的文章對 JAX-WS 和 JAX-RPC 間的區(qū)別進行了詳細的討論，我們將在隨后的數(shù)月中陸續(xù)發(fā)布。大致看來，可能會因為以下這些原因而決定從 JAX-RPC 遷移到 JAX-WS，或保持不變。

希望繼續(xù)使用 JAX-RPC 1.1 的原因：

• 如果您希望繼續(xù)使用現(xiàn)有的東西，JAX-RPC 將在今后一段時間內(nèi)繼續(xù)得到支持。
• 如果您不希望升級到 Java 5。
• 如果您希望發(fā)送采用 SOAP 編碼的消息或創(chuàng)建 RPC/encoded 樣式的 WSDL。

升級到 JAX-WS 2.0 的原因：

• 如果您希望使用新的面向消息的 API。
• 如果您希望使用 MTOM 發(fā)送附件數(shù)據(jù)。
• 如果您希望通過 JAXB 更好地支持 XML 模式。
• 如果您希望在 Web 服務客戶機中采用異步編程模型。
• 如果您需要使用能夠處理 SOAP 1.2 消息的客戶機或服務。
• 如果您希望在 Web 服務中消除對 SOAP 的需求，而直接使用 XML/HTTP 綁定。
• 如果您喜歡使用領先的尖端技術。