幾乎如任何與 XML 相關的事物一樣，“簡單對象訪問協議”近來倍受新聞界的注意。您可能會感到驚奇，雖然 SOAP 的櫥窗裝扮成新的，但其下面所呈現的要回溯至數年前，甚至是數十年前。在本文中，我揭開了圍繞著 SOAP 的面紗，並查看它應該是什麼樣，而實際是什麼樣，以及它如何與類似的技術相比。與我的所有文章一樣，底線是確定該技術是否適合於您，而在這裡我將嘗試撇開 SOAP 附帶的華麗辭藻來確定它可以給您的應用帶來的價值。
我將從快速查看構成 SOAP 首字母縮略詞混合的開始，包括在 RPC（遠程過程調用）它不怎麼順利的起源，以及它使用 XML 來解決一些 RPC 的早期問題。接下來，我將涉及 SOAP 為表帶來的一般 XML-RPC 工具箱中不交付的特性，以及這些附加物是重要還是不重要的原因。從那裡，我繼續將 SOAP 和一般而言的 RPC 與它的最大競爭對手之一，遠程方法調用（RMI）相比較。我將討論 RPC 模型、RMI 信息流模型以及在這種環境中使用 XML 的益處。我還將看一下如何使 SOAP 為您工作。最後，我將涵蓋 SOAP 的實用性對比其未來的展望，以及潛在的 XML 是否是您通信需求的完整答案，或者只是較大因素的一部分。
首字母縮略詞混合
SOAP 是 YAA － “還有另一個首字母縮略詞”。（是的，我正在用首字母縮略詞來說明首字母縮略詞；如果您感到不解，請查尋字典中的 諷刺！）正如上面所提到，"SOAP" 代表“簡單對象訪問協議”（Simple Object Access Protocol），與現在大多數首字母縮略詞一樣，它本身並不意味著什麼。只是另外四個要記住的字母，對嗎？實際上，比那要復雜得多。在下面，SOAP 需要其它幾個首字母縮略詞方面的知識。它基於遠程過程調用，或 RPC。除此之外，它建立在更傳統的 XML-RPC 之上。還有一個事實是，SOAP 需要遠程過程調用如何工作的基本知識，並且您還需要了解另一個首字母縮略詞 XDR（外部數據表示標准）和 HTTP（超文本傳輸協議）。有那麼多要記住，不是嗎？要了解 SOAP 的真正本質，有必要看一下它的基礎。
SOAP 從 RPC 開始
關於 RPC 的討論會闡明 SOAP 的各個方面，這些方面是 SOAP 特別 固有的。這裡您可以發現您喜歡的關於 SOAP 的事情與 SOAP 沒有直接的聯系，但是，事實上，是 XML-RPC 的特性。這提出使用任何技術時的重要觀點：確保不要使用過於復雜的包來處理也許是相當簡單的需求。如本文中我會多次提到，去蕪存箐。在您的應用程序中沒有地方來放亂七八糟的東西。按那種說法，該是仔細回憶的時候了。
SOAP 之路以 RPC 開始，如果您一直在做面向對象編程，那麼它是與您可能習慣使用的完全不同的模型。RPC 是一種通過網絡來發送請求的基於消息的方式。與其嘗試抽象地解釋它，不如看一個實際的示例。
RPC 示例
考慮執行有關人類基因項目工作的應用程序。這些應用程序允許科學家輸入信息和接收計算完的結果，同時應用程序核心執行大量計算。由於這些計算通常消耗相當長時間，在完成等式之前附加信息可能進入。所以理想的方案如下：科學家將數據輸入應用程序。計算開始。科學家和應用程序 繼續執行。在接受新數據之前，程序不會暫停並等待這些大量計算的完成；它只是啟動進程。（將它想象成 Java 中啟動一個線程。）更多信息出現了，它被輸入程序，計算被修改，進程繼續（因為那個線程是在後台）。在某一刻,無需用戶干涉，程序完成計算並提交結果。
RPC 進程與 OO 交互對比
在 RPC 示例中描述的交互與 OO 類型的交互完全不同，在 OO 交互中調用一個方法，在完成該方法後，返回結果。 在我剛描述的 RPC 情形中，數據被發送到執行復雜計算的機器，然後該機器返回一個相當於“好，我已經開始了”的響應。計算不斷地繼續下去。同時應用程序繼續前進，不等待計算的結果。那這是如何工作的呢？唔，它實際上 是 RPC 的基礎。RPC 是基於消息的：消息被發送到大的服務器，然後，在某一刻，會收到從大的服務器發出的“好，我做完了”的消息。您開始了解到在方法上 RPC 與您過去可能習慣的 00 方法之間的區別？
RPC 和編碼
現在，在 RPC 中，由於機器通常通過網絡進行通信，發送到執行計算的機器的數據必須被 編碼。數據必須轉換成某種容易在網絡傳輸的格式。所以自變量（數據)－無論是浮點數、整數、字符串還是復雜對象 － 都要編碼成可以傳輸到 RPC 接收方的格式。 在 RPC 中，該格式是我早先提到過的外部數據表示 (XDR) 標准。 然後，接收方從 XDR 譯碼消息，並對數據進行處理。返回消息反向執行同樣的過程（從服務器移到客戶機）。 由於 HTTP 易於使用，這些消息經常通過 HTTP 發送。所以如果您所希望的是這種通信方式，那麼 RPC 也許適合於您。換句話說，SOAP 不提供該功能；成為 SOAP 基礎的 RPC 基礎。記住，這裡沒有什麼是特定於 SOAP 的；我正在談論的是 任何 RPC 系統的基本基礎。
XML-RPC
您也許已經發現 RPC 的問題：編碼。 正如我所演示的，RPC 使用 XDR 編碼格式。當然，如果您象我一樣，當我第一次看到 XDR 時，說“那是什麼鬼東西？”唔，它是專為 RPC 創建的。最初，該編碼在任何其它環境中是毫無用處的。 由於它與 RPC 的聯系太緊密，在幾乎所有應用程序中，開發人員僅對 RPC 使用 XDR。它只是不適合於在其它通信或數據表示形式中使用。然而，在 1998 年，隨著人們逐漸熱衷於 XML，開發人員開始連接到網站上，認識到 XML 可能能夠替代 XDR 而成為 RPC 數據編碼格式。他們還認識到可以在應用程序中的許多其它地方使用 XML，譬如，數據庫存儲和表示。XML-RPC 是這種想法的實現：它只不過是普通的 RPC，但是用 XML － 而不是 XDR －作為編碼格式。
XML 的益處
XML 是標准語言，很容易為它編寫編碼器和譯碼器。但是益處不僅僅是這些。將字符流轉換成 XML，然後語法分析和理解那個 XML 是易如反掌。XML 給您帶來的不僅僅是容易編碼和譯碼。以 XML 格式存儲數據逐漸開始普及。例如，考慮這樣的事實，用很少或無系統開銷就可以相對不修改地將 XML 數據發送到 XML-RPC 調用。同樣，想象出現允許使用不同格式的 XML-RPC 系統方便地從一種格式轉換到另一種格式的 XML 轉換 (XSLT)。最後，想象在某處企業的 XML-RPC 發送方將一個 XML-RPC 有效負載發送到另一個企業。 不是嚴格地以 RPC 來處理它，發出調用的企業以 B2B（抱歉，這又是另一個首字母縮略詞，這個詞代表“商家到商家”）方式使用信息，然後返回 RPC 風格的響應。您突然發現自己在僅僅使用 XML-RPC 來編寫 B2B 應用程序，XML-RPC 是可以自由獲取用於幾乎任何編程語言的庫！
忠於 XML-RPC
我想說，傾心於 SOAP 中接近於 75% 的人實際是傾心於簡單的 XML-RPC。如果您發現您自己在考慮：“我可以發送 XML 遠程調用和使用簡單庫來做到？ 哇，太好了！今天我將開始使用 SOAP”，然後忠於 SOAP。 可以跳過 SOAP 下載，僅抓住簡單的 XML-RPC。您會對穩定的代碼、更簡單的接口以及更少的開銷，感到更高興。在可以使用更少處理能力來做同樣工作的建議中，我知道我正在涉足這一神聖的領域。但是要記住“去蕪存箐”這條諺語。將這牢記在心中，下一節將講述用 SOAP，您將 獲得什麼。
現在討論 SOAP
大問題是：“SOAP 將什麼添加到該等式中？”答案相當簡單。提交給 W3C 的有關 SOAP 的說明定義了除了基本的 XML-RPC 特性之外 SOAP 所包含的兩項主要項。首先是 信封，攜帶關於所包含消息的信息。其次是一套 應用程序特定數據類型編碼 的規則。讓我們看一下這些項。
信封
SOAP 信封類似於實際信的信封。 它提供關於正在 SOAP 有效負載中編碼的消息的消息，包括與接收方和發送方相關的數據以及關於消息本身的細節。例如，SOAP 信封的頭可以確切指定如何處理消息。這意味著在應用程序繼續處理消息之前，應用程序可以決定關於消息的信息，包括它是否 可以處理該消息。與標准 XML-RPC 調用的情況不同，使用 SOAP 實際的解釋，以便決定關於消息的某些事。 典型的 SOAP 消息還可能包含編碼風格，它幫助接收方解釋該消息。 清單 1 顯示了 SOAP 信封，用指定的編碼完成。
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.XMLsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://myHost.com/encodings/secureEncoding">
<SOAP-ENV:Body>
<article XMLns="http://www.ibm.com/developer">
<name>Soapbox</name>
<url>http://www.ibm.com/developerworks/library/x-soapbx1.Html</url>
</article>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
一套簡單的編碼規則
SOAP 帶給表的第二個主要元素是編碼用戶定義的數據類型的簡單方式。在 RPC（和 XML-RPC）中，編碼只可能針對預先定義的數據類型發生。編碼其它類型需要修改實際的 RPC 服務器和客戶機自身。然而，用 SOAP，XML 模式可以方便地用來指定新數據類型 （用 complexType 結構），然後那些新類型可以方便地用 XML 表示，作為 SOAP 有效負載的一部分。究竟這是如何起作用超出了本文所討論的范圍，並且可能需要我進一步詳細闡述 SOAP 和 XML 模式。考慮到本文的目的，顯示在 SOAP 消息中的任何數據類型編碼是多麼容易就已足夠了，您可以用 XML 模式邏輯地描述該消息。
SOAP 懷疑論
討論至今，可以看到 SOAP 不是僅由一個，而是由三個首字母縮略詞組成。如果您所需要的是經過網絡發送消息的方法，那麼緊緊抓住 XML-PRC。但是如果您發現經常因嘗試用復雜的、用戶定義的類型進行通信而煩惱，如果您的應用程序在處理該消息 以前 必須檢查消息的指令，或者如果您希望趕上最新潮流，那麼 SOAP 是適合您的。 對於 SOAP 的使用，如果有些懷疑，確實如此。如果經由網絡發送復雜的數據類型，將這些結構編碼以及譯碼成 XML，這與使用如 RMI（遠程方法調用）技術一樣，可能需花大量時間。而且，所有事情都是平等的，人們幾乎總是推薦 RMI，而不是 SOAP。 RMI 已有很長一段時間，這意味著它有較少的錯誤，有更多的時間成熟，並且在編程社區中，大家普遍接受 RMI。 那意味著我從來不用 SOAP 或從來不推薦它？當然不是！但與任何新技術一樣，當您希望使用勝過一般意義上的新技術時，小心和有一個好的理由使用技術，這將省去向您見識短淺的老板解釋時的尴尬。
展望 RMI
在下一篇文章中，我將繼續深入探討 SOAP。首先，我將從第一部分漏講的地方談起，比較和對照（聽起來象高中的英語作業？）RPC 和 RMI。毫不驚奇，總會有 SOAP 和 RPC 有意義的時候也會有 RMI 起作用的時候，所以在本系列中的下一篇文章將幫助搞清楚涉及的折衷方法。接下來我將研究現在使用 SOAP 意味著什麼，看一下您對哪些折服，仍然有哪些遺漏的，以及今後出現的標准有些什麼。經過所有這些之後，我仍會保持一種懷疑的眼光，以確保這一 SOAP 評估避免協議已引來的欺騙。
結束語
希望我所演示的 SOAP 並不是人們通常所認為的魔彈。更為重要的是，希望您能夠了解 SOAP 的眾多“特性”，並不是對 SOAP 是唯一的，事實上是 RPC 和 XML-RPC 的一部分。我確實標識了 SOAP 的某些特定的特性，如 SOAP 信封。
在您自己的工作中使用 SOAP 的價值和可行性這一點上，有可能作出任何結論嗎？絕對可以！首先，這不是什麼新的東西，您應該總是緊盯商業需求，而不是技術需求。擺弄 SOAP 有許多樂趣，並且在您那些標新立異的朋友當中顯得非常與眾不同，事實是，如果它不能為您提供一種解決問題的方法，那麼它可能會浪費大量時間。同樣，並且這是很重要的一點，使用 XML-RPC 完成任務要比您選擇使用 SOAP 更容易，這是很有可能的。 不要被廣告所欺騙。SOAP 已經到來，但它不是天外來客。相反，SOAP 僅僅是已經持續了很長一段時間的大的，有時是臃腫的同類技術，並且通常易於使用。下次我將更深入地剖析 SOAP，並探討更多有關它可為您所做的事。