前面我們對SOAP協議進行了介紹。我們了解，并且掌握了這部分的原理知識。了解到在一些重要的應用中，這個簡單對象訪問協議起到了很重要的作用。這里我們主要分析一下RPC以及SOAP協議應用等方面的內容。

SOAP-RPC    

SOAP消息本質上是一種從發送方到接收方的單向傳輸，但是SOAP經常組合到實 現請求/響應機制中。要讓RPC使用SOAP，必須遵循幾條規則。首先，請求和響應 消息必須被編碼成結構類型。對一個操作的每一個輸入參數，都必須有一個同名 元素（或輸入結構的成員）作為參數。對每一個輸出參數，都必須有一個名稱匹 配的元素（或輸出結構的成員）。

基于RPC的觀點，會省略一些更早一點顯示的SOAP消息。只帶有報文部分的SOAP請求與響應封套如下所示：

請求 DEF響應 22.50請求要調用GetLastTradePrice方法。注意響應定義了 GetLastTradePriceResponse操作。對附加響應到響應操作尾部的 一個常用的SOAP調用規則是：創建響應結構。這種輸出結構包含一個名稱為 price的元素，它返回方法調用的結果，假定為浮點型。

在SOAP封套中沒有什么地方的數據類型是顯式聲明的，注意到這一點很重要，這樣如果只查看SOAP消息，就不會知道符號類型或結果參數price（價格）的類 型。客戶端應用程序一般通過“Section 5”編碼定義數據類型，或通過與服務器 私下達成的協議來定義數據類型。在任何一種情況下，這些包含在SOAP消息中的 定義都不是顯式的。

***，為了進行RPC，需要一種低級協議如HTTP。盡管SOAP1.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之類的好萊塢電影角色也可用作 一種通信媒介。就像在電影中一樣，期待著這種新技術帶來震撼世界的效果。