1、 . . PAGE19 / NUMPAGES21航空大學科技學院web設計論文指導教師：潔 班級：1082061學號：29 ：袁羽WebService技術淺談摘要隨著電子商務技術的快速發展，原來那種基于特定系統和特定環境的開發方式逐漸無法適應新的需求變化。WebService技術的出現，給異構系統間的商務應用集成帶來了前所未有的希望。WebService技術是通過構筑一個通用的、與平臺和語言無關的技術層，使得各種不同平臺上的應用系統間，實施彼此的連接和集成。本文首先對WebService技術進行了簡介，在了解它的使用情況和優缺點后，對它和目前現有分布式CORBA技術進行了分析和對比，進而對它的

2、體系結構有深入的了解。其次介紹了WebService技術中的關鍵技術，其中包括可擴展性標記語言（XML）、簡單對象訪問協議（SOAP）、Web服務描述語言（WSDL）和統一描述、發現與集成（UDDI）注冊中心。最后本文依據WebServices的技術原理、體系架構與關鍵技術，提出了一個WebServices技術在旅游系統中的應用。關鍵詞： WebService技術CORBA技術XMLSOAPUDDI協議緒論不斷發展的計算機技術使得業發生了巨大的變化，并得以普與。World Wide Web、Java技術以與XML似乎無處不在，這些技術均得以快速應用，而且已成為企業級計算機的主要技術。Web服務

3、最早出現在1999年，也是不斷發展的技術。Web服務是隨著業的巨大擴而出現的，這項技術已經得到商務活動的認可，并且開始被大量的開發人員采納。隨著時間的推移，WebService技術也越來越完善，并且滲透于人們生活的方方面面。關于WebService技術已經有不少文獻進行了討論，在有些文獻中主要描述了WebService技術的前瞻性，其他一些則把重點描述了WebService技術在生活、軍事、氣象、醫療等實際應用前景。對于初涉WebService技術的人們來說這些都比較抽象且不易理解，本文在以上基礎上對WebServices技術的研究現狀、WebServices應用的關鍵技術和WebServic

4、es技術與CORBA技術的比較這三個方面做出了詳細的介紹，可以加深人們對WebServices技術的理解。一、WebService技術的簡介1.1WebService技術的出現1999年，惠普公司成為第一個引入Web服務概念的軟件廠家。惠普公司的eSpeak平臺使開發人員可以建立與實現電子Web服務，這是與Web服務相似的程序單元。但是，eSpeak的基礎技術具有專業性質，從而使這個平臺沒有得到廣泛的行業支持。2000年6月，微軟公司正式提出了Web服務的概念，把Web服務作為.NET項目的關鍵組件，這個項目用的是全新的方法在開發、構建與使用軟件，能夠牢牢掌握Internet。微軟公司聲稱將整

5、個公司的命運都壓在Web服務上，使Web服務幾乎立即成為“下一件大事”。現在幾乎每個主要軟件廠家都在推出Web服務工具和應用程序。隨著Web服務的發布，許多人認識到這個技術可能對分布式計算機帶來革命。過去，CORBA與DCOM都已經提交到標準組織，讓公司可以選擇其中一個標準作為通用分布式計算的標準。但這種情況并沒有發生，因為公司已經在Windows或Java平臺上投入大量資金，使用了相應的分布式技術，移植到平臺會需要大量業務時間，經費和員工生產率。行業對相互操作性問題的經驗導致了WebService技術開放標準的開發，努力實現跨平臺通信。Web服務使用的主要標準是XML，這是個數據標記語言，使

6、用程序和平臺之間可以交換信息。微軟與DevelopMentor公司建立簡單對象訪問協議（SOAP Simple Object Access Protocol）作為Web服務之間傳輸信息與指令的消息協議，用XML作為基礎協議。另外兩個Web服務規是Web服務描述語言（WSDL WebServices Description Language）和統一描述、發現與集成（UDDI Universal Description Discovery and Integration），也用XML作為基礎協議。WSDL提供了描述Web服務與其特定功能的標準方法，UDDI定義建立目錄XML規則，公司可以用這個目錄

