【文章內(nèi)容簡介】 TTP 和 XML），這使我們可以對客戶完全隱藏執(zhí)行任務的細節(jié)，客戶只需要知道這個服務的 URL或方法調(diào)用使用的數(shù)據(jù)類型，而不需要知道該任務到底是一個在 Linux 上運行的還是一個在 Windows 上運行的用 Java 編程的 服務。 本論文中所研究的就 是網(wǎng)絡中 SOAP 協(xié)議的應用，主要是更深刻的理解 SOAP協(xié)議在網(wǎng)絡中客戶端和服務器端進行通信，信息交流的過程中如何實現(xiàn)，相對于其他協(xié)議有哪些優(yōu)點。而對于 Web 服務來講， SOAP 協(xié)議又有何獨特的意義。 簡單對象訪問協(xié)議 SOAP 原理及抓包分析 2 2 概論 Web Service 簡介 Web 服務（ Web Service）是基于 XML 和 HTTPS 的一種服務，其通信協(xié)議主要基于 SOAP，服務的描述通過 WSDL，通過 UDDI 來發(fā)現(xiàn)和獲得服務的元數(shù)據(jù)。 Web service 到底是什么；在什么情況下你應該使用 Web service。 分布式應用程序和 瀏覽器 研究一下當前的應用程序開發(fā)，你會發(fā)現(xiàn)一個絕對的傾向：人們開始偏愛基于瀏覽器的受客戶應用程序。這當然不是因為受客戶能夠提供更好的用戶界面，而是因為它能夠避免花在桌面應用程序發(fā)布上的高成本。發(fā)布桌面應用程序成本很高，一半是因為應用程序安裝和配置的問題，另一半是因為客戶和服務器之間通信的問題。 傳統(tǒng)的 Windows 富客戶應用程序使用 DCOM 來與服務器進行通信和調(diào)用遠程對象。配置好 DCOM 使其在一個大型的網(wǎng)絡中正常工作將是一個極富挑戰(zhàn)性的工作，同時也是許多 IT 工程師的噩夢。事實上，許多 IT 工程師寧愿忍受瀏覽器所帶來的功能限制，也不愿在局域網(wǎng)上去運行一個 DCOM。在我看來，結(jié)果就是一個發(fā)布容易，但開發(fā)難度大而且用戶界面極其受限的應用程序。極端的說，就是你花了更多的資金和時間，卻開發(fā)出從用戶看來功能更弱的應用程序。不信？問問你的會計師對新的基于瀏覽器的會計軟件有什么想法：絕大多數(shù)商用程序用戶希望使用更加友好的 Windows 用戶界面。 關于客戶端與服務器的通信問題，一個完美的解決方法是使用 HTTP 協(xié)議來通信。這是因為任何運行 Web 瀏覽器的機器都在使用 HTTP 協(xié)議。同時，當前許多防火墻也配置為只允許 HTTP 連接 。 Web 服務（ Web Service WS）通常指通過 Web 提供的各種服務。一個典型的WS 過程是：一個業(yè)務應用通過使用 HTTP 的 SOAP 協(xié)議向某個指定 URL 上的一個服務發(fā)出請求，這個服務接受并且處理該請求后返回一個響應。一個經(jīng)常被引用的例子是股票報價服務，服務的請求是詢問某股票的當前價格，服務的響應是該股票的價格。這是最簡單的 WS 例子，其請求幾乎瞬間即可被滿足，請求和響應是同一個方法調(diào)用的不同組成部分。另外一個例子是指定貨物高校配送線路的服務。其中，商店發(fā)出的請求中包含遞送的目的地，服務經(jīng)過處理后確定 成本最簡單對象訪問協(xié)議 SOAP 原理及抓包分析 3 低的配送線路。返回響應的時間取決于線路的復雜程度，因此有可能發(fā)送和相應的操作與請求分開進行。 WS 和 WS 的消費者通常都是交易者，這使得 WS 的主流是企業(yè)對企業(yè)（ B2B）間的業(yè)務處理。一個企業(yè)有可能使某些 WS 的提供者，同時又是其他 WS 的消費者。例如：對于一個香料批發(fā)企業(yè)，當他使用 WS 核對香草豆是否有活的時候，其角色時 WS 的消費者；當他把不同賣主的價格提供給未來消費者的時候，其角色又是 WS 的提供者。 WS 的體系結(jié)構 總的來說 Web Service 的體系結(jié)構由簡單對象訪問模型而來，把所有的應用實體都抽 象成服務，包括三個角色和三種基本此操作： 三個角色如下： 服務提供者（ Service Provide）：從商務角度看，它是指服務的所有者，從體系結(jié)構上來看，它是指提供服務的平臺。 服務請求者（ Service Requester）：從商務角度看，它是指需要請求特定功能的企業(yè)，從體系結(jié)構看，它是指查找和調(diào)用服務的客戶端應用程序。 服務代理（ Service Broker）：它是指用來存儲服務描述信息的信息倉庫（ Repository）。它負責為服務提供方發(fā)布服務，為服務請求方查找服務，并且將獲取服務的信息綁定給請求 方。 三種基本操作如下： 發(fā)布（ Publish）：服務提供者需要將服務進行一定的描述并發(fā)布到注冊服務器上。在發(fā)布操作中，服務提供者需要通過注冊服務器的神恩驗證才能對服務描述信息進行發(fā)布和修改。 查找（ Find）：服務請求方根據(jù)注冊服務器提供的規(guī)范接口發(fā)出查詢請求，從而獲取所需服務的相關信息。在查找操作中，一般有兩種查找模式。一種是瀏覽模式（ Browse Pattern），及服務請求方可以根據(jù)通用的分類標準來瀏覽或者通過一些關鍵詞來搜索，逐步縮小查找的范圍，直到找到滿足需要的服務，其查找結(jié)果是一系列服務的集合 。另一種是直接獲取模式（ Drill Down Pattern），即通過惟一的關鍵詞直接得到特定服務的描述信息，其查找結(jié)果是唯一的。 綁定（ Bind）：服務請求方通過分析從注冊服務器中得到的服務綁定信息，例如服務訪問路徑、服務調(diào)用的參數(shù)、返回結(jié)果、傳輸協(xié)議、安全要求等，對自己的系統(tǒng)進行相應配置，進而可遠程調(diào)用服務提供者所提供的服務。 對應上述三種操作，給出了三種標準如下： SOAP（ Simple Object Access Protocol，簡單對象訪問協(xié)議），它實現(xiàn)的是低層協(xié)議，定義了服務請求者和服務提供者 之間的消息傳輸規(guī)范。 SOAP 用 XML 描述簡單對象訪問協(xié)議 SOAP 原理及抓包分析 4 信息，用 HTTP 承貸消息。 SOAP 包括四部分：一是封皮，定義了描述消息和如何處理消息的框架；二是表達應用程序定義的數(shù)據(jù)類型實例的編碼規(guī)則（ SOAP 編碼規(guī)則）；三是 SOAP RPC 表示，定義遠程過程調(diào)用和應答的協(xié)議；四是 SOAP 綁定（ Bind），定義法如何使用底層傳輸協(xié)議進行 SOAP 消息的交換。 WSDL（ Web Services Description Language， Web服務描述語言），它是 Microsoft公司的 SDL（ Services Description Language）、 IBM 公司的 NASSL（ NetworkAccessible Services Specification Language）合并后被 W3C 接納所形成的標準。 WSDL 為服務提供者提供以 XML 格式描述 WS 請求的標準格式，將網(wǎng)絡服務描述為能夠進行消息交換的通信端點的集合，以表達一個 WS 能做什么，它的位置在哪里，如何調(diào)用它等。 UDDI（ Universal Discover、 Description 、 Integration 通用發(fā)現(xiàn)、描述、集成）它是在原有 Microsoft 提供的 DISCO（ Discription of Web Services） 和 IBM 提出的 。 Web 服務 Web 服務（ Web Service）是基于 XML 和 HTTPS 的一種服務，其通信協(xié)議主要基于 SOAP，服務的描述通過 WSDL，通過 UDDI 來發(fā)現(xiàn)和獲得服務的元數(shù)據(jù)。 Web 服務是提供由 HTML 等語言描述的信息， Web 瀏覽器是為了將這些信息提取出來在客戶端運行的軟件?；ヂ?lián)網(wǎng)是 Web 服務器的集合體。 從表面上看， Web service 就是一個應用程序，它向外界暴露出一個能夠通過Web 進行調(diào)用的 API。這就是說，你能 夠用編程的方法通過 Web 來調(diào)用這個應用程序。我們把調(diào)用這個 Web service 的應用程序叫做客戶。例如，你想創(chuàng)建一個Web service ，它的作用是返回當前的天氣情況。那么你可已建立一個 ASP 頁面，它接受郵政編碼作為查詢字符串，然后返回一個由逗號隔開的字符串，包含了當前的氣溫和天氣。要調(diào)用這個 ASP 頁面，客戶端需要發(fā)送下面的這個 HTTP GET請求： Web service 更精確的解釋： Web services 是建立可互操作的分布式應用程序的新平臺。作為一個 Windows 程序員，你可能已經(jīng)用 COM 或 DCOM 建立過基于組件的分布式應用程序。 COM 是一個非常好的組件技術，但是我們也很容易舉出COM 并不能滿足要求的情況。 Web 的服務器軟件成為 Web 服務器軟件，這種為了通過 HTTP 進行交換的后臺程序也稱為 HTTPd（ HTTP daemon） 。如表 21 簡單對象訪問協(xié)議 SOAP 原理及抓包分析 5 表 21 Web服務器軟件 Web 服務器軟件 運行環(huán)境 說明 IIS（ Inter Information Serber） WindowsNT/2021 Serber 是在 Windows 系列網(wǎng)絡OS 的 NT 或 2021 上運行的 Web 服務器軟件同 OS捆綁在一起或者實地安裝提供 ASP 環(huán)境的服務器有增加的傾向 Apache 主要是 UNIX 系列的 OS（也有對應于WindowsNT/2021/98/Me） 是以 NCSA HTTPd 的 版本為基礎，進行了各種各樣的功能擴展而發(fā)布了的 Web 服務器軟件之一 簡單對象訪問協(xié)議 SOAP 原理及抓包分析 6 3 SOAP 協(xié)議 SOAP 協(xié)議 隨著計算機技術的不斷發(fā)展，現(xiàn)代企業(yè)面臨的環(huán)境越來越復雜，其信息系統(tǒng)大多數(shù)為多平臺、多系統(tǒng)的復雜系統(tǒng)。這就 要求今天的企業(yè)解決方案具有廣泛的兼容能力，可以支持不同的系統(tǒng)平臺、數(shù)據(jù)格式和多種連接方式，要求在 Inter 環(huán)境下，實現(xiàn)系統(tǒng)是松散耦合的、跨平臺的，與語言無關的，與特定接口無關的，而且要提供對 Web 應用程序的可靠訪問。 隨著異種計算環(huán)境的不斷增加，各種系統(tǒng)間的互操作性就愈顯得必要，要求系統(tǒng)能夠無縫地進行通信和共享數(shù)據(jù)，從而在 Inter 環(huán)境下，消除巨大的信息孤島，實現(xiàn)信息共享、進行數(shù)據(jù)交換，達到信息的一致性。 Web services 希望實現(xiàn)不同的系統(tǒng)之間能夠用 軟件 軟件對話 的方式相互調(diào) 用，打破了軟件應用、網(wǎng)站和各種設備之間的格格不入的狀態(tài)，實現(xiàn) 基于 WEB 無縫集成 的目標。 今年四月份的時候， W3C 聯(lián)盟召開了第一次 Web 服務專題研討會，目的為探索 W3C 應向哪個方向發(fā)展才能實現(xiàn)新興的 Web 服務架構的標準化，期間提出了一個 Web 服務堆棧 的構想，如下圖，從圖中可以看出， SOAP 在 WEB 服務堆棧中作為用于 XML 消息傳遞的一種非常普遍的協(xié)議，發(fā)揮著十分重要的作用。 圖 31 SOAP 在 WEB 服務堆棧中的作用 簡單對象訪問協(xié)議 SOAP 原理及抓包分析 7 SOAP 消息 1．第一個例子闡明了 SOAP 中一個簡單的通信信息，包括了兩個不是 SOAP定義而是應用程序定義的元素：頭塊元素 alertcontrol 和體塊元素 alert。頭塊元素包括兩個參數(shù)： priority 和 expires。體塊元素包括的是實際傳送的信息。 圖 32 SOAP 中一個簡單的通信信息 2． SOAP 通信與底層的不同協(xié)議和不同的交換格式有關，下面的例子 SOAP使用 HTTP 作為底層通信協(xié)議，從而可以很好的使用 request/response 機制來傳送信息。 SOAP/HTTP 請求包括一個 GetLastTradePrice 的塊元素，該請求攜帶一個字符串參數(shù)和 ticker 符號，在 SOAP 應答中返回一個浮點數(shù)。 XML 名域用來區(qū)分SOAP 標志符和應用程序特定的標 志符。 圖 33 使用 HTTP 作為底通信協(xié)議 3. 例 3 展示的是 StockQuote SOAP 服務信息，是對例 2 的請求作出的一條應答消息。 簡單對象訪問協(xié)議 SOAP 原理及抓包分析 8 圖 34 對于請求作出的一條應答消息 SOAP=RPC+HTTP+XML SOAP 簡單的理解，就是這樣的一個開放協(xié)議 SOAP=RPC+HTTP+XML：采用HTTP 作為底層通訊協(xié)議； RPC 作為一致性的調(diào)用途徑， XML 作為數(shù)據(jù)傳送的格式，允許服務提供者和服務客戶經(jīng)過防火墻在 INTERNET 進行通訊交互。 RPC 的描敘可能不大準確，因為 SOAP 一開始構思就是要實現(xiàn)平臺與環(huán)境的無關性和獨立性，每一個通過網(wǎng)絡的遠程調(diào)用都可以通過 SOAP 封裝起來，包括 DCE（ Distributed Computing Environment ） RPC CALLS， COM/DCOM CALLS, CORBA CALLS, JAVA CALLS， etc。 SOAP 使用 HTTP 傳送 XML，盡管 HTTP 不是有效率的通訊協(xié)議，而且 XML 還需要額外的文件解析（ parse），兩者使得交易的速度大大低于其它方案。但是 XML 是一個開放、健全、有語義的訊息機制，而 HTTP 是一個廣泛又能避免許多關于防火墻的問題，從而使 SOAP 得到了廣泛的應用。但是如果效率對你來說很重要，那么你應該多考慮其 它的方式，而不要用 SOAP。