發(fā)布日期： 4/1/2004 | 更新日期： 4/1/2004
Aaron Skonnard
DevelopMentor
2003 年 3 月
適用于：
•
全局 XML Web 服務(wù)結構 (GXA)
•
遠程過(guò)程調用 (RPC)
•
SOAP 1.1 和 SOAP 1.2 規范
•
傳輸協(xié)議： TCP、HTTP、SMTP 和 MSMQ
•
Web Services Enhancements 1.0 SP1 for Microsoft .NET
•
XML 架構
摘要： SOAP 提供一種簡(jiǎn)單的、可擴展并且功能豐富的 XML 消息處理框架，用于定義高級別的應用程序協(xié)議，從而在分布式異構環(huán)境中提供更高的互操作性。（20 頁(yè)打印頁(yè)）
本頁(yè)內容
簡(jiǎn)介SOAP 版本消息處理框架擴展性處理模型協(xié)議綁定HTTP 綁定RPC 和編碼SOAP 類(lèi)型小結簡(jiǎn)介
就在不久以前，SOAP 還不過(guò)是指肥皂而已。 而如今，大多數開(kāi)發(fā)人員一聽(tīng)到這個(gè)詞眼前就會(huì )浮現出一些尖括號來(lái)。 SOAP 最初代表“簡(jiǎn)單對象訪(fǎng)問(wèn)協(xié)議”。 如果在幾年前問(wèn)任何一個(gè)人 SOAP 的含義，他們很可能這樣回答：“SOAP 是用來(lái)使 DCOM 和 Corba（例如，RPC 調用）在互聯(lián)網(wǎng)上工作”。 原作者們也承認，在那時(shí)他們注重于“訪(fǎng)問(wèn)對象”，但隨著(zhù)時(shí)間的推移，人們希望 SOAP 能夠處理更廣泛的情況。 因此，SOAP 規范的重心很快從對象轉移到通用的 XML 消息處理框架上。
這種重心的變化給 SOAP 縮寫(xiě)詞中的 "O" 帶來(lái)了一點(diǎn)小問(wèn)題。 有意思的是，SOAP 1.2 工作組沿用了（到目前為止）SOAP 這個(gè)名稱(chēng)（為什么不呢？這個(gè)詞太流行了），但決定不再把這個(gè)詞拼出來(lái)以免誤導開(kāi)發(fā)人員。 如今，在最新的 SOAP 1.2 規范中，其正式的定義并不提及對象：
SOAP 是一種輕量級協(xié)議，用于在分散型、分布式環(huán)境中交換結構化信息。 SOAP 利用 XML 技術(shù)定義一種可擴展的消息處理框架，它提供了一種可通過(guò)多種底層協(xié)議進(jìn)行交換的消息結構。 這種框架的設計思想是要獨立于任何一種特定的編程模型和其他特定實(shí)現的語(yǔ)義。
這個(gè)定義確實(shí)體現了 SOAP 現在的主旨。 SOAP 定義了一種方法以便將 XML 消息從 A 點(diǎn)傳送到 B 點(diǎn)（參見(jiàn)圖 1）。 為此，它提供了一種基于 XML 且具有以下特性的消息處理框架：1) 可擴展，2) 可通過(guò)多種底層網(wǎng)絡(luò )協(xié)議使用，3) 獨立于編程模型。 以下將分別詳細討論這三種特性。
圖 1. 簡(jiǎn)單的 SOAP 消息處理
首先，SOAP 可擴展性是關(guān)鍵所在。 在這個(gè)縮寫(xiě)詞還代表某些含義時(shí)，"S" 意味著(zhù)“簡(jiǎn)單”。 如果我們從 Web 中學(xué)到了一樣東西，那就是，簡(jiǎn)單性總是比效率和純技術(shù)更重要，因而互操作性成敗的關(guān)鍵，就在于必須絕對要求簡(jiǎn)單性。 簡(jiǎn)單性仍然是 SOAP 的主要設計目標之一，這一點(diǎn)的例證就是 SOAP 缺少分布式系統的很多特性（如安全性、路由和可靠性等）。 SOAP 定義了一種通信框架，允許以分層擴展的形式隨著(zhù)時(shí)間推移而加入這些特性。 Microsoft、IBM 和其他軟件廠(chǎng)商正在積極開(kāi)發(fā)一個(gè) SOAP 擴展的通用套件，該套件將加入大多數開(kāi)發(fā)人員期待的特性。 這一計劃被稱(chēng)為
全局 XML Web 服務(wù)結構 (GXA)Microsoft 已經(jīng)發(fā)布了針對若干 GXA 規范的一個(gè)參考實(shí)現，并將其命名為
Web Services Enhancements 1.0 SP1 for Microsoft .NET (WSE)。
其次，SOAP 可在任何傳輸協(xié)議（諸如 TCP、HTTP、SMTP，甚至是 MSMQ）上使用（參見(jiàn)
圖 1）。 然而，為了保持互操作性，需要定義一些標準協(xié)議綁定以便草擬用于每種環(huán)境的規則。 SOAP 規范提供了一種用于定義任意協(xié)議綁定的靈活框架，并且由于 HTTP 的使用極為廣泛，它現已為 HTTP 提供了一種顯式綁定。
第三，SOAP 允許任何編程模型，并且不依賴(lài)于 RPC。 大多數開(kāi)發(fā)人員立刻將 SOAP 與對分布式對象進(jìn)行的 RPC 調用等效起來(lái)（因為 SOAP 最初就是關(guān)于“訪(fǎng)問(wèn)對象”的），但實(shí)際上，基本的 SOAP 模型更接近于傳統的消息處理系統，如 MSMQ。 SOAP 定義了一種模型以便處理個(gè)別的單向消息。 你可以將多條消息組合成一條整體的消息交換。 圖 1 說(shuō)明了一種簡(jiǎn)單的單向消息，其中發(fā)送方不會(huì )收到響應。 但是，接收方可以向發(fā)送方發(fā)回一條響應（參見(jiàn)圖 2）。 SOAP 允許使用任何數量的消息交換模式 (MEP)，請求/響應只是其中一種。 其他示例包括要求/響應（與請求/響應相對）、通知和長(cháng)期運行的點(diǎn)對點(diǎn)對話(huà)等。
圖 2. 請求/響應消息交換模式
開(kāi)發(fā)人員經(jīng)常將請求/響應與 RPC 混為一談，而實(shí)際上二者之間的差別很大。 RPC 使用請求/響應，但請求/響應不一定就是 RPC。 RPC 是 一種允許開(kāi)發(fā)人員進(jìn)行方法調用的編程模型。 RPC 需要將方法簽名轉換成 SOAP 消息。 鑒于 RPC 的廣泛應用，SOAP 草擬了一項協(xié)議，以便將 RPC 用于 SOAP（參見(jiàn)本文稍后的
RPC 和編碼一節）。
具備這三種主要特性，SOAP 消息處理框架就促進(jìn)了在異構環(huán)境中交換 XML 消息，而在這類(lèi)環(huán)境中，互操作性長(cháng)久以來(lái)都是極大的挑戰。
返回頁(yè)首SOAP 版本
從第一個(gè)發(fā)布的 SOAP 規范到如今被廣泛實(shí)施的
SOAP 1.1，很多方面都發(fā)生了改變，從瑣碎的細節到思想的重大轉變。 SOAP 1.1 被提交給 W3C，并于 2000 年 5 月被發(fā)布為 Note。由于 SOAP 1.1 未能通過(guò) W3C 過(guò)程的嚴格審核，"W3C Note" 狀態(tài)使其還停留在僅是一個(gè)好主意的層次，但當完成時(shí)，它將最終達到“推薦”狀態(tài)。 然而，由于如今 SOAP 1.1 得到了大小廠(chǎng)商如此廣泛的支持，它仍然被認為是事實(shí)上的標準。
W3C 使用 SOAP 1.1 Note 作為新 XML 協(xié)議工作組的基礎，負責產(chǎn)生下一版本的 SOAP，目前命名為
SOAP 1.2。 SOAP 1.2 當前是一種“候選推薦方案”，意味著(zhù)它正處在實(shí)施階段且離最后完成為期不遠。 一旦 SOAP 1.2 成為“推薦方案”，它極有可能很快獲得廠(chǎng)商的支持。
在 SOAP 1.2 發(fā)布之后，為了提供向后兼容性，廠(chǎng)商應該繼續支持 SOAP 1.1。 SOAP 版本控制基于 XML 命名空間。 SOAP 1.1 由 http://schemas.xmlsoap.org/soap/envelope/ 命名空間標識，而 SOAP 1.2 由 http://www.w3.org/2002/12/soap-envelope 命名空間標識（盡管當其成為推薦方案時(shí)，這也將改變）。
有關(guān)每個(gè)版本的命名空間名稱(chēng)和規范所在位置，請參見(jiàn)表 1。 在本文的剩余部分中，我們將講述 SOAP 1.1 最重要的一些方面。 要了解兩個(gè)版本之間完整的
更改列表，請查看當前的 SOAP 1.2 規范。
表 1. SOAP 版本信息
•
SOAP 1.1
•
命名空間名稱(chēng)
•
規范位置
•
SOAP 1.2
•
命名空間名稱(chēng)
•
規范位置
•
http://schemas.xmlsoap.org/soap/envelope/•
http://www.w3.org/TR/SOAP/•
http://www.w3.org/2002/12/soap-envelope/•
http://www.w3.org/TR/soap12-part0/（入門(mén)）
•
http://www.w3.org/TR/soap12-part1/•
http://www.w3.org/TR/soap12-part2/返回頁(yè)首消息處理框架
SOAP 規范的核心部分就是消息處理框架。 SOAP 消息處理框架定義了一整套 XML 元素，用以“封裝”任意 XML 消息以便在系統之間傳輸。
該框架包括以下核心 XML 元素： Envelope、Header、Body 和 Fault，所有這些都來(lái)自 SOAP 1.1 中的 http://schemas.xmlsoap.org/soap/envelope/ 命名空間。 以下代碼中提供了 SOAP 1.1 的完整 XML 架構定義，以供在閱讀下文時(shí)參考。 我個(gè)人認為，每次讓自己熟悉各種 XML 結構時(shí)，檢查一下該架構是頗有幫助的。
SOAP 1.1 XML 架構定義
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"xmlns:tns="http://schemas.xmlsoap.org/soap/envelope/"targetNamespace="http://schemas.xmlsoap.org/soap/envelope/"><!-- Envelope, header and body --><xs:element name="Envelope" type="tns:Envelope" /><xs:complexType name="Envelope" ><xs:sequence><xs:element ref="tns:Header" minOccurs="0" /><xs:element ref="tns:Body" minOccurs="1" /><xs:any namespace="##other" minOccurs="0"maxOccurs="unbounded" processContents="lax" /></xs:sequence><xs:anyAttribute namespace="##other"processContents="lax" /></xs:complexType><xs:element name="Header" type="tns:Header" /><xs:complexType name="Header" ><xs:sequence><xs:any namespace="##other" minOccurs="0"maxOccurs="unbounded" processContents="lax" /></xs:sequence><xs:anyAttribute namespace="##other"processContents="lax" /></xs:complexType><xs:element name="Body" type="tns:Body" /><xs:complexType name="Body" ><xs:sequence><xs:any namespace="##any" minOccurs="0"maxOccurs="unbounded" processContents="lax" /></xs:sequence><xs:anyAttribute namespace="##any"processContents="lax" /></xs:complexType><!-- Global Attributes --><xs:attribute name="mustUnderstand" default="0" ><xs:simpleType><xs:restriction base=‘xs:boolean‘><xs:pattern value=‘0|1‘ /></xs:restriction></xs:simpleType></xs:attribute><xs:attribute name="actor" type="xs:anyURI" /><xs:simpleType name="encodingStyle" ><xs:list itemType="xs:anyURI" /></xs:simpleType><xs:attribute name="encodingStyle"type="tns:encodingStyle" /><xs:attributeGroup name="encodingStyle" ><xs:attribute ref="tns:encodingStyle" /></xs:attributeGroup><xs:element name="Fault" type="tns:Fault" /><xs:complexType name="Fault" final="extension" ><xs:sequence><xs:element name="faultcode" type="xs:QName" /><xs:element name="faultstring" type="xs:string" /><xs:element name="faultactor" type="xs:anyURI"minOccurs="0" /><xs:element name="detail" type="tns:detail"minOccurs="0" /></xs:sequence></xs:complexType><xs:complexType name="detail"><xs:sequence><xs:any namespace="##any" minOccurs="0"maxOccurs="unbounded" processContents="lax" /></xs:sequence><xs:anyAttribute namespace="##any"processContents="lax" /></xs:complexType></xs:schema>
如果檢查一下 Envelope 的 complexType 定義，你很快就能了解這些元素相互之間是如何關(guān)聯(lián)的。 以下消息模板說(shuō)明了 SOAP Envelope 的結構：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header> <!-- optional --><!-- header blocks go here... --></soap:Header><soap:Body><!-- payload or Fault element goes here... --></soap:Body></soap:Envelope>
Envelope 元素始終是 SOAP 消息的根元素。 這就便于應用程序識別“SOAP 消息” — 只要檢查一下根元素的名稱(chēng)即可。 通過(guò)檢查 Envelope 元素的命名空間，應用程序也可確定所使用的 SOAP 版本。
Envelope 元素包含一個(gè)可選的 Header 元素（有關(guān)詳細信息，參見(jiàn)
可擴展性一節），后跟一個(gè)必要的 Body 元素。 Body 元素代表了該消息的有效內容。 它是一種通用容器，因為它可包含來(lái)自任何命名空間的任意數量的元素。 這就是試圖發(fā)送數據的最終目的地。
例如，以下的 SOAP 消息代表了一個(gè)在銀行帳戶(hù)之間轉帳的請求：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><x:TransferFunds xmlns:x="urn:examples-org:banking"><from>22-342439</from><to>98-283843</to><amount>100.00</amount></x:TransferFunds></soap:Body></soap:Envelope>
如果接收方支持請求/響應，且能夠成功地處理該消息，它應向最初的發(fā)送方返回另一條 SOAP 消息。 在這種情況下，響應信息也應包含在 Body 元素中，如下例所示：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><x:TransferFundsResponsexmlns:x="urn:examples-org:banking"><balances><account><id>22-342439</id><balance>33.45</balance></account><account><id>98-283843</id><balance>932.73</balance></account></balances></x:TransferFundsResponse></soap:Body></soap:Envelope>
該消息處理框架還定義了一個(gè)名為Fault 的元素，用于在發(fā)生錯誤時(shí)在 Body 元素中表示錯誤。 這是不可缺少的，因為如果沒(méi)有一種標準的錯誤表示方法，每個(gè)應用程序將不得不自己創(chuàng )建，從而使得通用基礎結構不可能區分成功和失敗。 以下示例 SOAP 消息中包含了一個(gè) Fault 元素，指明在處理該請求時(shí)發(fā)生了“Insufficient Funds（資金不足）”錯誤：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><soap:Fault><faultcode>soap:Server</faultcode><faultstring>Insufficient funds</faultstring><detail><x:TransferError xmlns:x="urn:examples-org:banking"><sourceAccount>22-342439</sourceAccount><transferAmount>100.00</transferAmount><currentBalance>89.23</currentBalance></x:TransferError></detail></x:TransferFunds></soap:Body></soap:Envelope>
Fault 元素必須包含一個(gè) faultcode，后跟一個(gè) faultstring 元素。 faultcode 元素使用一種符合命名空間的名稱(chēng)對錯誤進(jìn)行分類(lèi)，而 faultstring 元素提供一種對錯誤可讀的解釋?zhuān)?lèi)似于 HTTP 的工作方式）。 表 2 簡(jiǎn)要地說(shuō)明了 SOAP 1.1 所定義的各種錯誤碼（所有這些代碼都包含在 http://schemas.xmlsoap.org/soap/envelope/ 命名空間中）。
Fault 元素也可能包含一個(gè) detail 元素，以便提供該錯誤的細節，這樣可以幫助客戶(hù)端診斷問(wèn)題，特別是在 Client 和 Server 錯誤碼的情況下。
表 2. SOAP 1.1 錯誤碼
名稱(chēng)
•
VersionMismatch
•
MustUnderstand
•
Client
•
Server
含義
•
處理方發(fā)現 SOAP Envelope 元素的命名空間是無(wú)效的。
•
處理方?jīng)]有理解或服從 SOAP Header 元素的某個(gè)直接子元素，而該子元素包含一個(gè)值為 "1" 的 SOAP mustUnderstand 屬性。
•
Client 類(lèi)的錯誤表明消息的格式錯誤或者不包含適當的信息，因而不能成功。 這通常表明，如果不對該消息做出更改，就不應該重發(fā)該消息。
•
Server 類(lèi)的錯誤表明該消息未能得到處理的原因與消息的內容并沒(méi)有直接關(guān)系，而是跟該消息的處理有關(guān)。 例如，處理過(guò)程可能包括與某個(gè)上游處理器的通信，但該處理器沒(méi)有響應。 如果在稍后重發(fā)，該消息可能會(huì )成功。
現在，假設你想在初始的消息中增加一些驗證信息，以便接收方能夠確定發(fā)送方是否有足夠的權限來(lái)執行傳輸。 要達到這一目的，一種方法就是在主體中添加憑證信息，如下所示：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><x:TransferFunds xmlns:x="urn:examples-org:banking"><from>22-342439</from><to>98-283843</to><amount>100.00</amount><!-- security credentials --><credentials><username>dave</username><password>evad</password></credentials></x:TransferFunds></soap:Body></soap:Envelope>
如果使用這種方法，每項需要驗證的操作都必須處理這些憑證。 這也意味著(zhù)其他需要安全性的應用程序必須開(kāi)發(fā)自己的解決方案以解決這個(gè)問(wèn)題；歸根結底，這將損害互操作性。 對于諸如安全性等公共需要，定義各方都同意的標準 SOAP 標頭將更有意義。 然后，各廠(chǎng)商可以在其通用的 SOAP 基礎結構中建立對擴展功能的支持，這樣各方皆贏(yíng)。 這種方法可提高開(kāi)發(fā)人員的生產(chǎn)力，同時(shí)有助于確保更高級別的互操作性。 而這正是 SOAP 擴展性模型設計要實(shí)現的目標。
返回頁(yè)首擴展性
大多數現有的協(xié)議都區分控制信息（例如，標頭）和消息有效負載。 在這方面，SOAP 也不例外。 SOAP Header 和 Body 元素在易于處理的 XML 世界中也進(jìn)行同樣的區分。 除了易用性之外，可擴展 Envelope 的關(guān)鍵優(yōu)勢在于它可用于任何通訊協(xié)議。
在各種應用程序協(xié)議中（如 HTTP、SMTP 等）標頭總是具有重要的意義，因為標頭允許連網(wǎng)兩端的應用程序就所支持命令的具體行為進(jìn)行協(xié)商。 盡管 SOAP 規范本身并不定義任何內置的標頭，標頭將逐漸在 SOAP 中扮演同等重要的角色。 隨著(zhù) GXA 日趨成熟及 SOAP 標頭的標準化，開(kāi)發(fā)人員能夠更方便地定義豐富的應用程序協(xié)議，而不必每次都重新開(kāi)始。
與 Body 元素類(lèi)似，Header 元素是控制信息的通用容器。 其中可包含來(lái)自任何命名空間（除 SOAP 命名空間之外）的任意數量的元素。 放置在 Header 元素中的各個(gè)元素被稱(chēng)為標頭塊。 如同其他協(xié)議一樣，標頭塊中包含的信息應該能夠影響有效負載的處理。 因此，這里正適于放置諸如憑證一類(lèi)的元素，以幫助控制對操作的訪(fǎng)問(wèn)：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><!-- security credentials --><s:credentials xmlns:s="urn:examples-org:security"><username>dave</username><password>evad</password></s:credentials></soap:Header><soap:Body><x:TransferFunds xmlns:x="urn:examples-org:banking"><from>22-342439</from><to>98-283843</to><amount>100.00</amount></x:TransferFunds></soap:Body></soap:Envelope>
我們也可以利用一個(gè)名為 mustUnderstand 的全局 SOAP 屬性對標頭塊進(jìn)行標注，以指明接收方在處理該消息之前是否需要理解標頭。 以下示例說(shuō)明了如何要求對憑證標頭進(jìn)行處理：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><!-- security credentials --><s:credentials xmlns:s="urn:examples-org:security"soap:mustUnderstand="1"><username>dave</username><password>evad</password></s:credentials></soap:Header>...
如果某個(gè)標頭塊被標注為 mustUnderstand="1"，而接收方未設計為支持給定的標頭，則不應處理該消息，而應該向發(fā)送方返回一條 Fault （帶有 soap:MustUnderstand 狀態(tài)碼）。 如果 mustUnderstand="0" 或者沒(méi)有提供 mustUnderstand 屬性，則接收方可以忽略相應的標頭塊并繼續進(jìn)行處理。 在整個(gè) SOAP 處理模塊中，mustUnderstand 屬性起著(zhù)核心作用。
返回頁(yè)首處理模型
SOAP 定義了一種處理模型，它大致規定了從 SOAP 發(fā)送方傳輸到 SOAP 接收方的過(guò)程中對 SOAP 消息的處理規則。
圖 1說(shuō)明了最簡(jiǎn)單的 SOAP 消息處理方案，其中一個(gè)應用程序（SOAP 發(fā)送方）向另一個(gè)應用程序（SOAP 接收方）發(fā)送一條 SOAP 消息。
但是，處理模型允許使用一些更有趣的結構（如圖 3 中的結構），這類(lèi)結構中包含多個(gè)中間 節點(diǎn)。 在下文中，將使用 SOAP 節點(diǎn) 這個(gè)術(shù)語(yǔ)指代任何要處理 SOAP 消息的應用程序，不管是最初的發(fā)送方、中間節點(diǎn)還是最終的接收方；否則，我將明確指出并使用相應的準確術(shù)語(yǔ)。
圖 3. 高級 SOAP 消息處理
中間節點(diǎn)位于最初的發(fā)送方和最終的接收方之間，并截獲 SOAP 消息。 中間節點(diǎn)可同時(shí)作為 SOAP 發(fā)送方和 SOAP 接收方。 中間節點(diǎn)使得有可能設計一些有趣且靈活的網(wǎng)絡(luò )體系結構，而這些網(wǎng)絡(luò )結構能受到的消息內容影響。 SOAP 路由就是一個(gè)很好的示例，它很大程度上利用了 SOAP 中間節點(diǎn)（有關(guān) SOAP 路由的詳細信息，請查看
Routing SOAP Messages with Web Services Enhancements 1.0）。
在處理消息時(shí)，SOAP 節點(diǎn)承擔一個(gè)或者多個(gè)角色 (role)，這些角色會(huì )影響如何處理 SOAP 標頭。 各個(gè)角色被賦予獨特的名稱(chēng)（以 URI 的形式），以便在處理過(guò)程中能夠識別這些角色。 當 SOAP 節點(diǎn)接收到一條要處理的消息時(shí)，它首先必須確定要假定哪些角色。 它可以檢查該 SOAP 消息以幫助確定。
一旦 SOAP 節點(diǎn)確定了要扮演的角色，它隨后必須處理針對其角色之一的所有必要標頭（標記為mustUnderstand="1" ）。 SOAP 節點(diǎn)也可選擇處理針對其角色之一的任何可選標頭（標記為 mustUnderstand="0"）。
SOAP 1.1 只定義了一個(gè)名為 http://schemas.xmlsoap.org/soap/actor/next 的角色（簡(jiǎn)寫(xiě)為 next）。 每個(gè) SOAP 節點(diǎn)都必須承擔 next 角色。 因此，當 SOAP 消息到達任一給定的 SOAP 節點(diǎn)時(shí)，該節點(diǎn)必須處理針對 next 角色的所有必要標頭，它可以選擇處理針對該 next 角色的可選標頭。 除 next 外，SOAP 1.2 定義了另外一些角色（參見(jiàn)
表 3），且應用程序也可以定義自定義角色。
SOAP 標頭通過(guò)全局 actor 屬性（在 SOAP 1.2 中該屬性名為 role ）來(lái)指定具體的角色。 如果不存在 actor 屬性，則標頭默認地指向最終的接收方。 以下 SOAP 消息說(shuō)明了如何使用 actor：
<soap:Envelopexmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp"soap:actor="http://schemas.xmlsoap.org/soap/actor/next"soap:mustUnderstand="1">...
由于 wsrp:path 標頭被指定為 next 角色且被標記為必要的 (mustUnderstand="1")，因此接收到此消息的第一個(gè) SOAP 節點(diǎn)必須根據該標頭塊的規范來(lái)處理此消息，在這種情況下為 WS-Routing。 如果 SOAP 節點(diǎn)不理解針對其角色之一的某個(gè)必要的標頭，則它必須產(chǎn)生一個(gè)帶 soap:MustUnderstand 狀態(tài)碼的 SOAP 錯誤，并停止處理。 SOAP Fault 元素提供了faultactor 子元素，以指定在消息路徑中哪個(gè)節點(diǎn)導致了該錯誤的發(fā)生。faultactor 屬性的值是一個(gè) URI，用以標識導致該錯誤的 SOAP 節點(diǎn)。
如果 SOAP 節點(diǎn)成功地處理了一個(gè)標頭，則它必須從消息中刪除該標頭。 SOAP 節點(diǎn)可以再插入標頭，但是這樣做會(huì )改變合同方 — 它現在處于當前節點(diǎn)與該標頭所指向的下一節點(diǎn)之間。 如果 SOAP 節點(diǎn)恰好是最終的接收方，則它還必須處理 SOAP 主體。
表 3. SOAP 1.2 角色
SOAP 角色名稱(chēng)
•
http://www.w3.org/2002/06/soap-envelope/role/next•
http://www.w3.org/2002/06/soap-envelope/role/none•
http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver說(shuō)明
•
每個(gè) SOAP 中間節點(diǎn)和最終的 SOAP 接收方必須 (MUST) 扮演此角色，并可以 (MAY) 另外承擔零個(gè)或多個(gè)其他 SOAP 角色。
•
SOAP 節點(diǎn)絕不可以 (MUST NOT) 扮演此角色。
•
要將某個(gè) SOAP 節點(diǎn)確立為最終的接收方，該 SOAP 節點(diǎn)必須 (MUST) 扮演此角色。 SOAP 中間節點(diǎn)絕不能 (MUST NOT) 扮演此角色。
返回頁(yè)首協(xié)議綁定
圖 3中一個(gè)有趣之處是 SOAP 允許通過(guò)多種底層協(xié)議進(jìn)行消息交換。 由于 SOAP 消息處理框架獨立于底層協(xié)議，每個(gè)中間節點(diǎn)可以選擇使用不同的通信協(xié)議而不會(huì )影響 SOAP 消息。 然而，為了確保各種 SOAP 應用程序和基礎結構之間高級別的互操作性，標準的協(xié)議綁定是必要的。
一種具體的協(xié)議綁定準確地定義了應該如何利用給定的協(xié)議來(lái)傳輸 SOAP 消息。 換言之，它詳細定義了 SOAP 如何適用于另一協(xié)議的范圍，該協(xié)議很可能具有自己的消息處理框架以及多種標頭。 協(xié)議綁定實(shí)際所定義的內容很大程度上取決于該協(xié)議的功能和選項。 例如，針對 TCP 的協(xié)議綁定應很大程度不同于針對 MSMQ 或針對 SMTP 的協(xié)議綁定。
SOAP 1.1 規范僅規范化了一種用于 HTTP 的協(xié)議綁定（由于 HTTP 的廣泛使用）。 SOAP 已經(jīng)用于 HTTP 之外的很多協(xié)議，但是其實(shí)現并未遵循標準化的綁定。 當你嘗試與利用相同協(xié)議的其他 SOAP 實(shí)施進(jìn)行集成時(shí)，只要準備好處理各種互操作性方面的問(wèn)題，超前一點(diǎn)而不使用標準的協(xié)議綁定也未嘗不可。
返回頁(yè)首HTTP 綁定
HTTP 協(xié)議綁定定義了在 HTTP 上使用 SOAP 的規則。 SOAP 請求/響應自然地映射到 HTTP 請求/協(xié)議模型。 圖 4 說(shuō)明了 SOAP HTTP 綁定的很多細節。
圖 4. SOAP HTTP 綁定
HTTP 請求和響應消息的 Content-Type 標頭都必須設為 text/xml （在 SOAP 1.2 中是 application/soap+xml）。 對于請求消息，它必須使用 POST 作為動(dòng)詞，而 URI 應該識別 SOAP 處理器。 SOAP 規范還定義了一個(gè)名為 SOAPAction 的新 HTTP 標頭，所有 SOAP HTTP 請求（即使是空的）都必須包含該標頭。 SOAPAction 標頭旨在表明該消息的意圖。 對于 HTTP 響應，如果沒(méi)有發(fā)生任何錯誤，它應該使用 200 狀態(tài)碼，如果包含 SOAP 錯誤，則應使用 500。
返回頁(yè)首RPC 和編碼
盡管 SOAP 規范已日漸遠離對象，它仍然定義了一種約定，以便利用上述的消息處理框架來(lái)封裝并交換 RPC 調用。 定義一種標準的方法將 RPC 調用映射到 SOAP 消息，這使得在運行時(shí)基礎結構可以在方法調用和 SOAP 消息之間自動(dòng)轉換，而不用圍繞 Web 服務(wù)平臺重新設計代碼。
要利用 SOAP 進(jìn)行方法調用，基礎結構需要以下信息：
•
1.終結點(diǎn)位置 (URI)
•
2.方法名稱(chēng)
•
3.參數名稱(chēng)/值
•
4.可選的方法簽名
•
5.可選的標頭數據
這些信息可以通過(guò)多種方法來(lái)傳輸，包括類(lèi)型庫、IDL 文件，或者，更好的是 WSDL 文件。 SOAP RPC 綁定定義了如何在 SOAP 主體中封裝并表示這些信息。 為此，RPC 綁定首先定義如何將方法簽名映射到簡(jiǎn)單的請求/響應結構，然后將這些結構以 XML 進(jìn)行編碼。 RPC 綁定規定將以一個(gè)按照方法命名的 struct 來(lái)模擬該方法調用。 該結構將包含對應于每個(gè) [in] 或 [in/out] 參數的一個(gè)訪(fǎng)問(wèn)器，訪(fǎng)問(wèn)器的名稱(chēng)與參數名相同，其次序由消息簽名確定。 方法響應也將作為一個(gè)結構來(lái)建模。 結構的名稱(chēng)無(wú)關(guān)緊要，盡管約定是使用方法名后跟 "Response"（例如，對于 add 操作，方法響應名應該相應為 addResponse）。 響應結構包含一個(gè)用于返回值的訪(fǎng)問(wèn)器（其名稱(chēng)在 SOAP 1.1 中無(wú)關(guān)緊要，但在 SOAP 1.2 必須是 rpc:result），其后是針對每個(gè) [out] 或 [in/out] 參數的訪(fǎng)問(wèn)器。
讓我們來(lái)看一個(gè)示例。 假設 add 操作具有以下的 C# 方法簽名：
double add(ref double x, double y)
根據剛才所說(shuō)明的 RPC 綁定規則，代表該方法調用的請求結構應如下建模：
struct add {double x;double y;}
而響應結構如下：
struct addResponse {double result;double x;}
現在的問(wèn)題是： 應該如何將這些結構映射到 XML(R) SOAP 規范定義了一組編碼規則，專(zhuān)門(mén)用于此用途。 SOAP 編碼規則大致闡述了如何將當今最常用的數據結構（如結構和數組）映射到普通的 XML 格式。 根據 SOAP 編碼規則，以上的請求結構應映射到以下 XML 消息（這將放在 SOAP 主體中）：
<add><x>33</x><y>44</y></add>
且上述請求的響應消息將映射到以下 XML 消息（這個(gè)消息將進(jìn)入響應消息的主體）：
<addResponse><result>77</result><x>33</x></addResponse>
XML 架構的相關(guān)工作剛剛開(kāi)始，SOAP 編碼規則即已創(chuàng )立。 既然 XML 架構已經(jīng)完成，開(kāi)發(fā)人員可以簡(jiǎn)單地提供文字的 XML 架構定義，從而準確指定應該如何以 XML 來(lái)格式化請求/響應消息。 由于利用 XML 架構定義更易于獲得互操作性，因此大多數開(kāi)發(fā)人員已經(jīng)決定完全摒棄 SOAP 編碼規則。 實(shí)際上，自 SOAP 1.2 起，SOAP 規范不再正式要求支持 SOAP 編碼規則。 從現在起，最好避免使用 SOAP 編碼規則，有關(guān)此中原由的全面討論，請查看
關(guān)于 SOAP 編碼的討論一文。
盡管 SOAP RPC 綁定和編碼規則為那些不愿意涉及諸如 XML 架構和 WSDL 等的應用程序提供了一個(gè)很好的 SOAP 集成層，因為 RPC 綁定和編碼規則易于導致互操作性方面的問(wèn)題，它們基本上已經(jīng)失寵于 Web 服務(wù)社區。
返回頁(yè)首SOAP 類(lèi)型
要重申的是，如今有兩種基本類(lèi)型的 SOAP 消息處理： 文檔和 RPC。 文檔類(lèi)型指出主體只是包含一個(gè) XML 文檔，而發(fā)送方和接收方都必須遵循該文檔的格式。 另一方面，RPC 類(lèi)型指出主體中包含某個(gè)方法調用的 XML 表示，正如剛才所述。
兩種方法可用于確定如何將數據序列化到主體中： 使用文字的 XML 架構定義和使用 SOAP 編碼規則。 利用前一種方法，架構定義逐字確定了主體的 XML 格式，不具有二義性。 然而，利用后一種方法，SOAP 處理器必須在運行時(shí)遍歷各種 SOAP 編碼規則以確定主體正確的序列化。 很顯然，這種方法更易于導致錯誤和互操作性方面的問(wèn)題。
最常見(jiàn)的情形是在使用文檔類(lèi)型時(shí)也使用文字架構定義（稱(chēng)為文檔/文字），以及在使用 SOAP 編碼規則時(shí)使用 RPC 類(lèi)型（稱(chēng)為 rpc/編碼）。 文檔/編碼和 rpc/文字也是可能的，但并不常見(jiàn)，也沒(méi)有太大意義。 大多數 Web 服務(wù)平臺都集中于文檔/文字類(lèi)型，將其作為發(fā)展的主要用例，且是現今 Microsoft ASP.NET WebMethod 框架的默認設置。
返回頁(yè)首小結
SOAP 定義了一種簡(jiǎn)單而可擴展的 XML 消息處理框架，它可以通過(guò)多種協(xié)議用于各種不同的編程模型，盡管此規范中規范化了如何將 SOAP 用于 HTTP 和 RPC 調用。 SOAP 還定義了一個(gè)完整的處理模型，大致規定了當消息沿路徑傳送時(shí)如何對其進(jìn)行處理。 總的來(lái)說(shuō)，SOAP 提供了一個(gè)功能豐富而靈活的框架以便定義高級應用程序協(xié)議，這些協(xié)議可在分布式異構環(huán)境中提供更好的互操作性。
