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