對于簡單對象訪問協(xié)議，也就是SOAP協(xié)議大家了解多少呢？我們本文就來對這個協(xié)議的結(jié)構(gòu)進行一下細致地講解。希望對您能有所幫助。那么首先來看一下這方面的定義吧。SOAP：簡單對象訪問協(xié)議（SOAP：Simple Object Access Protocol）

簡單對象訪問協(xié)議（SOAP）是一種輕量的、簡單的、基于 XML 的協(xié)議，它被設(shè)計成在 WEB 上交換結(jié)構(gòu)化的和固化的信息。SOAP可以和現(xiàn)存的許多因特網(wǎng)協(xié)議和格式結(jié)合使用，包括超文本傳輸協(xié)議（ HTTP），簡單郵件傳輸協(xié)議（SMTP），多用途網(wǎng)際郵件擴充協(xié)議（MIME）。它還支持從消息系統(tǒng)到遠程過程調(diào)用（RPC）等大量的應(yīng)用程序。

SOAP包括三個部分：

SOAP封裝：它定義了一個框架 , 該框架描述了消息中的內(nèi)容是什么，誰應(yīng)當(dāng)處理它以及它是可選的還是必須的。

SOAP編碼規(guī)則：它定義了一種序列化的機制，用于交換應(yīng)用程序所定義的數(shù)據(jù)類型的實例。

SOAPRPC 表示：它定義了用于表示遠程過程調(diào)用和應(yīng)答的協(xié)定。

SOAP消息基本上是從發(fā)送端到接收端的單向傳輸，但它們常常結(jié)合起來執(zhí)行類似于請求 / 應(yīng)答的模式。所有的SOAP消息都使用 XML 編碼。一條SOAP消息就是一個包含有一個必需的SOAP的封裝包，一個可選的SOAP標頭和一個必需的SOAP體塊的 XML 文檔。

把SOAP綁定到 HTTP 提供了同時利用SOAP的樣式和分散的靈活性的特點以及 HTTP 的豐富的特征庫的優(yōu)點。在 HTTP 上傳送SOAP并不是說SOAP會覆蓋現(xiàn)有的 HTTP 語義，而是 HTTP 上的SOAP語義會自然的映射到 HTTP 語義。在使用 HTTP 作為協(xié)議綁定的場合中， RPC 請求映射到 HTTP 請求上，而 RPC 應(yīng)答映射到 HTTP 應(yīng)答。然而，在 RPC 上使用SOAP并不僅限于 HTTP 協(xié)議綁定。

消息格式

SOAP在標準化消息格式環(huán)境中，可以做所有它能完成的工作。消息的主體部分 是“text/xml”形式的MIME類型，并且包含一個SOAP封套。該封套是一個XML文 檔。封套包含了報頭（可選的）和報文（必須有的）。封套的報文部分總是用于 最終接收的消息，而報頭項目可以確定執(zhí)行中間處理的目標節(jié)點。附件、二進制 數(shù)字及其他項目可以附加到報文上。

SOAP協(xié)議提供了一種讓客戶端指定哪個中間處理節(jié)點必須處理報頭項目的方法。由于報頭與SOAP消息的主體內(nèi)容是互不相關(guān)的，所以可用它們給消息添加信息，而 不會影響對消息報文的處理。

例如，報頭可用于為報文中包含的請求提供數(shù)字簽名。在這種情形下，身份驗證/授權(quán)服務(wù)器可以處理報頭項目獨立于報文可以剝離信息以驗證簽名。 一旦通過驗證，封套的其余部分將被傳遞給SOAP服務(wù)器，它將對消息的報文進行處理。深入研究一下SOAP封套，有助于明了SOAP報頭和報文元素的位置和用途。

剖析SOAP封套

SOAP1.1規(guī)范提供了下面的封套示例：SOAP-ENV:mustUnderstand=1 5DEF

在這個例子中，GetLastTradePrice請求被傳送給網(wǎng)絡(luò)上某個位置的一個存儲。

引用服務(wù)

該請求帶有一個字符型參數(shù)，一個訂單符號，并在SOAP響應(yīng)中返回一 個浮點數(shù)。SOAP封套是表示SOAP消息的XML文檔的頂層元素。XML命名空間用于將SOAP標識 符與應(yīng)用程序的特定標識符區(qū)分開。XML命名空間在SOAP協(xié)議中使用很頻繁，以把消息 的元素的作用域限制在一個特定的領(lǐng)域。理解SOAP協(xié)議命名空間有助于熟悉XML命名空 間規(guī)范。如果您沒有理解命名空間，也可以簡單地把它看作一種鄰近的標識符， 它通過把SOAP元素與特定的位置（真實的或想像的）相關(guān)聯(lián)，從而有助于惟一地 標識SOAP元素。

命名空間

上面例子中的第一個命名空間參照了在SOAP消息中定義元素和屬性的SOAP模式。第二個命名空間參照了SOAP編碼，即前文中討論過的“Section 5”數(shù)據(jù)類型。 由于沒有指定額外的通用元素編碼，這種編碼將適用于整篇文檔。

報頭

在SOAP封套報頭示例中標識的第一個元素是一個transaction（交易）元素，它 帶有一個命名空間屬性和一個值為1的mustUnderstand屬性。既然mustUnderstand的屬性值設(shè)為1 ，接受該消息的服務(wù)器必須在該transaction節(jié)點上執(zhí)行中間處理。您可以對此 作這樣的解釋：服務(wù)器與客戶端事先已就管理該報頭元素處理的語義達成了一 致，因而服務(wù)器確切地知道要處理的元素的內(nèi)容，本例中元素的內(nèi)容是“5”。 如果接收消息的服務(wù)器不理解transaction報頭的語義，它就會拒絕請求并拋出 一個錯誤。錯誤元素是SOAP報文和定義良好的機制的一個特殊部分，用于把錯誤信 息送回給客戶端。

像這樣的中間處理節(jié)點是SOAP可擴展性的一個例子?？蛻舳嗽赟OAP消息中包含 這樣的節(jié)點，以在可以處理消息的報文內(nèi)容前，指示要發(fā)生的特殊的處理需要。 要保證向后兼容不能提供這種處理的現(xiàn)有的服務(wù)器，只需把mustUnderstand 屬性設(shè)置為0，它使操作是可選的。除了定義像上例中所示的transaction節(jié)點外，SOAP消息還可包含報頭項目， 它們用于指定節(jié)點執(zhí)行身份驗證處理、加密、狀態(tài)的永久性、業(yè)務(wù)邏輯處理等。 報頭有助于把SOAP協(xié)議構(gòu)建成一種可擴展的模態(tài)包模型。只需記住報頭處理是完全獨 立于SOAP消息的報文的。

報文

上面例子中的SOAP報文包含一個XML載荷，我們可以推測RPC沒有為我們對其作詳細解釋。SOAP不僅是一種模態(tài)包模型，它還是一種相當(dāng)神秘的包模型。沒有什么跡象清楚地顯示RPC將要開始做什么。我們在報文中所看到的是幾個 XML元素，其中一個用命名空間進行了限制。它取決于SOAP服務(wù)器理解文檔語義并 執(zhí)行正確的處理。事實上，服務(wù)器提供了一種架構(gòu)，以有意義的方式處理XML載 荷。這里的“有意義”意味著服務(wù)器在某些后臺數(shù)據(jù)庫上調(diào)用遠程過程，以為消 息報文中包含的股票-符號元素接收股票價格。所有這些魔術(shù)般的操作都是在SOAPRPC幕后發(fā)生的。