7、對本身與其Web服務進行公告。盡管Web服務還沒有充分發揮所有潛力，但已經對業務通信帶來了變革。在教學、制造、財務服務與旅游等等行業中得以廣泛的使用11。1.2WebService技術概述WebService它不是一種框架，而是一種技術。WebServices是由企業發布的完成其特定商務需求的在線應用服務，其他公司或應用軟件能夠通過Internet來訪問并使用這項在線服務，它是一種構建應用程序的普遍模型，可以在任何支持網絡通信的操作系統中實施運行；它是一種新的web應用程序分支，是自包含、自描述、模塊化的應用，可以發布、定位、通過web調用。WebService是一個應用組件，它邏輯性的為其他

8、應用程序提供數據與服務。各應用程序通過網絡協議和規定的一些標準數據格式（ ，XML，SOAP)來訪問WebService，通過WebService部執行得到所需結果。WebService可以執行從簡單的請求到復雜商務處理的任何功能。一旦部署以后，其他WebService應用程序可以發現并調用它部署的服務。官方的解釋就是：WebService主要是為了使原來各孤立的站點之間的信息能夠相互通信、共享而提出的一種接口。WebServices技術可以理解為：各個站點之間互相調用方法實現功能，不受操作系統，編程語言等等的限制，比如：工行的網上銀行系統是使用java編寫的，中行的網上銀行系統是使用.net

9、編寫的，可是他們各自提供轉賬的對外接口，實現跨語言、平臺的信息交互。在工行的提款機上可以使用中行的卡取錢，它其實是調用了人家中行的系統的方法和中行的數據庫交互，中行的數據庫是不允許工行的程序去訪問的。1.3WebService技術的體系結構Web服務的一個主要思想，就是未來的應用將由一組應用了網絡的服務組合而成。只要兩個等同的服務使用統一標準和中性的方法在網絡上宣傳自己，那么從理論上說，一個應用程序就可以根據價格或者性能的標準，從兩個彼此競爭的服務之中選出一個。除此之外，一些服務允許在機器之間復制，因而可以通過把有用的服務復制到本地儲存庫，來提高允許運行在特定的計算機（群）上的應用程序的性能。

10、WebServices體系結構是面向對象分析與設計（OOAD）的一種合理發展（logical evolution），同時也是電子商務解決方案中，面向體系結構、設計、實現與部署而采用的組件化的合理發展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。這兩種方式在復雜的大型系統中經受住了考驗。和面向對象系統一樣，封裝、消息傳遞、動態綁定、服務描述和查詢也是WebServices中的基本概念，

11、而且，WebServices另外一個基本概念就是：所有東西都是服務，這些服務發布一個API供網絡中的其他服務使用，并且封裝了實現細節。下面就來看一下WebServices的體系結構-面向服務的體系結構（SOA）。圖 1-1 面向服務的體系結構（SOA）從圖1-1可以看出，SOA結構中共有三種角色：Service provider：發布自己的服務，并且對使用自身服務的請求進行響應。Service broker：注冊已經發布的Service provider，對其進行分類，并提供搜索服務。Service requester：利用Service broker查找所需的服務，然后使用該服務。SOA體系

12、結構中的組件必須具有上述一種或多種角色。在這些角色之間使用了三種操作：publish操作：使Service provider可以向Service broker注冊自己的功能與訪問接口。find操作：使Service requester可以通過Service broker查找特定種類的服務。bind操作：使Service requester能夠真正使用Service provider。為支持結構中的三種操作（publish、find和bind），SOA需要對服務進行一定的描述，這種服務描述（Service Description）應具有下面幾個重要特點：首先，它要聲明Service provid

13、er的語義特征。Service broker使用語義特征將Service provider進行分類，以幫助具體服務的查找。Service requester根據語義特征來匹配那些滿足要求的Service provider。（因此，語義特征中重要的一點就是對Service provider的分類）其次，服務描述應該聲明接口特征，以訪問特定的服務。最后，服務描述還應聲明各種非功能特征，如安全要求，事務要求，使用Service provider的費用等等。接口特征和非功能特征也可以用來幫助Service requester對Service provider的查找。注意，服務描述和服務實現是分離的，這

