畢業(yè)論文Webservice技術(shù)淺析

1、 . . PAGE19 / NUMPAGES21航空大學(xué)科技學(xué)院web設(shè)計(jì)論文指導(dǎo)教師：潔 班級(jí)：1082061學(xué)號(hào)：29 ：袁羽WebService技術(shù)淺談?wù)S著電子商務(wù)技術(shù)的快速發(fā)展，原來那種基于特定系統(tǒng)和特定環(huán)境的開發(fā)方式逐漸無法適應(yīng)新的需求變化。WebService技術(shù)的出現(xiàn)，給異構(gòu)系統(tǒng)間的商務(wù)應(yīng)用集成帶來了前所未有的希望。WebService技術(shù)是通過構(gòu)筑一個(gè)通用的、與平臺(tái)和語言無關(guān)的技術(shù)層，使得各種不同平臺(tái)上的應(yīng)用系統(tǒng)間，實(shí)施彼此的連接和集成。本文首先對(duì)WebService技術(shù)進(jìn)行了簡(jiǎn)介，在了解它的使用情況和優(yōu)缺點(diǎn)后，對(duì)它和目前現(xiàn)有分布式CORBA技術(shù)進(jìn)行了分析和對(duì)比，進(jìn)而對(duì)它的

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

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

4、es技術(shù)與CORBA技術(shù)的比較這三個(gè)方面做出了詳細(xì)的介紹，可以加深人們對(duì)WebServices技術(shù)的理解。一、WebService技術(shù)的簡(jiǎn)介1.1WebService技術(shù)的出現(xiàn)1999年，惠普公司成為第一個(gè)引入Web服務(wù)概念的軟件廠家?；萜展镜膃Speak平臺(tái)使開發(fā)人員可以建立與實(shí)現(xiàn)電子Web服務(wù)，這是與Web服務(wù)相似的程序單元。但是，eSpeak的基礎(chǔ)技術(shù)具有專業(yè)性質(zhì)，從而使這個(gè)平臺(tái)沒有得到廣泛的行業(yè)支持。2000年6月，微軟公司正式提出了Web服務(wù)的概念，把Web服務(wù)作為.NET項(xiàng)目的關(guān)鍵組件，這個(gè)項(xiàng)目用的是全新的方法在開發(fā)、構(gòu)建與使用軟件，能夠牢牢掌握Internet。微軟公司聲稱將整

5、個(gè)公司的命運(yùn)都?jí)涸赪eb服務(wù)上，使Web服務(wù)幾乎立即成為“下一件大事”?，F(xiàn)在幾乎每個(gè)主要軟件廠家都在推出Web服務(wù)工具和應(yīng)用程序。隨著Web服務(wù)的發(fā)布，許多人認(rèn)識(shí)到這個(gè)技術(shù)可能對(duì)分布式計(jì)算機(jī)帶來革命。過去，CORBA與DCOM都已經(jīng)提交到標(biāo)準(zhǔn)組織，讓公司可以選擇其中一個(gè)標(biāo)準(zhǔn)作為通用分布式計(jì)算的標(biāo)準(zhǔn)。但這種情況并沒有發(fā)生，因?yàn)楣疽呀?jīng)在Windows或Java平臺(tái)上投入大量資金，使用了相應(yīng)的分布式技術(shù)，移植到平臺(tái)會(huì)需要大量業(yè)務(wù)時(shí)間，經(jīng)費(fèi)和員工生產(chǎn)率。行業(yè)對(duì)相互操作性問題的經(jīng)驗(yàn)導(dǎo)致了WebService技術(shù)開放標(biāo)準(zhǔn)的開發(fā)，努力實(shí)現(xiàn)跨平臺(tái)通信。Web服務(wù)使用的主要標(biāo)準(zhǔn)是XML，這是個(gè)數(shù)據(jù)標(biāo)記語言，使

6、用程序和平臺(tái)之間可以交換信息。微軟與DevelopMentor公司建立簡(jiǎn)單對(duì)象訪問協(xié)議（SOAP Simple Object Access Protocol）作為Web服務(wù)之間傳輸信息與指令的消息協(xié)議，用XML作為基礎(chǔ)協(xié)議。另外兩個(gè)Web服務(wù)規(guī)是Web服務(wù)描述語言（WSDL WebServices Description Language）和統(tǒng)一描述、發(fā)現(xiàn)與集成（UDDI Universal Description Discovery and Integration），也用XML作為基礎(chǔ)協(xié)議。WSDL提供了描述Web服務(wù)與其特定功能的標(biāo)準(zhǔn)方法，UDDI定義建立目錄XML規(guī)則，公司可以用這個(gè)目錄

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

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

