理解SOAP (一)介紹、SOAP 版本、
日期：2003－03<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />
適用於：全域性XML Web 服務架構(GXA)
遠端過程呼叫（RPC）
SOAP 1.1 SOAP 1.2 規範
傳輸協議：TCP, HTTP, SMTP, 和 MSMQ
Microsoft® .NET Web Services Enhancements 1.0 SP1
XML Schema
摘要
SOAP在分佈異構環境中提供一種簡單，可擴充套件，和豐富的XML訊息框架（messaging framework）,對定義高層的應用協議提供更強的互操作性（
內容
介紹
SOAP 版本
訊息框架
擴充套件性
處理模型
協議繫結
HTTP 繫結
RPC 與編碼
SOAP 樣式
總結
介紹
在昨天SOAP好像只不過是一種清潔產品。現在大多數開發者無法理解沒有尖括號的資訊（can't hear the word without seeing angle brackets.譯註：我理解成現在資料大多以XML表現）。SOAP最初代表" 簡單物件訪問協議"。如果你幾年以前問人詢問SOAP的意思，他們會或許說“在internet上與DCOM 和 Corba (如 RPC 呼叫)做類似工作”。它的原作者們承認他們集中於“物件訪問”然後返回，隨著時間發展，使
焦點的變化在縮寫詞SOAP的字母’O’上產生了一個細微的問題。有趣的是，SOAP1.2工作組仍保留(迄今) SOAP這個名字(它太應用的太普遍，很難改變它)，但是決定依靠（against）清楚地說明來避免誤解開發者。最新的SOAP1.2規範中正式的SOAP定義，甚至沒有涉及物件：
|
SOAP是一種在分散，分佈環境中用來交換結構化資訊的輕量級協議。SOAP使用XML 技術來定義一個可擴充套件的訊息框架，這個訊息框架提供了一個能在多種下層（underlying）協議上進行交換的訊息構造。框架被設計成獨立於任何特定的程式設計模型和其他實現的具體語義。 |
現在，這個定義真正的描敘了SOAP的實質。SOAP定義了一個方法來將XML訊息從A點傳送到B點（見圖1）。這是靠SOAP提供了一個基於XML的訊息框架，它有以下幾個特點：
①可擴充套件（extensible）
②能使用多種下層網路協議
③獨立於程式設計模型
現在來依次討論這三個特點的更多細節。
<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />
圖1.簡單SOAP訊息
首先，SOAP的關鍵是可擴充套件性（extensibility）。當SOAP代表一些東西的時候，“S”意為“簡單（Simple）”。如果有一件事我們能從web上學到，那就是簡單（Simplicity）總能爭取(wins over)效率或工業純度(technical purity)。而且當互操作性處於得失攸關（at stake）時，簡單就是絕對的需要。SOAP缺乏多種分散式系統的特點，如安全、路徑選擇和命名一些可靠性，印證了SOAP保持了最初設計目標――簡單。SOAP定義了一個通訊框架來允許這些特點作為分層擴充套件加進來（to be added down the road as layered extensions）。Microsoft 、IBM 和其他軟體商正積極著手於一套通用的SOAP擴充套件，它將增加大多數開發者期望的一些特點。初始階段作為全域性XML Web 服務架構(GXA)而涉及。Microsoft已經發佈一個GXA規範的參考實現，並稱為Microsoft® .NET Web Services Enhancements 1.0 SP1。
其次，SOAP能夠基於任何傳送協議使用，例如TCP，HTTP，SMTP甚至MSMQ(參閱圖1)。不過，為了保持互操作性需要定義標準協議繫結來略述（outline）適合每個環境的規定(rule)。SOAP規範提供一個靈活的框架來定義任意的協議繫結，而且，因為HTTP協議已被廣泛使用，現在已經明確定義了一個HTTP協議的繫結。
第三，SOAP允許任何程式設計模型並且並不依賴RPC。實際上，大多數開發者直接將SOAP等同於在分散式物件上使用RPC呼叫（因為最初SOAP是關於“訪問物件”），基本的SOAP模型象MSMQ一樣更近似於傳統訊息系統。SOAP定義了一個單獨處理的單向訊息模型。你可以將多條訊息合併成一個整體資訊進行交換。圖1 說明了一條簡單的傳送者接收不到response的單向訊息，不過，接收者可以把response發回給傳送人(參閱圖2)。SOAP允許任意數量的訊息交換模式(message exchange patterns －MEPs)，每個訊息交換模式的request/response僅僅只有一個。其他例子包括solicit/reponse( 和request/reponse相反)，通知，和長時間執行的點對點會話（peer-to-peer conversations）。
圖2. Request/response 訊息交換模式
開發者經常將request/response與RPC相混淆，而實際上它們非常不同。RPC使用請求/反應，但是請求/反應不一定是RPC必需的。RPC是允許開發者與方法呼叫合作的一種程式設計模型。RPC需要一個方法簽名到SOAP訊息的轉換。由於RPC的普及性，SOAP略述了一個以SOAP來使用RPC的協定（見下文的RPC 和編碼這一部分）。
有了這三大特徵，SOAP訊息框架就能在異構的環境中方便的傳送XML訊息了，而互操作性在這些異構的環境中早就是一個挑戰了。
SOAP 版本
從最初發布SOAP規範對今天的廣泛實現的SOAP1.1，很多東西已經改變，從小的細節到主要的思想變化。SOAP1.1被提交到W3C，並在2000年5月返回作為備忘錄（note）釋出。 "W3C 備忘錄（Note）"狀態使得 SOAP 1.1 僅僅是一個好的想法，因為它還沒有通過W3C的嚴格程式，在這個程式中它會最終達到實現的“建議書（Recommendation）”狀態。雖然如此，現在在如此廣泛的大或小的應用提供商支援下，SOAP1.1仍然被認為為實際上的標準。
W3C使用SOAP1.1建議書作為原本（seed）來讓一個新的XML 協議工作組負責生成下一個SOAP版本，目前命名為SOAP1.2。在目前，SOAP1.2是"候選建議書"，這表明它在實現階段內而且離完成不遠。一旦SOAP1.2 成為"建議書" ，它可能會迅速得到應用提供商的支援。
在SOAP1.2 實現之後，應用提供商會為向後相容而繼續支援SOAP1.1。SOAP版本化（versioning）是基於XML 名稱空間。SOAP 1.1對應於http://schemas.xmlsoap.org/soap/envelope 名稱空間，而SOAP 1.2對應於http://www.w3.org/2002/12/soap-envelope 名稱空間（儘管在它成為建議書時會有改變）。
參閱表格1來快速參考每個名稱空間的名字和規範的位置。在整個餘下的文章中，我們將覆蓋SOAP中最重要的地方。在兩個版本的廣泛的變更列表中檢查當前的SOAP 1.2規範。
表1.SOAP版本資訊
SOAP 1.1
名稱空間名字
http://schemas.xmlsoap.org/soap/envelope/
規範位置
SOAP 1.2
名稱空間名字
http://www.w3.org/2002/12/soap-envelope
規範位置