14、使得Service requester可以在Service provider的一個具體實現（implementation）正處于開發階段、部署階段或完成（execution）階段時，對其（具體實現）進行綁定。另外，SOA中的組件相互之間必須能夠進行交互，才能進行上述三種操作。所以WebServices體系結構的另一個基本原則就是使用標準的技術，包括服務描述、通訊協議以與數據格式等。這樣一來，開發者就可以開發出平臺獨立、編程語言獨立的WebServices，從而能夠充分利用現有的軟硬件資源和人力資源。最后，SOA體系結構沒有對WebService的粒度進行限制，因此一個WebService即可以

15、是一個組件（小粒度），該組件必須和其他組件結合才能進行完整的業務處理；WebService也可以是一個應用程序（大粒度）5。1.4WebService技術的工作流程在使用WebService時，包括三個階段的通信。第一階段的通信被稱為發現階段(Discover)，其主要作用是確定在服務器上有哪些服務。經過發現階段我們一般可以確定服務器一共提供了哪些服務，在使用這些服務之前我們還必須知道這些服務支持什么樣的界面。第二階段的通信就是發送請求獲得WebService描述語言WSDL。 第三階段的通信主要是向WebService服務器發送信息服務請求，并等待服務器的應答。1.5WebService技術

16、的優缺點1.5.1WebService技術的優點在以下四種情況下，使用WebService會帶來極大的好處。長項一：跨防火墻的通信如果應用程序有成千上萬的用戶，而且分布在世界各地，那么客戶端和服務器之間的通信將是一個棘手的問題。因為客戶端和服務器之間通常會有防火墻或者代理服務器。在這種情況下，使用DCOM就不是那么簡單，通常也不便于把客戶端程序發布到數量如此龐大的每一個用戶手中。傳統的做法是，選擇用瀏覽器作為客戶端，寫下一大堆ASP頁面，把應用程序的中間層暴露給最終用戶。這樣做的結果是開發難度大，程序很難維護。舉個例子，在應用程序里加入一個新頁面，必須先建立好用戶界面(Web頁面)，并在這個頁

17、面后面，包含相應商業邏輯的中間層組件，還要再建立至少一個ASP頁面，用來接受用戶輸入的信息，調用中間層組件，把結果格式化為HTML形式，最后還要把“結果頁”送回瀏覽器。要是客戶端代碼不再如此依賴于HTML表單，客戶端的編程就簡單多了。如果中間層組件換成WebService的話，就可以從用戶界面直接調用中間層組件，從而省掉建立ASP頁面的那一步。要調用WebService，可以直接使用MicrosoftSOAPToolkit或.NET這樣的SOAP客戶端，也可以使用自己開發的SOAP客戶端，然后把它和應用程序連接起來。不僅縮短了開發周期，還減少了代碼復雜度，并能夠增強應用程序的可維護性。同時，應

18、用程序也不再需要在每次調用中間層組件時，都跳轉到相應的“結果頁”。從經驗來看，在一個用戶界面和中間層有較多交互的應用程序中，使用WebService這種結構，可以節省花在用戶界面編程上20%的開發時間。另外，這樣一個由WebService組成的中間層，完全可以在應用程序集成或其它場合下重用。最后，通過WebService把應用程序的邏輯和數據“暴露”出來，還可以讓其它平臺上的客戶重用這些應用程序。長項二：應用程序集成企業級的應用程序開發者都知道，企業里經常都要把用不同語言寫成的、在不同平臺上運行的各種程序集成起來，而這種集成將花費很大的開發力量。應用程序經常需要從運行在IBM主機上的程序中獲取

19、數據；或者把數據發送到主機或UNIX應用程序中去。即使在同一個平臺上，不同軟件廠商生產的各種軟件也常常需要集成起來。通過WebService，應用程序可以用標準的方法把功能和數據“暴露”出來，供其它應用程序使用。例如，有一個訂單登錄程序，用于登錄從客戶來的新訂單，包括客戶信息、發貨地址、數量、價格和付款方式等容；還有一個訂單執行程序，用于實際貨物發送的管理。這兩個程序來自不同軟件廠商。一份新訂單進來之后，訂單登錄程序需要通知訂單執行程序發送貨物。通過在訂單執行程序上面增加一層WebService，訂單執行程序可以把“AddOrder”函數“暴露”出來。這樣，每當有新訂單到來時，訂單登錄程序就可