9、編寫的，可是他們各自提供轉(zhuǎn)賬的對(duì)外接口，實(shí)現(xiàn)跨語言、平臺(tái)的信息交互。在工行的提款機(jī)上可以使用中行的卡取錢，它其實(shí)是調(diào)用了人家中行的系統(tǒng)的方法和中行的數(shù)據(jù)庫(kù)交互，中行的數(shù)據(jù)庫(kù)是不允許工行的程序去訪問的。1.3WebService技術(shù)的體系結(jié)構(gòu)Web服務(wù)的一個(gè)主要思想，就是未來的應(yīng)用將由一組應(yīng)用了網(wǎng)絡(luò)的服務(wù)組合而成。只要兩個(gè)等同的服務(wù)使用統(tǒng)一標(biāo)準(zhǔn)和中性的方法在網(wǎng)絡(luò)上宣傳自己，那么從理論上說，一個(gè)應(yīng)用程序就可以根據(jù)價(jià)格或者性能的標(biāo)準(zhǔn)，從兩個(gè)彼此競(jìng)爭(zhēng)的服務(wù)之中選出一個(gè)。除此之外，一些服務(wù)允許在機(jī)器之間復(fù)制，因而可以通過把有用的服務(wù)復(fù)制到本地儲(chǔ)存庫(kù)，來提高允許運(yùn)行在特定的計(jì)算機(jī)（群）上的應(yīng)用程序的性能。

10、WebServices體系結(jié)構(gòu)是面向?qū)ο蠓治雠c設(shè)計(jì)（OOAD）的一種合理發(fā)展（logical evolution），同時(shí)也是電子商務(wù)解決方案中，面向體系結(jié)構(gòu)、設(shè)計(jì)、實(shí)現(xiàn)與部署而采用的組件化的合理發(fā)展（logical evolution of components geared towards the architecture, design, implementation, and deployment of e-business solutions）。這兩種方式在復(fù)雜的大型系統(tǒng)中經(jīng)受住了考驗(yàn)。和面向?qū)ο笙到y(tǒng)一樣，封裝、消息傳遞、動(dòng)態(tài)綁定、服務(wù)描述和查詢也是WebServices中的基本概念，

11、而且，WebServices另外一個(gè)基本概念就是：所有東西都是服務(wù)，這些服務(wù)發(fā)布一個(gè)API供網(wǎng)絡(luò)中的其他服務(wù)使用，并且封裝了實(shí)現(xiàn)細(xì)節(jié)。下面就來看一下WebServices的體系結(jié)構(gòu)-面向服務(wù)的體系結(jié)構(gòu)（SOA）。圖 1-1 面向服務(wù)的體系結(jié)構(gòu)（SOA）從圖1-1可以看出，SOA結(jié)構(gòu)中共有三種角色：Service provider：發(fā)布自己的服務(wù)，并且對(duì)使用自身服務(wù)的請(qǐng)求進(jìn)行響應(yīng)。Service broker：注冊(cè)已經(jīng)發(fā)布的Service provider，對(duì)其進(jìn)行分類，并提供搜索服務(wù)。Service requester：利用Service broker查找所需的服務(wù)，然后使用該服務(wù)。SOA體系

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

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

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

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

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

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

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

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

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

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

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

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

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

25、作或遠(yuǎn)程調(diào)用的時(shí)候是最有用的。不過，也有一些情況，WebService不能帶來任何好處。短處一：?jiǎn)螜C(jī)應(yīng)用程序目前，企業(yè)和個(gè)人還使用著很多桌面應(yīng)用程序。其中一些只需要與本機(jī)上的其它程序通信。在這種情況下，最好就不要用WebService，只要用本地的API就可以了。COM非常適合于在這種情況下工作，因?yàn)樗刃∮挚?。運(yùn)行在同一臺(tái)服務(wù)器上的服務(wù)器軟件也是這樣。最好直接用COM或其它本地的API來進(jìn)行應(yīng)用程序間的調(diào)用。當(dāng)然WebService也能用在這些場(chǎng)合，但那樣不僅消耗太大，而且不會(huì)帶來任何好處。短處二：局域網(wǎng)的同構(gòu)應(yīng)用程序在許多應(yīng)用中，所有的程序都是用VB或VC開發(fā)的，都在Windows平臺(tái)下使

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

