簡介
SOAP（SOAP：Simple Object Access Protocol）
簡單對象訪問協定（SOAP）是一種輕量的、簡單的、基於 XML 的協定，它被設計成在 WEB 上交換結構化的和固化的信息。 SOAP 可以和現存的許多網際網路協定和格式結合使用，包括超文本傳輸協定（ HTTP），簡單郵件傳輸協定（SMTP），多用途網際郵件擴充協定（MIME）。它還支持從訊息系統到遠程過程調用（RPC）等大量的應用程式。
SOAP 包括三個部分：
SOAP 封裝：它定義了一個框架 , 該框架描述了訊息中的內容是什麼，誰應當處理它以及它是可選的還是必須的。
SOAP 編碼規則：它定義了一種序列化的機制，用於交換應用程式所定義的數據類型的實例。
SOAP RPC 表示：它定義了用於表示遠程過程調用和應答的協定。
SOAP 訊息基本上是從傳送端到接收端的單向傳輸，但它們常常結合起來執行類似於請求 / 應答的模式。所有的 SOAP 訊息都使用 XML 編碼。一條 SOAP 訊息就是一個包含有一個必需的 SOAP 的封裝包，一個可選的 SOAP 標頭和一個必需的 SOAP 體塊的 XML 文檔。
把 SOAP 綁定到 HTTP 提供了同時利用 SOAP 的樣式和分散的靈活性的特點以及 HTTP 的豐富的特徵庫的優點。在 HTTP 上傳送 SOAP 並不是說 SOAP 會覆蓋現有的 HTTP 語義，而是 HTTP 上的 SOAP 語義會自然的映射到 HTTP 語義。在使用 HTTP 作為協定綁定的場合中， RPC 請求映射到 HTTP 請求上，而 RPC 應答映射到 HTTP 應答。然而，在 RPC 上使用 SOAP 並不僅限於 HTTP 協定綁定。
歷史
SOAP曾經代表“SimpleObjectAccessProtocol”，但是這種縮寫已經在標準的1.2版後被廢止了。1.2版在2003年6月24日成為W3C的推薦版本。這種縮寫容易與SOA——Service-orientedarchitecture產生歧義，雖然它們之間存在非常大的差異。
SOAP由DaveWiner,DonBox，BobAtkinson,MohsenAl-Ghosein於1998年設計，當時只作為一種對象訪問協定。現在，SOAP規範由全球資訊網聯盟的XML工作組維護。
訊息格式
SOAP在標準化訊息格式環境中，可以做所有它能完成的工作。訊息的主體部分 是“text/xml”形式的MIME類型，並且包含一個SOAP封套。該封套是一個XML文 檔。封套包含了報頭（可選的）和報文（必須有的）。封套的報文部分總是用於 最終接收的訊息，而報頭項目可以確定執行中間處理的目標節點。附屬檔案、二進制 數字及其他項目可以附加到報文上。
SOAP提供了一種讓客戶端指定哪箇中間處理節點必須處理報頭項目的方法。由於報頭與SOAP訊息的主體內容是互不相關的，所以可用它們給訊息添加信息，而 不會影響對訊息報文的處理。
例如，報頭可用於為報文中包含的請求提供數字簽名。在這種情形下，身份驗證/授權伺服器可以處理報頭項目獨立於報文可以剝離信息以驗證簽名。一旦通過驗證，封套的其餘部分將被傳遞給SOAP伺服器，它將對訊息的報文進行處理。深入研究一下SOAP封套，有助於明了SOAP報頭和報文元素的位置和用途。
剖析SOAP封套
SOAP1.1規範提供了下面的封套示例：SOAP-ENV:mustUnderstand="1"5DEF在這個例子中，GetLastTradePrice請求被傳送給網路上某個位置的一個存儲-引用服務。
該請求帶有一個字元型參數，一個訂單符號，並在SOAP回響中返回一個浮點數。SOAP封套是表示SOAP訊息的XML文檔的頂層元素。XML命名空間用於將SOAP標識符與應用程式的特定標識符區分開。XML命名空間在SOAP中使用很頻繁，以把訊息的元素的作用域限制在一個特定的領域。理解SOAP命名空間有助於熟悉XML命名空間規範。如果您沒有理解命名空間，也可以簡單地把它看作一種鄰近的標識符， 它通過把SOAP元素與特定的位置（真實的或想像的）相關聯，從而有助於惟一地標識SOAP元素。
命名空間
上面例子中的第一個命名空間參照了在SOAP訊息中定義元素和屬性的SOAP模式。
第二個命名空間參照了SOAP編碼，即前文中討論過的“Section 5”數據類型。 由於沒有指定額外的通用元素編碼，這種編碼將適用於整篇文檔。
報頭
在SOAP封套報頭示例中標識的第一個元素是一個transaction（交易）元素，它帶有一個命名空間屬性和一個值為1的mustUnderstand屬性。既然mustUnderstand的屬性值設為1 ，接受該訊息的伺服器必須在該transaction節點上執行中間處理。您可以對此 作這樣的解釋：伺服器與客戶端事先已就管理該報頭元素處理的語義達成了一致，因而伺服器確切地知道要處理的元素的內容，本例中元素的內容是“5”。如果接收訊息的伺服器不理解transaction報頭的語義，它就會拒絕請求並拋出 一個錯誤。錯誤元素是SOAP報文和定義良好的機制的一個特殊部分，用於把錯誤信息送回給客戶端。
像這樣的中間處理節點是SOAP可擴展性的一個例子。客戶端在SOAP訊息中包含這樣的節點，以在可以處理訊息的報文內容前，指示要發生的特殊的處理需要。要保證向後兼容不能提供這種處理的現有的伺服器，只需把mustUnderstand 屬性設定為0，它使操作是可選的。除了定義像上例中所示的transaction節點外，SOAP訊息還可包含報頭項目， 它們用於指定節點執行身份驗證處理、加密、狀態的永久性、業務邏輯處理等。報頭有助於把SOAP構建成一種可擴展的模態包模型。只需記住報頭處理是完全獨 立於SOAP訊息的報文的。
報文
上面例子中的SOAP報文包含一個XML載荷，我們可以推測RPC沒有為我們對其作詳細解釋。SOAP不僅是一種模態包模型，它還是一種相當神秘的包模型。沒有什麼跡象清楚地顯示RPC將要開始做什麼。我們在報文中所看到的是幾個 XML元素，其中一個用命名空間進行了限制。它取決於SOAP伺服器理解文檔語義並 執行正確的處理。事實上，伺服器提供了一種架構，以有意義的方式處理XML載荷。這裡的“有意義”意味著伺服器在某些後台資料庫上調用遠程過程，以為訊息報文中包含的股票-符號元素接收股票價格。所有這些魔術般的操作都是在SOAP RPC幕後發生的。
SOAP-RPC
SOAP訊息本質上是一種從傳送方到接收方的單向傳輸，但是SOAP經常組合到實 現請求/回響機制中。要讓RPC使用SOAP，必須遵循幾條規則。首先，請求和回響訊息必須被編碼成結構類型。對一個操作的每一個輸入參數，都必須有一個同名元素（或輸入結構的成員）作為參數。對每一個輸出參數，都必須有一個名稱匹 配的元素（或輸出結構的成員）。
基於RPC的觀點，會省略一些更早一點顯示的SOAP訊息。只帶有報文部分的SOAP請求與回響封套如下所示：
請求DEF回響 22.50請求要調用GetLastTradePrice方法。注意回響定義了GetLastTradePriceResponse操作。對附加回響到回響操作尾部的一個常用的SOAP調用規則是：創建回響結構。這種輸出結構包含一個名稱為price的元素，它返回方法調用的結果，假定為浮點型。
在SOAP封套中沒有什麼地方的數據類型是顯式聲明的，注意到這一點很重要，這樣如果只查看SOAP訊息，就不會知道符號類型或結果參數price（價格）的類型。客戶端應用程式一般通過“Section 5”編碼定義數據類型，或通過與伺服器 私下達成的協定來定義數據類型。在任何一種情況下，這些包含在SOAP訊息中的 定義都不是顯式的。
最後，為了進行RPC，需要一種低級協定如HTTP。儘管SOAP 1.0規範強制要求 使用HTTP作為傳輸協定，但SOAP1.1規範（及其姊妹規範“帶有附屬檔案的SOAP訊息”）允許使用FTP、SMTP、甚至（可能）原始的TCP/IP套接字。所有這些對SOAP通用的序列化和編碼規則，也適用於RPC參數。
SOAP用例
Internet上某些地方的客戶端應用程式使用Web服務。
Web服務（通過SOAP）顯示對象方法。
對象方法訪問Web上任意位置的遠程數據。
對這些網路命題套用傳遞邏輯，我們可以為Web服務和SOAP下一個總的結論：某些位置的客戶端可以使Web上任意位置的數據。這就是所要證明的。
下面是更加詳細一點的用例。
SOAP客戶端使用UDDI註冊來查找Web服務。不用直接操作WSDL，大多數情況下SOAP應用程式將硬連線到使用特定類型的連線埠和特定樣式的綁定，並且它將通過UDDI動態配置要調用的、與發現的Web服務匹配的服務地址。
客戶端應用程式創建SOAP訊息，它是一個可執行想要的請求/回響操作的XML文檔。
客戶端把SOAP訊息傳送給監聽SOAP請求的Web伺服器上的JSP或ASP頁面。
SOAP伺服器解析SOAP包並在其領域調用合適的對象方法，在SOAP文檔中包
含的參數中傳遞。在SOAP伺服器接收訊息之前，中間處理節點可以執行SOAP報 頭指示的特殊功能，可視情況確定是否執行這步操作。
請求對象執行指示的功能，並返回數據給SOAP伺服器，它把回響打包到
SOAP封套中。伺服器把SOAP封套包裹在要傳送回請求機器的回響對象中，如servlet或COM對象。
客戶端接收對象，剝離出SOAP封套並把回響文檔傳送給最初發出請求的程式，完成請求/回響循環。
小結
SOAP是一種基於XML的協定，它用於在分散式環境中傳送訊息，並執行遠程過程調用。使用SOAP，不用考慮任何特定的傳輸協定（儘管通常選用HTTP協定），就能使數據序列化。用SOAP來構建平台與語言中性的互作業系統是一個好的選擇。總之，SOAP和 Web服務已為在XML上構建分散式應用程式基礎結構所需的一切都考慮好了。通過解決COM和Java組件對象模型之間的衝突，SOAP把多個平台在訪問數據時所出現的不兼容性問題減至最少。先把這些討論放在一邊，SOAP是一種適用於所有類型的對象實體的理想的媒介即使對於像Brad Pitt和Edward Norton之類的好萊塢電影角色也可用作一種通信媒介。就像在電影中一樣，期待著這種新技術帶來震撼世界的效果。