20、以調用這個函數來發送貨物了。長項三：B2B的集成用WebService集成應用程序，可以使公司部的商務處理更加自動化。但當交易跨越供應商和客戶、突破公司的界限時會怎么樣呢？跨公司的商務交易集成通常叫做B2B集成。WebService是B2B集成成功的關鍵。通過WebService，公司可以把關鍵的商務應用“暴露”給指定的供應商和客戶。例如，把電子下單系統和電子發票系統“暴露”出來，客戶就可以以電子的方式發送訂單，供應商則可以以電子的方式發送原料采購發票。當然，這并不是一個新的概念，EDI(電子文檔交換)早就是這樣了。但是，WebService的實現要比EDI簡單得多，而且WebService運

21、行在Internet上，在世界任何地方都可輕易實現，其運行成本就相對較低。不過，WebService并不像EDI那樣，是文檔交換或B2B集成的完整解決方案。WebService只是B2B集成的一個關鍵部分，還需要許多其它的部分才能實現集成。用WebService來實現B2B集成的最大好處在于可以輕易實現互操作性。只要把商務邏輯“暴露”出來，成為WebService，就可以讓任何指定的合作伙伴調用這些商務邏輯，而不管他們的系統在什么平臺上運行，使用什么開發語言。這樣就大大減少了花在B2B集成上的時間和成本，讓許多原本無法承受EDI的中小企業也能實現B2B集成。長項四：軟件和數據重用軟件重用是一個

22、很大的主題，重用的形式很多，重用的程度有大有小。最基本的形式是源代碼模塊或者類一級的重用，另一種形式是二進制形式的組件重用。當前，像表格控件或用戶界面控件這樣的可重用軟件組件，在市場上都占有很大的份額。但這類軟件的重用有一個很大的限制，就是重用僅限于代碼，數據不能重用。原因在于，發布組件甚至源代碼都比較容易，但要發布數據就沒那么容易，除非是不會經常變化的靜態數據。WebService在允許重用代碼的同時，可以重用代碼背后的數據。使用WebService，再也不必像以前那樣，要先從第三方購買、安裝軟件組件，再從應用程序中調用這些組件；只需要直接調用遠端的WebService就可以了。舉個例子，要

23、在應用程序中確認用戶輸入的地址，只需把這個地址直接發送給相應的WebService，這個WebService就會幫你查閱街道地址、城市、省區和郵政編碼等信息，確認這個地址是否在相應的郵政編碼區域。WebService的提供商可以按時間或使用次數來對這項服務進行收費。這樣的服務要通過組件重用來實現是不可能的，那樣的話你必須下載并安裝好包含街道地址、城市、省區和郵政編碼等信息的數據庫，而且這個數據庫還是不能實時更新的。另一種軟件重用的情況是，把好幾個應用程序的功能集成起來。例如，要建立一個局域網上的門戶站點應用，讓用戶既可以查詢聯邦快遞包裹，查看股市行情，又可以管理自己的日程安排，還可以在線購買電

24、影票。現在Web上有很多應用程序供應商，都在其應用中實現了這些功能。一旦他們把這些功能都通過WebService“暴露”出來，就可以非常容易地把所有這些功能都集成到你的門戶站點中，為用戶提供一個統一的、友好的界面。將來，許多應用程序都會利用WebService，把當前基于組件的應用程序結構擴展為組件/WebService的混合結構，可以在應用程序中使用第三方的WebService提供的功能，也可以把自己的應用程序功能通過WebService提供給別人。兩種情況下，都可以重用代碼和代碼背后的數據。1.5.2WebService技術的缺點從以上論述可以看出，WebService在通過Web進行互操

25、作或遠程調用的時候是最有用的。不過，也有一些情況，WebService不能帶來任何好處。短處一：單機應用程序目前，企業和個人還使用著很多桌面應用程序。其中一些只需要與本機上的其它程序通信。在這種情況下，最好就不要用WebService，只要用本地的API就可以了。COM非常適合于在這種情況下工作，因為它既小又快。運行在同一臺服務器上的服務器軟件也是這樣。最好直接用COM或其它本地的API來進行應用程序間的調用。當然WebService也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。短處二：局域網的同構應用程序在許多應用中，所有的程序都是用VB或VC開發的，都在Windows平臺下使

