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 協議綁定。 html
SOAP在標準化消息格式環境中，能夠作全部它能完成的工做。消息的主體部分 是「text/xml」形式的MIME類型，而且包含一個SOAP封套。該封套是一個XML文 檔。封套包含了報頭（可選的）和報文（必須有的）。封套的報文部分老是用於 最終接收的消息，而報頭項目能夠肯定執行中間處理的目標節點。附件、二進制 數字及其餘項目能夠附加到報文上。數據庫
SOAP提供了一種讓客戶端指定哪一個中間處理節點必須處理報頭項目的方法。由
於報頭與SOAP消息的主體內容是互不相關的，因此可用它們給消息添加信息，而 不會影響對消息報文的處理。安全
例如，報頭可用於爲報文中包含的請求提供數字簽名。在這種情形下，身份驗
證/受權服務器能夠處理報頭項目獨立於報文能夠剝離信息以驗證簽名。
一旦經過驗證，封套的其他部分將被傳遞給SOAP服務器，它將對消息的報文進行
處理。深刻研究一下SOAP封套，有助於明瞭SOAP報頭和報文元素的位置和用途。服務器
SOAP 1.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消息本質上是一種從發送方到接收方的單向傳輸，可是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做爲傳輸協議，但SOAP
1.1規範（及其姊妹規範「帶有附件的SOAP消息」 ）容許使用FTP、SMTP、甚至（可能）原始的TCP/IP套接字。全部這些對SOAP通用
的序列化和編碼規則，也適用於RPC參數。
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之類的好萊塢電影角色也可用做 一種通訊媒介。就像在電影中同樣，期待着這種新技術帶來震撼世界的效果。
RPC-----------------------------
RPC（Remote Procedure Call Protocol）——
遠程過程調用協議，它是一種經過網絡從遠程
計算機程序上請求服務，而不須要了解底層網絡技術的協議。
RPC協議假定某些
傳輸協議的存在，如TCP或UDP，爲通訊程序之間攜帶信息數據。在OSI
網絡通訊模型中，RPC跨越了
傳輸層和
應用層。RPC使得開發包括網絡分佈式多程序在內的
應用程序更加容易。
RPC採用客戶機/服務器
模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，而後等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息的到達爲止。當一個調用信息到達，服務器得到進程參數，計算結果，發送答覆信息，而後等待下一個調用信息，最後，
客戶端調用進程接收答覆信息，得到進程結果，而後調用執行繼續進行。
有多種 RPC
模式和執行。最初由 Sun 公司提出。IETF ONC 憲章從新修訂了 Sun 版本，使得 ONC RPC 協議成爲 IETF 標準協議。如今使用最廣泛的
模式和執行是開放式
軟件基礎的分佈式計算環境（DCE）。
運行時,一次客戶機對服務器的RPC調用,其內部操做大體有以下十步：
5.執行遠程過程
6.執行的過程將結果返回服務器句柄
10.客戶接收句柄返回的數據
RPC OVER HTTP
Microsoft RPC-over-HTTP 部署(RPC over HTTP)容許RPC
客戶端安全和有效地經過Internet 鏈接到RPC 服務器程序並執行
遠程過程調用。這是在一個名稱爲RPC-over-HTTP 代理，或簡稱爲RPC 代理的
中間件的幫助下完成的。
RPC 代理運行在IIS
計算機上。它接受來自Internet 的RPC 請求，在這些請求上執行認證，檢驗和訪問檢查，若是請求經過全部的測試，RPC 代理將請求轉發給執行真正處理的RPC 服務器。經過RPC over HTTP，RPC
客戶端不和服務器直接通訊，它們使用RPC 代理做爲
中間件。
遠程過程調用（RPC）信息協議由兩個不一樣結構組成：調用信息和答覆信息。信息流程以下所示：
RPC 調用信息：每條
遠程過程調用信息包括如下無符號整數字段，以獨立識別遠程過程：
程序號（Program number）
程序版本號（Program version number）
過程號（Procedure number）
RPC 調用信息主體形式以下：
struct call_body {
unsigned int rpcvers;
unsigned int prog;
unsigned int vers;
unsigned int proc;
opaque_auth cred;
opaque_auth verf;
1 parameter
2 parameter . . . }；
RPC 答覆信息：RPC 協議的答覆信息的改變取決於
網絡服務器對調用信息是接收仍是拒絕。答覆信息請求包括區別如下情形的各類信息：
RPC 成功執行調用信息。.
RPC 的遠程實現不是協議第二版，返回 RPC 支持的最低和最高版本號。
在遠程系統中，遠程程序不可用。
遠程程序不支持被請求的版本號。返回遠程程序所支持的最低和最高版本號。
請求的過程號不存在。一般是呼叫方協議或程序差錯。
RPC答覆信息形式以下：
enum reply_stat stat
{MSG_ACCEPTED = 0,
MSG_DENIED = 1 }；