27、提出的分布式對(duì)象計(jì)算規(guī)，經(jīng)過十幾年的的發(fā)展，已經(jīng)在很多關(guān)鍵業(yè)務(wù)處理中得到了廣泛的應(yīng)用。CORBA和WebService都是實(shí)現(xiàn)分布式技術(shù)的技術(shù)框架，在體系結(jié)構(gòu)、組成、技術(shù)實(shí)現(xiàn)甚至研究方法上都有可比之處，因此，將CORBA和WebService進(jìn)行比較，借鑒CORBA研究和應(yīng)用中的成果，是發(fā)展和完善WebService技術(shù)的一種途徑。2.1CORBA技術(shù)的簡(jiǎn)介CORBA實(shí)現(xiàn)了分布異構(gòu)環(huán)境中對(duì)象之間的透明請(qǐng)求調(diào)用，應(yīng)用程序無需考慮底層硬件平臺(tái)、操作系統(tǒng)、通信協(xié)議等細(xì)節(jié)，保證了分布式應(yīng)用的互操作性，其體系結(jié)構(gòu)如圖2-1所示。ORB核心（GIOPIIOP）動(dòng)態(tài)調(diào)用IDL存根ORB界面靜態(tài)IDL框架動(dòng)態(tài)

28、框架調(diào)用對(duì)象適配器客 戶服 務(wù) 器圖 2-1 CORBA組成部分對(duì)象請(qǐng)求代理ORB負(fù)責(zé)接收客戶端的請(qǐng)求，并傳遞到目標(biāo)對(duì)象，將執(zhí)行結(jié)果返回給客戶程序。ORB是CORBA的核心，使應(yīng)用程序無需關(guān)心目標(biāo)對(duì)象的物理位置、實(shí)現(xiàn)和現(xiàn)行狀態(tài)等。CORBA使用OMG IDL定義了對(duì)象接口，并通過語言映射技術(shù)翻譯成對(duì)應(yīng)的編程語言，生成客戶端的存根和服務(wù)端的框架。存根將請(qǐng)求進(jìn)行封裝以與對(duì)響應(yīng)進(jìn)行解封裝；框架則在服務(wù)端完成互補(bǔ)的類似工作?？蛻舳顺绦蛲ㄟ^IDL存根發(fā)起對(duì)遠(yuǎn)程對(duì)象的請(qǐng)求、請(qǐng)求到達(dá)服務(wù)端的對(duì)象適配器。對(duì)象適配器負(fù)責(zé)對(duì)象登記、定位、激活和撤銷等，它將請(qǐng)求調(diào)度到適合的對(duì)象實(shí)現(xiàn)，并將執(zhí)行結(jié)果返回給客戶。2.2

29、WebService技術(shù)和CORBA技術(shù)CORBA和WebService的共同點(diǎn)在于，它們都提供了一中分布計(jì)算領(lǐng)域的技術(shù)框架，因而都對(duì)分布式應(yīng)用面臨的問題提出了解決方法。分布式應(yīng)用最基本的要應(yīng)用能夠跨平臺(tái)調(diào)用，而CORBA和WebService都能夠屏蔽底層平臺(tái)的差異，使應(yīng)用程序與操作系統(tǒng)、通信協(xié)議無關(guān)，簡(jiǎn)化了分布式應(yīng)用的開發(fā)。分布式應(yīng)用請(qǐng)求模式客戶端調(diào)用服務(wù)端的功能，這使二者都在體系結(jié)構(gòu)上有一個(gè)對(duì)方的概念。因?yàn)榭蛻舳艘{(diào)用服務(wù)端，要求客戶端對(duì)服務(wù)端有一定理解，因此，二者都采用了某種語言來描述服務(wù)方的接口?？蛻舳撕头?wù)端的分離，使客戶端在請(qǐng)求服務(wù)的時(shí)候，總需要一定方式來標(biāo)識(shí)服務(wù)方。如果客戶端不

30、知道服務(wù)方的標(biāo)識(shí)，它就需要某種方式來查找所需的服務(wù)。CORBA和WebService都通過唯一標(biāo)識(shí)來識(shí)別服務(wù)方，并且都提供了服務(wù)的查找手段。應(yīng)用在進(jìn)行關(guān)鍵業(yè)務(wù)處理時(shí)，要求操作的可靠性、安全性和服務(wù)質(zhì)量，而CORBA和WebService中都制訂了對(duì)應(yīng)的規(guī)來滿足這些要求。表 2-1 WebService和CORBA對(duì)比項(xiàng)目WebServiceCORBA問題域Internet企業(yè)計(jì)算環(huán)境基本模型面向服務(wù)面向?qū)ο篑詈闲运缮Ⅰ詈暇o密耦合數(shù)據(jù)描述XML格式文檔二進(jìn)制接口描述語言WSDLIDL傳輸協(xié)議SOAP（ ,SMTP）等HOP,GIOP位置表示URLIOR防火墻穿越容易難查找UDDI名字服務(wù)，交易服

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

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

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

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