26、用COM，都運行在同一個局域網上。例如，有兩個服務器應用程序需要相互通信，或者有一個Win32或WinForm的客戶程序要連接局域網上另一個服務器的程序。在這些程序里，使用DCOM會比SOAP/ 有效得多。與此相類似，如果一個.NET程序要連接到局域網上的另一個.NET程序，應該使用.NETremoting。有趣的是，在.NET Remoting中，也可以指定使用SOAP/ 來進行WebService調用。不過最好還是直接通過TCP進行RPC調用，那樣會有效得多。總之，應當從具體應用環境出發，選擇最適當的解決方案。二、WebService技術與CORBA技術CORBA是20世紀90年代由OMG

27、提出的分布式對象計算規，經過十幾年的的發展，已經在很多關鍵業務處理中得到了廣泛的應用。CORBA和WebService都是實現分布式技術的技術框架，在體系結構、組成、技術實現甚至研究方法上都有可比之處，因此，將CORBA和WebService進行比較，借鑒CORBA研究和應用中的成果，是發展和完善WebService技術的一種途徑。2.1CORBA技術的簡介CORBA實現了分布異構環境中對象之間的透明請求調用，應用程序無需考慮底層硬件平臺、操作系統、通信協議等細節，保證了分布式應用的互操作性，其體系結構如圖2-1所示。ORB核心（GIOPIIOP）動態調用IDL存根ORB界面靜態IDL框架動態

28、框架調用對象適配器客 戶服 務 器圖 2-1 CORBA組成部分對象請求代理ORB負責接收客戶端的請求，并傳遞到目標對象，將執行結果返回給客戶程序。ORB是CORBA的核心，使應用程序無需關心目標對象的物理位置、實現和現行狀態等。CORBA使用OMG IDL定義了對象接口，并通過語言映射技術翻譯成對應的編程語言，生成客戶端的存根和服務端的框架。存根將請求進行封裝以與對響應進行解封裝；框架則在服務端完成互補的類似工作。客戶端程序通過IDL存根發起對遠程對象的請求、請求到達服務端的對象適配器。對象適配器負責對象登記、定位、激活和撤銷等，它將請求調度到適合的對象實現，并將執行結果返回給客戶。2.2

29、WebService技術和CORBA技術CORBA和WebService的共同點在于，它們都提供了一中分布計算領域的技術框架，因而都對分布式應用面臨的問題提出了解決方法。分布式應用最基本的要應用能夠跨平臺調用，而CORBA和WebService都能夠屏蔽底層平臺的差異，使應用程序與操作系統、通信協議無關，簡化了分布式應用的開發。分布式應用請求模式客戶端調用服務端的功能，這使二者都在體系結構上有一個對方的概念。因為客戶端要調用服務端，要求客戶端對服務端有一定理解，因此，二者都采用了某種語言來描述服務方的接口。客戶端和服務端的分離，使客戶端在請求服務的時候，總需要一定方式來標識服務方。如果客戶端不

30、知道服務方的標識，它就需要某種方式來查找所需的服務。CORBA和WebService都通過唯一標識來識別服務方，并且都提供了服務的查找手段。應用在進行關鍵業務處理時，要求操作的可靠性、安全性和服務質量，而CORBA和WebService中都制訂了對應的規來滿足這些要求。表 2-1 WebService和CORBA對比項目WebServiceCORBA問題域Internet企業計算環境基本模型面向服務面向對象耦合性松散耦合緊密耦合數據描述XML格式文檔二進制接口描述語言WSDLIDL傳輸協議SOAP（ ,SMTP）等HOP,GIOP位置表示URLIOR防火墻穿越容易難查找UDDI名字服務，交易服

31、務安全性研究中安全服務事務處理研究中對象事物服務靈活的通信機制研究中事件、通知服務從表2-1中可以看到，WebServices與CORBA最根本的差異在與出發點不同。CORBA是20世紀90年代提出來的，主要是針對企業環境中業務處理所面臨的問題。面向對象是實際應用中證明非常有效的設計和開放模式，因此CORBA采用了面向對象的計算模式（這也決定了服務位置標示采用對象引用的方式）；并且在企業環境中，業務聯系比較緊密，體現在處理業務的應用程序之間也是緊密耦合的，因此其數據描述也采用了二進制方式。企業環境中關系可能很復雜，這要求非常靈活的通信機制，因此CORBA提供了事件、通知等多種方式。WebSer

