SOAP協議的結構格式
對于簡單對象訪問協議,也就是SOAP協議大家了解多少呢?我們本文就來對這個協議的結構進行一下細致地講解。希望對您能有所幫助。那么首先來看一下這方面的定義吧。SOAP:簡單對象訪問協議(SOAP:Simple Object Access Protocol)
簡單對象訪問協議(SOAP)是一種輕量的、簡單的、基于 XML 的協議,它被設計成在 WEB 上交換結構化的和固化的信息。SOAP可以和現存的許多因特網協議和格式結合使用,包括超文本傳輸協議( HTTP),簡單郵件傳輸協議(SMTP),多用途網際郵件擴充協議(MIME)。它還支持從消息系統到遠程過程調用(RPC)等大量的應用程序。
SOAP包括三個部分:
SOAP封裝:它定義了一個框架 , 該框架描述了消息中的內容是什么,誰應當處理它以及它是可選的還是必須的。
SOAP編碼規則:它定義了一種序列化的機制,用于交換應用程序所定義的數據類型的實例。
SOAPRPC 表示:它定義了用于表示遠程過程調用和應答的協定。
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 協議綁定。
消息格式
SOAP在標準化消息格式環境中,可以做所有它能完成的工作。消息的主體部分 是“text/xml”形式的MIME類型,并且包含一個SOAP封套。該封套是一個XML文 檔。封套包含了報頭(可選的)和報文(必須有的)。封套的報文部分總是用于 最終接收的消息,而報頭項目可以確定執行中間處理的目標節點。附件、二進制 數字及其他項目可以附加到報文上。
SOAP協議提供了一種讓客戶端指定哪個中間處理節點必須處理報頭項目的方法。由于報頭與SOAP消息的主體內容是互不相關的,所以可用它們給消息添加信息,而 不會影響對消息報文的處理。
例如,報頭可用于為報文中包含的請求提供數字簽名。在這種情形下,身份驗證/授權服務器可以處理報頭項目獨立于報文可以剝離信息以驗證簽名。 一旦通過驗證,封套的其余部分將被傳遞給SOAP服務器,它將對消息的報文進行處理。深入研究一下SOAP封套,有助于明了SOAP報頭和報文元素的位置和用途。
剖析SOAP封套
SOAP1.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載 荷。這里的“有意義”意味著服務器在某些后臺數據庫上調用遠程過程,以為消 息報文中包含的股票-符號元素接收股票價格。所有這些魔術般的操作都是在SOAPRPC幕后發生的。