35、己的特性，其他應(yīng)用程序可以通過UDDI找到Web服務(wù)。SOAP則可提供了應(yīng)用程序和Web服務(wù)之間的通信手段。而WSDL、SOAP、和UDDI都是建立在XML基礎(chǔ)之上。3.1XML3.1.1簡(jiǎn)介為了實(shí)現(xiàn)異構(gòu)系統(tǒng)(不同的平臺(tái)、編程語言和組件模型等)之間的互操作性，需提供一套標(biāo)準(zhǔn)通用的數(shù)據(jù)語言。可擴(kuò)展標(biāo)記語言(XML Extensible Markup Language)已經(jīng)成為Internet的通用語言。在WebServices平臺(tái)中，采用XML表示數(shù)據(jù)的基本格式。XML能創(chuàng)建不依賴于平臺(tái)、編程語言的開放數(shù)據(jù)，具有平臺(tái)無關(guān)性。作為一個(gè)服務(wù)平臺(tái)，WebServices必須提供一種標(biāo)準(zhǔn)的數(shù)據(jù)類型系統(tǒng)，

36、用于溝通不同系統(tǒng)之間的不同類型。萬維網(wǎng)聯(lián)盟(W3C)制定的XML Schema(XSL)定義了一套標(biāo)準(zhǔn)的數(shù)據(jù)類型來擴(kuò)展這套數(shù)據(jù)類型。WebServices平臺(tái)采用XSD(XML Schema Definition)作為其數(shù)據(jù)類型系統(tǒng)。無論使用哪種語言構(gòu)造WebServices，最終都將被轉(zhuǎn)換為XSD類型。在實(shí)際應(yīng)用中，開發(fā)工具一般會(huì)幫助開發(fā)者完成這一轉(zhuǎn)換過程。3.1.2XML和HTML的差異XML和HTML的不同可以歸納為三點(diǎn)：XML擴(kuò)展性優(yōu)于HTMLXML（Extensible Markup Languages）是擴(kuò)展標(biāo)記語言的英語縮寫，他可以創(chuàng)建個(gè)性化的標(biāo)記語言，可以稱之為元語言。XML的

37、標(biāo)記語言可以自定義，這樣可以提供更多的數(shù)據(jù)操作，而不像HTML一樣，只能局限于按一定的格式在終端顯示出來。HTML的功能只有瀏覽器放入顯示和打印，僅僅適合靜態(tài)網(wǎng)頁(yè)的要求。XML的語法比HTML嚴(yán)格由于XML的擴(kuò)展性強(qiáng)，它需要穩(wěn)定的基礎(chǔ)規(guī)則來支持?jǐn)U展。它的嚴(yán)格規(guī)則為：起始和結(jié)束的標(biāo)簽相匹配嵌套標(biāo)簽不能相互嵌套區(qū)分大小寫相對(duì)應(yīng)XML的嚴(yán)格規(guī)則，HTML語言并沒有規(guī)定標(biāo)簽的絕對(duì)位置，也不區(qū)分大小寫，而這些全部由瀏覽器來完成識(shí)別和更正。XML與HTML互補(bǔ)XML可以獲得應(yīng)用之間的相應(yīng)信息，提供終端的多項(xiàng)處理要求，也能被其他的解析器和工具所使用，在現(xiàn)階段，XML可以轉(zhuǎn)化成相應(yīng)的HTML，來適應(yīng)當(dāng)前瀏覽器

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

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

40、然而，在RPC上使用SOAP并不僅限于 協(xié)議綁定。SOAP也可以綁定到TCP和UDP協(xié)議上。性能：SOAP用XML將消息編碼，因此在調(diào)用過程的任何一步都極易處理消息。另外，調(diào)試SOAP消息的方便性使各種SOAP執(zhí)行能快速聚合在一起，這點(diǎn)很重要因?yàn)镾OAP就是要達(dá)到大圍的協(xié)同工作。（CORBA、DCOM和RMI對(duì)參數(shù)和返回值使用二進(jìn)制編碼。除此之外，他們假設(shè)發(fā)送端和接收端充分了解消息的前后關(guān)系，因此對(duì)諸如參數(shù)名稱或類型的任何元信息都不編碼。這種方法產(chǎn)生了良好的性能，但使中介很難處理消息。因?yàn)槊總€(gè)系統(tǒng)使用不同的二進(jìn)制編碼，所以建立互操作的系統(tǒng)很難）。表面看來，基于XML的模式本應(yīng)比基于二進(jìn)制的慢，

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

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

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

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

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

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

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

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