32、vices是伴隨著Internet的飛速發展而出現的。Internet中主要應用是基于Web服務的應用，因此WebServices采用了面向服務的模型。在廣闊的Internet上，業務之間的關系本身比企業的應用簡單，這可以從早期的Web應用主要是無狀態的請求/應答模式看到，因此，WebServices中，請求方和服務之間也沒有始終保持的通道，是非常松散的耦合關系。為了保證松散耦合應用程序能夠互相理解，具有自描述性的XML成了WebServices的數據描述方式，這也使WebServices具有可擴展性好、易于集成的優點。在Internet上，URL成為WebServices標示目標服務自然的選

33、擇。從上述分析可知，WebServices環境中，請求方和服務方是松散的耦合，請求以XML文檔的形式進行傳輸，接口的細微變化不會影響程序的正常執行，具有更好的課擴展性；而CORBA環境中對象請求采用二進制傳輸，請求方和服務方是緊密耦合的，服務端接口一旦發生變化，客戶端就必須作相應修改，否則就可能崩潰。CORBA采用IIOP進行傳輸，端口是動態分配的，請求很可能被防火墻拒絕；而WebServices主要基于 ，很容易穿越防火墻。在WebServices中，業務處理在Intenet上進行，這使參與者的信息更容易被竊聽和非法訪問，因此安全性要求更高。WebServices一個明顯的劣勢在于性能。XM

34、L文檔比同等信息量的CDR數據耗費更多存，也增加了網絡流量和傳輸時間，XML文檔的解析和轉換比CDR數據的編解碼需要更多容和處理時間。因此，一般來講，面向Internet的業務處理選擇WebService技術框架較為適宜。在企業環境中，如果業務之間關系緊密，或者對性能要求較高，CORBA等分布式對象模式更合適，如果業務關系較為松散，更關注開放性，則WebService是更佳選擇。三、WebService技術中的關鍵技術WebService涉與的最基本的技術規包括XML、SOAP、WSDL和UDDI。WSDL是程序員描述WebService的編程接口。WebService可以通過UDDI來注冊自

35、己的特性，其他應用程序可以通過UDDI找到Web服務。SOAP則可提供了應用程序和Web服務之間的通信手段。而WSDL、SOAP、和UDDI都是建立在XML基礎之上。3.1XML3.1.1簡介為了實現異構系統(不同的平臺、編程語言和組件模型等)之間的互操作性，需提供一套標準通用的數據語言。可擴展標記語言(XML Extensible Markup Language)已經成為Internet的通用語言。在WebServices平臺中，采用XML表示數據的基本格式。XML能創建不依賴于平臺、編程語言的開放數據，具有平臺無關性。作為一個服務平臺，WebServices必須提供一種標準的數據類型系統，

36、用于溝通不同系統之間的不同類型。萬維網聯盟(W3C)制定的XML Schema(XSL)定義了一套標準的數據類型來擴展這套數據類型。WebServices平臺采用XSD(XML Schema Definition)作為其數據類型系統。無論使用哪種語言構造WebServices，最終都將被轉換為XSD類型。在實際應用中，開發工具一般會幫助開發者完成這一轉換過程。3.1.2XML和HTML的差異XML和HTML的不同可以歸納為三點：XML擴展性優于HTMLXML（Extensible Markup Languages）是擴展標記語言的英語縮寫，他可以創建個性化的標記語言，可以稱之為元語言。XML的

37、標記語言可以自定義，這樣可以提供更多的數據操作，而不像HTML一樣，只能局限于按一定的格式在終端顯示出來。HTML的功能只有瀏覽器放入顯示和打印，僅僅適合靜態網頁的要求。XML的語法比HTML嚴格由于XML的擴展性強，它需要穩定的基礎規則來支持擴展。它的嚴格規則為：起始和結束的標簽相匹配嵌套標簽不能相互嵌套區分大小寫相對應XML的嚴格規則，HTML語言并沒有規定標簽的絕對位置，也不區分大小寫，而這些全部由瀏覽器來完成識別和更正。XML與HTML互補XML可以獲得應用之間的相應信息，提供終端的多項處理要求，也能被其他的解析器和工具所使用，在現階段，XML可以轉化成相應的HTML，來適應當前瀏覽器

