|
在電影Fight Club（“戰爭俱樂部”）中，Brad Pitt和Edward Norton是一對密友——心理上對立的兩個極端——兩
個小伙子嘗試互相 通信，但十分艱難。令人感興趣的是——沒有給出提示臺詞——影片中 的大部分劇情都
圍繞著肥皂的生產進行，看上去像是把多個角色以獨一 無二的、令人意想不到的方式綁在了一起。
現在快進到一種不同類型的劇情，Microsoft和Sun這兩個軟件密友 在Internet也出演了這段劇情，他們每一方都
用經過良好定義的視點， 試圖彌合彼此間的差異，并與另一方之間建立一條通信線路。進入SOAP ，即簡單
對象訪問協議。
簡介
SOAP，簡單地講，就是允許Java對象和COM對象在分布式、分散的、 基于Web的環境中彼此通話。更一般地
講，SOAP允許任何類型的對象（或 代碼）——在任何平臺上，以任何一種語言——相互通信。目前，已在
2 0多個平臺上，以60多種語言實現了SOAP。突然之間，任何地方的對象， 無論本地或遠程的，無論大或小，
都可以互操作。Brad Pitt和Edward Norton，就像兩種截然不同的對象，最終能夠通信。
回顧一下這種技術，我最開始將在Web服務的大環境下介紹SOAP， SOAP作為一種協議，它與UDDI（通用
描述、發現和集成）一起提供了業 務間注冊和消息傳遞服務。我還將討論揭示“發布-查找-綁定”范例的
基于Web的基礎，并介紹SOAP包裝、傳輸和發送機制。
Web服務的發展
先把所有大肆張揚的宣傳放在一邊，SOAP僅僅只是一種組件——雖然 是一種中心組件——用于把Web的藍
圖描述成用于業務操作的、基于標準 的、語言與平臺中性的架構。這些業務操作通常被標上了“Web 服務”
的通用標簽，但是Web服務自身也只是一種支持它們的良好的基礎。相應 地，Internet有一種快捷的n層基礎。
網絡分層
在Web服務的發展過程中，有3種網絡層是顯而易見的：TCP/IP、 HTTP/HTML和XML?，F在這3個層相繼構建
在彼此的頂上，并保持相互之間 的兼容性。
第1層，TCP/IP協議，主要關注的是以分組形式通過線纜傳輸數據。 作為一種確保通過公共網絡傳輸的協議，
TCP/IP強調數據傳輸的可靠性 和物理連通性。起初是把專用網絡粘合在一起，現在則是用Web中樞協議 來連
接網絡，更高層次的標準協議如HTTP就是依賴于這種中樞協議的。
第2層，HTTP上的HTML，它是一個顯示層，自身關注的是基于瀏覽器 的搜索、檢索和信息共享。它強調的是
基于GUI（圖形用戶界面）的導航 和顯示格式的處理。在許多方面，HTML更多地是用于顯示，而不是轉到 別
的網頁上，并且在可擴展性和真正的編程能力上有所欠缺。雖然如此， 在瀏覽器環境中共享超文本鏈接的文
檔使人們用基于文本的信息與他人 通信的方式引發了革命。網絡桌面環境，受專用操作系統和依賴于平臺 的
軟件所限，速度緩慢，毫無疑問會讓路于基于標準的，對系統開放的 Internet。
把這種責任引導到這個勇敢的、新的、基于標準的世界的是XML，它 是Internet的第3層，也可能是最引人注目
的一層。XML，一種強類型數 據交換格式，它為HTTP/HTML層提供了一個新范圍。在XML層中，機器到
機器的通信有可能通過標準接口來進行。XML層——有多種不同的描述， 如A2A（應用程序到應用程序）、
B2B（業務到業務）、或C2C（計算機到 計算機）——允許程序在平臺上交換數據格式——和顯示——獨立于
編 程的方式。XSLT樣式表可以作為一種可選用的顯示和/或可傳輸的組件予 以添加。
XML：描述Web服務的關鍵
把這種可能變為現實的關鍵是實現機器到機器的通信，這是XML力所 能及的。作為一種描述數據的詞法，
XML是定義驅動的（通過使用DTD和 架構），并允許以編程方式處理信息。這意味著大多數可考慮到的工作
都可以從B2B通信中取出來?？梢杂幸恢碌臉擞洠梢远x接口，處理也 可以是標準化的。Web服務是可重
用的組件程序，它們把XML用作一種標 準的、可擴展的通信架構，以方便機器到機器類型的通信。
Web服務為通過HTTP傳輸的組件數據和業務邏輯提供接口。大量的數 據被放置在服務器端腳本后面的一個
傳統的位置，等待著被Web瀏覽器或 客戶程序訪問。Web服務承諾使許多企業領域的、處于閑置狀態的公司
軟 件資源獲得新生。
在把駐留于Web中的數據集成到企業應用程序中和協調用于組件片固 定的業務邏輯方面，XML起了至關重要
的作用。特定的業務邏輯和服務 （包括工作流程邏輯、業務邏輯、組件序列邏輯、交易邏輯等）可以封 裝在
XML文檔中，并集成到現有的業務環境中去。這允許業務在內部資源 和Web服務之間，簡化業務交易邏輯和
通過Web提供鏈條式交互之間起到 杠桿作用。
由于XML是人們可閱讀的和基于文本的，使之可理想地用作傳輸松耦 合的Web服務的架構。最低限度是：
自動化的交易可提高生產率、減少費 用和改善服務。網絡標準的存在使自動化交易成為可能、使所有成員的
生產率都能得到提高。
SOAP是一種源于更早的基于XML標準的技術，早期XML標準在某種意義 是指一種稱為 ebXML（電子商務
XML）的顯示標準。EbXML具有一種依次進行的連續 邏輯，它在貿易合作者間提供了一種共享業務消息的
綜合定義。SOAP適用 的范圍更普遍，也更容易實現。
松耦合的系統
Web服務把對象從管理它們的平臺上分離開來，也就是說，Web服務使 獨立于平臺的對象之間的交互更容易
，對象可以訪問Web上任何地方的數 據。作為脫離專用平臺的一部分，Web服務依賴于松散而不是緊密耦合
的 Web組件。根據Brian Travis（SOAP顧問和作者）的觀點，“依賴于專用 對象的系統被認為是耦合緊密的，
因為它們依賴一種定義良好但很脆弱 的接口。如果應用程序與服務對象間通信的任何部分被打斷，或者如果
調用不完全正確，將會發生不可預料的結果。”EDI就是一個用于執行電 子商務的耦合緊密的架構的例子。
松耦合的系統允許在開放的、
分布式 Web環境中進行靈活的和動態的交換。
CORBA第二次降臨
網絡上的公司——IBM、BEA、Sun，僅舉幾個例子——同時在與他們 競爭的公司合作。標準化的網絡傳輸協
議，獨立于平臺的編程語言如： Java、XML和特定行業的專業用語，及開放的基于組件的服務器體系結構
使每個人都能免費享用非專用的資源?，F在，Web服務，帶著其對包含廣 泛的應用程序互操作性的承諾，就
像一種最終的“膠水”，使這些技術 交互作用，即使不是無縫的，至少也不會超過以前技術如CORBA和RMI
所 帶來的累贅。
在某種意義上，Web服務代表著CORBA的第二次降臨。但是CORBA是一 種面向對象的、基于IIOP的二進制
通信架構，是由基礎、骨架和特定于 供應商的ORB裝載而成的；而Web服務則是輕型的、基于HTTP的、XML
驅動 的及平臺和語言完全中性的。如果說CORBA是一只重達600磅的大猩猩， 那么Web服務就是一只小羚羊，
在遼闊的Internet禁區里自由地蹦跳。
發布、綁定和查找
Web服務的架構由發布-查找-綁定這個周而復始的循環組成，它通過 服務提供程序使數據、內容和服務能
為注冊的服務請求者所用，服務請 求者通過定位和綁定到服務來使用資源。請求應用程序使用 WSDL
（Web服務描述語言）把請求者轉到Web服務上。WSDL為想要的 服務提供了一種低層次的技術信息，
并授權訪問關于數據編碼的XML架構 信息、及通過正確的協議確保調用正確的操作。
發布、綁定和查找機制，在3個獨立（但有些等同）的協議中有它們 各自的副本，這3個協議是WSDL、
SOAP和UDDI（通用描述和發現接口）， 它們組成了Web服務網絡棧。
對CORBA作更深層次的類推可以發現，SOAP起到了CORBA中IIOP（或RMI 中的JRMP）的作用。它是對立
的端點間的綁定機制。另一方面，WSDL起 到了IDL（接口描述語言）的作用。在這種功能上，WSDL把
Web服務定義 成端口和操作的集合。WSDL端口是模擬接口的，而WSDL操作則是模擬方 法的。WSDL
把Web服務接口發布給那些對跨越不同平臺通信感興趣的各 方。
但是，WSDL已經超越了一種接口定義語言；它還包含允許給想發布的 Web服務描述地址和協議信息的
構造。關于WSDL的令人感興趣的事情是它 為Web服務描述了一個抽象接口，同時還允許您——以難以
忍受的細節 ——綁定Web服務給特定的傳輸機制，如HTTP。通過使接口抽象化，WSDL 可用作一種可重
用的Web服務技術。通過綁定到特定的傳輸機制，WSDL生 成了抽象的類聚。如果這看上去有些自相矛盾，
可以想一下航天飛機： 它是可重復使用的、但要把全機能太空艙完全綁定到專用的、但不可重 復使用的
助力器火箭上。傳輸機制可能會改變，但有效載荷會保留下來 。
最后，UDDI是用于注冊發布和查找Web服務的。在基于Web的注冊中， 通過顯示服務信息和綁定接口，
UDDK為業務和客戶提供了一個共享目錄 以查找別人的Web服務。
構建Web服務
SOAP可通過遠程調用對象上的方法，讓您構建應用程序。SOAP消除 了兩種系統必須運行于同一平臺上、
且必須是用同一種編程語言編寫而 成的要求。SOAP包不是通過專用的二進制協議調用方法，而是使用
XML 這種基本文本的詞法來調用方法。請求應用程序與接收對象之間的所有 信息，是作為XML流中的
標記數據通過HTTP發送的。從Web服務的角度來 看，SOAP可以看作一種客戶端或服務器實現。
SOAP客戶端和服務器
SOAP客戶端是一種創建XML文檔的程序，該XML文檔包含在分布式系 統遠程調用方法所需的信息。SOAP
客戶端不是傳統意義上的程序，它除 了用作普通的桌面應用程序外，還可以是一種Web服務器或基于服務
器 的應用程序。
來自SOAP客戶端的消息和請求一般是通過HTTP發送的。因而，SOAP 文檔可以穿過幾乎所有的防火墻，
從而能跨越不同的平臺交換信息。
SOAP服務器只是用于監聽SOAP消息的特殊代碼，它可用作SOAP文檔的 分配器和解釋器。外部Web服
務可以與基于J2EE技術的應用程序服務器交 互，這種應用程序服務器可以處理多種客戶端的SOAP請求。
SOAP服務器確保通過HTTP連接接收的文檔被轉換成可以被另一端對 象理解的語言。由于所有的通信都采
用XML格式，某種語言（比如說 Java）中的對象可以通過SOAP與另一種語言（如C++）中的對象通信。
SOAP服務器的工作就是確保各端都能理解——并且滿意——為它們提供 服務的SOAP。
SOAP和Java技術
根據SOAP 1.1規范，SOAP是“一種用于在分散的、分布式環境中交換 信息的輕型協議”。SOAP不會委
托單一的編程模型——也不會為特定的 編程語言定義語言綁定。在Java編程語言環境中，它取決于Java
團隊來 定義特定的語言綁定?，F在Java語言綁定通過JAX-RPC來集中定義。
在最近的JavaOne開發人員討論會上對SOAP的討論中，Sun公司的工程 師Roberto Chinnici和Rahul Sharma把
JAX技術家庭的作用定義成“使用 熟悉的、用于Java平臺的JSP和EJB組件技術創建Web服務”。Servlets
和無狀態會話bean被引用作兩種最可能用于封裝Web服務的Java技術。
什么是SOAP？真的嗎？
我們已經徹底設置好了SOAP舞臺，并描述了其在Web服務中至關重要的作用， 現在進一步看看SOAP
到底是什么，它執行什么任務，以及是怎樣執行的？
SOAP是一種可擴展的、基于文本的架構，它允許在不同角色之間通信，這里的 角色一般是指對象，
它們先前并不了解對方或對方所在的平臺。從網絡對象的角 度來看，SOAP是它們的最后不可見形式。
客戶端應用程序可以在松耦合的環境中 互操作，以發現和動態地連接到服務，而這并不需要事先在應
用程序與服務之間 建立一種協定。
SOAP是可擴展的，這是因為無需中斷已有的應用程序，SOAP客戶端、服務器和 協議自身都能發展。
而且SOAP能極好地支持中間介質和層次化的體系結構。這意 味著處理節點可以把請求的路徑置于客
戶端與服務器之外。中間節點通過使用報 頭（用于標識哪個節點處理哪部分消息）來處理SOAP指定
的各部分消息。這種類 型的中間報頭處理是通過客戶端應用程序與中間處理節點之間的私人契約來執
行 的。SOAP為報頭提供了一個mustUnderstand屬性，它允許客戶端將 處理指定為是必須執行的還是
可選的。如果mustUnderstand被設置 為1，服務器必須執行報頭指定的中間處理或給出錯誤。
SOAP還定義了數據編碼規則，稱為基準編碼或“Section 5（第5節）”編碼， 它是出自SOAP規范中
描述數據編碼規則的那一節內容。應當指出SOAP編碼的內容 占了SOAP 1.1規范40頁中的大部分篇幅。
不必深入到XML數據類型細節——它仍然 是XML架構制定組的專家們研究的范疇——SOAP編碼可以
簡短地描述成簡單值或復 合值的集合。
簡單值可以是簡單類型，如整型、浮點型和字符型，或者是XML架構規范第2部 中定義的內置類型，
包括各種數據類型，如字節型數組和枚舉。
復合值包括結構、數組和XML架構制定組定義的復雜類型。最后，當然不是至 少，SOAP數據編碼指
定了對象序列化規則，即通過網絡排列和分散數據流的機制。 這些“Section 5”編碼在任何情況下都不
是強制性的，注意這點很重要，這樣客 戶端和服務器可以自由地使用不同的數據編碼規范，只要它們
符合格式就行。但 是這樣做的話，就會毀滅SOAP在網絡上提供標準化服務所起的推動作用，并且會
帶來一個常見的警告：已偏離航線太遠，單獨的客戶端和服務器可以選擇較短的 旅行路線。
最后，SOAP建立了一組規則，它允許客戶端和服務器把SOAP用作一種通信架構 來執行遠程過程調用
。SOAP——作為一種面向消息的協議——可以使用這些規范 像RPC類型的型一樣良好地工作。對象序
列化的機制給SOAP-RPC提供了活力。
消息格式
SOAP在標準化消息格式環境中，可以做所有它能完成的工作。消息的主體部分 是“text/xml”形式的
MIME類型，并且包含一個SOAP封套。該封套是一個XML文 檔。封套包含了報頭（可選的）和報文
（必須有的）。封套的報文部分總是用于 最終接收的消息，而報頭項目可以確定執行中間處理的目標
節點。附件、二進制 數字及其他項目可以附加到報文上。
SOAP提供了一種讓客戶端指定哪個中間處理節點必須處理報頭項目的方法。由 于報頭與SOAP消息的
主體內容是互不相關的，所以可用它們給消息添加信息，而 不會影響對消息報文的處理。
例如，報頭可用于為報文中包含的請求提供數字簽名。在這種情形下，身份驗 證/授權服務器可以處理
報頭項目——獨立于報文——可以剝離信息以驗證簽名。 一旦通過驗證，封套的其余部分將被傳遞給
SOAP服務器，它將對消息的報文進行 處理。深入研究一下SOAP封套，有助于明了SOAP報頭和報文
元素的位置和用途。
剖析SOAP封套
SOAP 1.1規范提供了下面的封套示例：
<SOAP-ENV: Envelopexmlns: SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"SOAP-ENV: encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Header>
<t:Transaction xmlns:t="some-URI">SOAP-ENV:mustUnderstand="1" 5</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="some-URI">
<symbol>DEF</Symbol>
</m: GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-Envelope>
在這個例子中，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可擴展性的一個例子?？蛻舳嗽赟OAP消息中包含 這樣的節點，以在可
以處理消息的報文內容前，指示要發生的特殊的處理需要。 要保證向后兼容不能提供這種處理的現有
的服務器，只需把mustUnderstand 屬性設置為0，它使操作是可選的。
除了定義像上例中所示的transaction節點外，SOAP消息還可包含報頭項目， 它們用于指定節點執行身
份驗證處理、加密、狀態的永久性、業務邏輯處理等。 報頭有助于把SOAP構建成一種可擴展的模態
包模型。只需記住報頭處理是完全獨 立于SOAP消息的報文的。
報文
上面例子中的SOAP報文包含一個XML載荷，我們可以推測RPC沒有為我們對其作 詳細解釋。SOAP不僅
是一種模態包模型，它還是一種相當神秘的包模型。
沒有什么跡象清楚地顯示RPC將要開始做什么。我們在報文中所看到的是幾個 XML元素，其中一個用
命名空間進行了限制。它取決于SOAP服務器理解文檔語義并 執行正確的處理。事實上，服務器提供了
一種架構，以有意義的方式處理XML載 荷。這里的“有意義”意味著服務器在某些后臺數據庫上調用
遠程過程，以為消 息報文中包含的股票-符號元素接收股票價格。所有這些魔術般的操作都是在SOAP
RPC幕后發生的。
SOAP-RPC
SOAP消息本質上是一種從發送方到接收方的單向傳輸，但是SOAP經常組合到實 現請求/響應機制中。
要讓RPC使用SOAP，必須遵循幾條規則。首先，請求和響應 消息必須被編碼成結構類型。對一個操
作的每一個輸入參數，都必須有一個同名 元素（或輸入結構的成員）作為參數。對每一個輸出參數，
都必須有一個名稱匹 配的元素（或輸出結構的成員）。
基于RPC的觀點，會省略一些更早一點顯示的SOAP消息。只帶有報文部分的 SOAP請求與響應封套如
下所示：
請求 <SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="some-URI">
<symbol>DEF</Symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>響應
<SOAP-ENV:Body>
<m:GetLastTradePriceResponse xmlns:m="some-URI">
<price>22.50</price>
</m: GetLastTradePriceResponse>
</SOAP-ENV:Body>
請求要調用GetLastTradePrice方法。注意響應定義了 GetLastTradePriceResponse操作。對附加響應到響應
操作尾部的 一個常用的SOAP調用規則是：創建響應結構。這種輸出結構包含一個名稱為 price的元素，
它返回方法調用的結果，假定為浮點型。
在SOAP封套中沒有什么地方的數據類型是顯式聲明的，注意到這一點很重要， 這樣如果只查看
SOAP消息，就不會知道符號類型或結果參數price（價格）的類 型。客戶端應用程序一般通過
“Section 5”編碼定義數據類型，或通過與服務器 私下達成的協議來定義數據類型。在任何一種情況下，
這些包含在SOAP消息中的 定義都不是顯式的。
最后，為了進行RPC，需要一種低級協議如HTTP。盡管SOAP 1.0規范強制要求 使用HTTP作為傳輸協議
，但SOAP 1.1規范（及其姊妹規范“帶有附件的SOAP消息” ）允許使用FTP、SMTP、甚至（可能）
原始的TCP/IP套接字。所有這些對SOAP通用 的序列化和編碼規則，也適用于RPC參數。
SOAP用例
現在您看到的就是詳細的SOAP封套圖，它能幫助我們后退一步從用例的角度觀 察SOAP，以幫助我們
領會
在分布式Web環境中一個來回的處理過程。此處列出了幾 條構成Web服務和SOAP的概念中樞的、顯目的、
概括性命題。
- Internet上某些地方的客戶端應用程序使用Web服務。
- Web服務（通過SOAP）顯示對象方法。
- 對象方法訪問Web上任意位置的遠程數據。
對這些網絡命題應用傳遞邏輯，我們可以為Web服務和SOAP下一個總的結論： 某些位置的客戶端可以使
Web上任意位置的數據。這就是所要證明的。
下面是更加詳細一點的用例。
- SOAP客戶端使用UDDI注冊來查找Web服務。不用直接操作WSDL，大多數情況 下SOAP應用程序將
- 硬連接到使用特定類型的端口和特定樣式的綁定，并且它將 通過UDDI動態配置要調用的、與發現的
- Web服務匹配的服務地址。
- 客戶端應用程序創建SOAP消息，它是一個可執行想要的請求/響應操作的 XML文檔。
- 客戶端把SOAP消息傳送給監聽SOAP請求的Web服務器上的JSP或ASP頁面。
- SOAP服務器解析SOAP包并在其領域調用合適的對象方法，在SOAP文檔中包 含的參數中傳遞。
- 在SOAP服務器接收消息之前，中間處理節點可以執行SOAP報 頭指示的特殊功能，可視情況確定
- 是否執行這步操作。
- 請求對象執行指示的功能，并返回數據給SOAP服務器，它把響應打包到 SOAP封套中。服務器把SOAP
- 封套包裹在要發送回請求機器的響應對象中，如 servlet或COM對象。
- 客戶端接收對象，剝離出SOAP封套并把響應文檔發送給最初發出請求的程 序，完成請求/響應循環。
小結
SOAP是一種基于XML的協議，它用于在分布式環境中發送消息，并執行遠程過 程調用。使用SOAP，
不用考慮任何特定的傳輸協議（盡管通常選用HTTP協議）， 就能使數據序列化。
用SOAP來構建平臺與語言中性的互操作系統是一個好的選擇?？傊?，SOAP和 Web服務已為在XML
上構建分布式應用程序基礎結構所需的一切都考慮好了。通過 解決COM和Java組件對象模型之間的沖
突，SOAP把多個平臺在訪問數據時所出現的 不兼容性問題減至最少。
先把這些討論放在一邊，SOAP是一種適用于所有類型的對象實體的理想的媒介 ——即使對于像
Brad Pitt和Edward Norton之類的好萊塢電影角色——也可用作 一種通信媒介。就像在電影中一樣，
期待著這種新技術帶來震撼世界的效果。
參考文獻
《A Framework for Using Web Services》，作者：Simeon Simonov，刊登 《XML》雜志第2卷第6期上。
《SOAP 1.1 in the Java Platform: Introducing the JAX-RPC Technology》 ，Roberto Chinnici和Rahul Sharma在
2001年6月的JavaOne開發人員討論會上的 演講稿。
《理解SOAP》，作者：Kennard Scribner和Marc C. Stiver ，Sams出 版社2000年出版。（這本書非常吸引人，
該書的兩位作者從高度的技術層面揭示 SOAP和網絡技術，該書以流暢的風格，從最低層次的細節角度
宣揚了“呆在一個 地方，做所有的工作”的理念。該書是具有XML和Web服務經驗的開發人員成為
SOAP專家必讀的經典力作）。
《Writing Your First Web Service》, 作者： Andy McCright, 刊登在2001年 6月預發行的《Web服務》雜志上。
《XML and SOAP Programming for BizTalk Servers》, 作者： Brian E. Travis, Microsoft 出版社2000出版。
(不要讓這本書的書名迷惑了你， 這是一本優秀的，介紹Web服務和SOAP的中，高級書籍， 其內容精彩，
結構組織非 常優秀。 其中介紹BizTalk最基本知識的內容占了全書很大比例，是一本適合于 初學者閱讀的經典的著作。
作者介紹
Tom Clements是一名技術類書籍和詩歌自由撰稿人，擅長于Java API、XML/XSLT、設備驅動程序及無線通
信等技術。
| SOAP：簡單對象訪問協議 |
| |
（SOAP：Simple Object Access Protocol） |
|
簡單對象訪問協議（SOAP）是一種輕量的、簡單的、基于 XML 的協議，它被設計成在 WEB 上交換結構化的和固化的信息。 SOAP 可以和現存的許多因特網協議和格式結合使用，包括超文本傳輸協議（ HTTP），簡單郵件傳輸協議（SMTP），多用途網際郵件擴充協議（MIME）。它還支持從消息系統到遠程過程調用（RPC）等大量的應用程序。
SOAP 包括三個部分：
- SOAP 封裝：它定義了一個框架，該框架描述了消息中的內容是什么，誰應當處理它以及它是可選的還是必須的。
- SOAP 編碼規則：它定義了一種序列化的機制，用于交換應用程序所定義的數據類型的實例。
- SOAP RPC 表示：它定義了用于表示遠程過程調用和應答的協定。
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 消息格式：
SOAP 標頭
<SOAP-ENV: Envelope
Attributes>
<SOAP-ENV:Body
Attributes
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
示例 1 ： 內嵌在 HTTP 請求中的 SOAP 消息
|
|
內嵌在 HTTP 請求中的 SOAP 消息
|
|
下面是一個包含將 SOAP 消息作為負載的 HTTP 應答消息。
示例 2 ： 內嵌在 HTTP 應答中的 SOAP 消息
|
|
內嵌在 HTTP 應答中的 SOAP 消息
|
|