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

SOAP 1.2 與 GET 請求

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

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

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

關(guān)于 POST 方法

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

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

比如，新聞?wù)军c(diǎn)的頭版不斷更新。雖然第二次請求會(huì)返回不同的一批新聞，該操作仍然被認(rèn)為是安全的和冪等的，因?yàn)樗偸欠祷禺?dāng)前的新聞。反之亦然。

POST 請求就不那么輕松了。POST 表示可能改變服務(wù)器上的資源的請求。仍然以新聞?wù)军c(diǎn)為例，讀者對文章的注解應(yīng)該通過 POST 請求實(shí)現(xiàn)，因?yàn)樵谧⒔馓峤恢笳军c(diǎn)已經(jīng)不同了（比方說文章下面出現(xiàn)一條注解）。

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

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

SOAP 結(jié)盟 GET

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

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

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

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

* 服務(wù)器答復(fù)，客戶將響應(yīng)作為正常的 SOAP 響應(yīng)處理。

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

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

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

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

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

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

SOAP 1.2

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

XML/HTTP

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

WS-I Basic Profiles

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

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

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

Java 5

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

總結(jié)

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

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

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

升級(jí)到 JAX-WS 2.0 的原因：

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