38、的需求。3.2SOAP簡單對象訪問協議（SOAP Simple Object Access Protocol）是一種輕量的、簡單的、基于XML的協議，它被設計成在WEB上交換結構化的和固化的信息。SOAP可以和現存的許多因特網協議和格式結合使用，包括超文本傳輸協議（ ），簡單傳輸協議（SMTP），多用途網際擴充協議（MIME）。它還支持從消息系統到遠程過程調用（RPC）等大量的應用程序。SOAP包括三個部分： SOAP的封裝：它定義了一個框架，該框架描述了消息中的容是什么，誰應當處理它以與它是可選的還是必須的。 SOAP的編碼規則：它定義了一種序列化的機制，用于交換應用程序所定義的數據類型的實

39、例。 SOAP的RPC表示：它定義了用于表示遠程過程調用和應答的協定。 SOAP協議的消息基本上是從發送端到接收端的單向傳輸，但它們常常結合起來執行類似于請求/應答的模式。所有的SOAP消息都使用XML編碼。一條SOAP消息就是一個包含有一個必需的SOAP的封裝包，一個可選的SOAP標頭和一個必需的SOAP體塊的XML文檔。把SOAP綁定到 提供了同時利用SOAP的樣式和分散的靈活性的特點以與 的豐富的特征庫的優點。在 上傳送SOAP并不是說SOAP會覆蓋現有的 語義，而是 上的SOAP語義會自然的映射到 語義。在使用 作為協議綁定的場合中，RPC請求映射到 請求上，而RPC應答映射到 應答。

40、然而，在RPC上使用SOAP并不僅限于 協議綁定。SOAP也可以綁定到TCP和UDP協議上。性能：SOAP用XML將消息編碼，因此在調用過程的任何一步都極易處理消息。另外，調試SOAP消息的方便性使各種SOAP執行能快速聚合在一起，這點很重要因為SOAP就是要達到大圍的協同工作。（CORBA、DCOM和RMI對參數和返回值使用二進制編碼。除此之外，他們假設發送端和接收端充分了解消息的前后關系，因此對諸如參數名稱或類型的任何元信息都不編碼。這種方法產生了良好的性能，但使中介很難處理消息。因為每個系統使用不同的二進制編碼，所以建立互操作的系統很難）。表面看來，基于XML的模式本應比基于二進制的慢，

41、但它并不像表面那么簡單。首先，當SOAP被用于通過因特網發送消息時，在每個端點給消息編碼/解碼的時間與在端點間傳輸字節的時間相比較是微不足道的，所以這種情況下使用XML沒太大問題。其次，當SOAP用于封閉環境下的點對點間的消息傳送，如在同一公司部門間的傳送時，各端點可能將運行一樣的SOAP執行。這樣，這個特定執行就擁有專門的優化機會。例如，一個SOAP客戶端可添加一個 header標記到SOAP請求上，這個請求說明它支持一個特定的優化。如果SOAP服務器也支持那個優化，它會在第一個SOAP響應中返回一個 header標記，告訴客戶端可以在下面的通信中使用這種優化。接下來，客戶端和服務器可以開始

42、使用這種優化了。3.3WSDL和UDDI規作為一個服務平臺，WebServices必須具備相應的一套機制。用機器能閱讀的方式提供一個正式的描述文檔，為程序員調用服務提供幫助，使其更易于了解和使用WebServices，所采用的解決辦法是通過WSDL和UDDI協議達到其目的。3.3.1WSDL服務描述(WSDL WebService Description Language)最初由Microsoft，IBM，Ariba三家公司于2000年9月推出。它是描述網絡（network）服務或終端（endpoint）的一種XML語言，它用于定義WebServices以與如何調用它們（描述Web服務的屬性，

43、例如它做什么，它位于哪里和怎樣調用它）。WSDL文檔可用于動態發布WebServices、查找已發布的WebServices以與綁定WebServices。WSDL 文件包含以下元素：Type：使用某種語法（如XML模式）的數據類型定義（string、int）。 Message：要傳遞的數據。Part：消息參數。Operation：服務支持的操作的抽象描述。Port Type / Interface：一個或多個端點支持的操作的抽象集，此名稱已更改，因此可能會遇到兩者中的任何一個。 Binding：特定端口類型的具體協議和數據格式規。Port / Endpoint：綁定和網絡地址的組合，此名稱也

