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

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

SOAP包括三個(gè)部分：

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

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

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

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

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

消息格式

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

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

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

剖析SOAP封套

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

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

引用服務(wù)

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

命名空間

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

報(bào)頭

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

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

報(bào)文

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