44、已更改，因此可能會遇到兩者中的任何一個。Service：相關端點的集合，包括其關聯的接口、操作、消息等。在WSDL中包含了使用SOAP的服務描述的綁定，也包含了使用簡單 GET和POST請求的服務描述的綁定。WSDL將Web服務定義成一系列的端口（port），每個端口用來表示從抽象端口類型（port type）到用于調用Web服務的具體通信協議的一個映射。端口類型由一組與Service provider交換信息的操作組成，它支持對包含消息的數據類型的定義。一個完整的WSDL服務描述是由一個服務接口和一個服務實現文檔組成的。 由于服務接口表示服務的可重用定義，它在UDDI注冊中心被作為tMode

45、l發布。服務實現描述服務的實例。每個實例都是使用一個WSDL service元素定義的。服務實現文檔中的每個service元素都被用于發布UDDI businessService。因為WSDL包含了對服務接口的完整描述，所以可以使用它來創建能簡化服務訪問的存根，該存根為一段Java代碼（假設使用Java），它自動生成了訪問Web服務的類。如果需要訪問Web服務，只需調用該類中對應的方法即可，而不用在客戶端程序中再寫入那些令人頭疼的配置信息了。通過IBM提供的工具包可以輕松創建WSDL文檔對應的存根。（由此看出，不用WSDL也可以訪問Web服務）WSDL取代了IBM的NASSL（Network-

46、Accessible Service Specification Language）和Microsoft的SCL（SOAP Contract Language）。3.3.2UDDI服務發布與發現(UDDI Universal Description Discovery and Integration)，即“通用描述、發現和集成”。該規仍由上述三家公司于2000年7月提出。它提供了在Web上描述并發現商業服務的框架。UDDI通過服務注冊，以與使用SOAP訪問這些注冊信息的約定來實現上述目標。UDDI計劃的核心組件是UDDI商業注冊，它使用一個XML文檔來描述企業與其提供的Web服務。從概念上來說

47、，UDDI商業注冊所提供的信息包含三個部分：“白頁(White Page)”包括了地址，聯系方法，和已知的企業標識；“黃頁(Yellow page)”包括了基于標準分類法的行業類別；“綠頁(Green Page)”則包括了關于該企業所提供的Web服務的技術信息，其形式可能是一些指向文件或是URL的指針，而這些文件或URL是為服務發現機制服務的。所有的UDDI商業注冊信息存儲在UDDI商業注冊中心中。 借助XML和SOAP，集成和交互的問題將從層次上被簡化。XML提供了跨平臺的數據編碼和組織方法，而SOAP建立在XML之上，定義了一種跨系統平臺的信息交換的簡單包裝方法。綁定于 之上的SOAP協議

48、，可以跨語言、跨操作系統進行遠程過程調用(RPC)，實現了編程語言和系統平臺的無關性。而以前的調用方式則和復雜的分布式對象標準或是中間件有密切的關系，從長期的眼光來看，這些都不是高效的解決方案。XML和SOAP這樣的跨語言、跨平臺的解決方案大大簡化了不同企業系統之間的交互問題。但如果僅僅是XML和SOAP的話，對于公司間的交流仍存在著巨大的鴻溝。UDDI規在XML和SOAP的基礎之上定義了新的一層，在這一層次，不同企業可以用一樣的方法描述自己所能提供的，并能查詢對方所能提供的服務。UDDI注冊使用的核心信息模型由XML Schema定義。使用XML 是因為它提供了平臺無關的數據描述并很自然的描述了數據的層次關系。而選擇XML Schema是因為它支持豐富的數據類型，便捷的描述方式與其按信息模型對數據進行驗證的能力。UDDI XML Schema定義了四種主要信息類型，它們是技術人員在需要使用合作伙伴所提供的Web服務時必須了解的技術信息。它們是：商業實體信息、服務信息、綁定信息和服務調用規的說明信息。UDDI程序員API規分為兩個邏輯部分：查詢API和發布API。查詢API又分為兩個部分：一部分被用來構造搜索和瀏覽UDDI注冊信息的程序，另一部分在Web服務出現錯誤時使用。程序員可以利用發布API創建各種類型的工具，以直接與UDDI注冊中心進行交互，便于企業技術人員管理busi