(精品論文)畢業(yè)論文WEBSERVICE_技術(shù)淺析

WebService技術(shù)淺析編號：_畢業(yè)論文（設(shè)計）題 目： WebService 技術(shù)淺析 系 別： 計算機科學(xué)系 專 業(yè)： 計算機應(yīng)用技術(shù) 摘要隨著電子商務(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)筑一個通用的、與平臺和語言無關(guān)的技術(shù)層，使得各種不同平臺上的應(yīng)用系統(tǒng)間，實施彼此的連接和集成。本文首先對WebService技術(shù)進行了簡介，在了解它的使用情況和優(yōu)缺點后，對它和目前現(xiàn)有分布式CORBA技術(shù)進行了分析和對比，進而對它的體系結(jié)構(gòu)有深入的了解。其次介紹了WebService技術(shù)中的關(guān)鍵技術(shù)，其中包括可擴展性標(biāo)記語言（XML）、簡單對象訪問協(xié)議（SOAP）、Web服務(wù)描述語言（WSDL）和統(tǒng)一描述、發(fā)現(xiàn)與集成（UDDI）注冊中心。最后本文依據(jù)WebServices的技術(shù)原理、體系架構(gòu)及關(guān)鍵技術(shù)，提出了一個WebServices技術(shù)在旅游系統(tǒng)中的應(yīng)用。關(guān)鍵詞： WebService技術(shù)CORBA技術(shù)XMLSOAPUDDI協(xié)議目 錄緒論1第一章WebService技術(shù)的簡介21.1WebService技術(shù)的出現(xiàn)21.2WebService技術(shù)概述31.3WebService技術(shù)的體系結(jié)構(gòu)31.4WebService技術(shù)的工作流程51.5WebService技術(shù)的優(yōu)缺點51.5.1WebService技術(shù)的優(yōu)點51.5.2WebService技術(shù)的缺點8第二章WebService技術(shù)與CORBA技術(shù)92.1CORBA技術(shù)的簡介92.2 WebService技術(shù)和CORBA技術(shù)10第三章WebService技術(shù)中的關(guān)鍵技術(shù)123.1XML123.1.1簡介123.1.2XML和HTML的差異123.2SOAP133.3WSDL和UDDI規(guī)范143.3.1WSDL143.3.2UDDI15結(jié)束語18參考文獻19商丘科技職業(yè)學(xué)院畢業(yè)論文緒論不斷發(fā)展的計算機技術(shù)使得傳媒業(yè)發(fā)生了巨大的變化，并得以普及。World Wide Web、Java技術(shù)以及XML似乎無處不在，這些技術(shù)均得以快速應(yīng)用，而且已成為企業(yè)級計算機的主要技術(shù)。Web服務(wù)最早出現(xiàn)在1999年，也是不斷發(fā)展的技術(shù)。Web服務(wù)是隨著傳媒業(yè)的巨大擴張而出現(xiàn)的，這項技術(shù)已經(jīng)得到商務(wù)活動的認可，并且開始被大量的開發(fā)人員采納。隨著時間的推移，WebService技術(shù)也越來越完善，并且滲透于人們生活的方方面面。關(guān)于WebService技術(shù)已經(jīng)有不少文獻進行了討論，在有些文獻中主要描述了WebService技術(shù)的前瞻性，其他一些則把重點描述了WebService技術(shù)在生活、軍事、氣象、醫(yī)療等實際應(yīng)用前景。對于初涉WebService技術(shù)的人們來說這些都比較抽象且不易理解，本文在以上基礎(chǔ)上對WebServices技術(shù)的研究現(xiàn)狀、WebServices應(yīng)用的關(guān)鍵技術(shù)和WebServices技術(shù)與CORBA技術(shù)的比較這三個方面做出了詳細的介紹，可以加深人們對WebServices技術(shù)的理解。第一章WebService技術(shù)的簡介1.1WebService技術(shù)的出現(xiàn)1999年，惠普公司成為第一個引入Web服務(wù)概念的軟件廠家。惠普公司的eSpeak平臺使開發(fā)人員可以建立與實現(xiàn)電子Web服務(wù)，這是與Web服務(wù)相似的程序單元。但是，eSpeak的基礎(chǔ)技術(shù)具有專業(yè)性質(zhì)，從而使這個平臺沒有得到廣泛的行業(yè)支持。2000年6月，微軟公司正式提出了Web服務(wù)的概念，把Web服務(wù)作為.NET項目的關(guān)鍵組件，這個項目用的是全新的方法在開發(fā)、構(gòu)建與使用軟件，能夠牢牢掌握Internet。微軟公司聲稱將整個公司的命運都壓在Web服務(wù)上，使Web服務(wù)幾乎立即成為“下一件大事”?，F(xiàn)在幾乎每個主要軟件廠家都在推出Web服務(wù)工具和應(yīng)用程序。隨著Web服務(wù)的發(fā)布，許多人認識到這個技術(shù)可能對分布式計算機帶來革命。過去，CORBA與DCOM都已經(jīng)提交到標(biāo)準(zhǔn)組織，讓公司可以選擇其中一個標(biāo)準(zhǔn)作為通用分布式計算的標(biāo)準(zhǔn)。但這種情況并沒有發(fā)生，因為公司已經(jīng)在Windows或Java平臺上投入大量資金，使用了相應(yīng)的分布式技術(shù)，移植到平臺會需要大量業(yè)務(wù)時間，經(jīng)費和員工生產(chǎn)率。行業(yè)對相互操作性問題的經(jīng)驗導(dǎo)致了WebService技術(shù)開放標(biāo)準(zhǔn)的開發(fā)，努力實現(xiàn)跨平臺通信。Web服務(wù)使用的主要標(biāo)準(zhǔn)是XML，這是個數(shù)據(jù)標(biāo)記語言，使用程序和平臺之間可以交換信息。微軟與DevelopMentor公司建立簡單對象訪問協(xié)議（SOAP Simple Object Access Protocol）作為Web服務(wù)之間傳輸信息與指令的消息協(xié)議，用XML作為基礎(chǔ)協(xié)議。另外兩個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ī)則，公司可以用這個目錄對本身及其Web服務(wù)進行公告。盡管Web服務(wù)還沒有充分發(fā)揮所有潛力，但已經(jīng)對業(yè)務(wù)通信帶來了變革。在教學(xué)、制造、財務(wù)服務(wù)與旅游等等行業(yè)中得以廣泛的使用11。1.2WebService技術(shù)概述WebService它不是一種框架，而是一種技術(shù)。WebServices是由企業(yè)發(fā)布的完成其特定商務(wù)需求的在線應(yīng)用服務(wù)，其他公司或應(yīng)用軟件能夠通過Internet來訪問并使用這項在線服務(wù)，它是一種構(gòu)建應(yīng)用程序的普遍模型，可以在任何支持網(wǎng)絡(luò)通信的操作系統(tǒng)中實施運行；它是一種新的web應(yīng)用程序分支，是自包含、自描述、模塊化的應(yīng)用，可以發(fā)布、定位、通過web調(diào)用。WebService是一個應(yīng)用組件，它邏輯性的為其他應(yīng)用程序提供數(shù)據(jù)與服務(wù)。各應(yīng)用程序通過網(wǎng)絡(luò)協(xié)議和規(guī)定的一些標(biāo)準(zhǔn)數(shù)據(jù)格式（HTTP，XML，SOAP)來訪問WebService，通過WebService內(nèi)部執(zhí)行得到所需結(jié)果。WebService可以執(zhí)行從簡單的請求到復(fù)雜商務(wù)處理的任何功能。一旦部署以后，其他WebService應(yīng)用程序可以發(fā)現(xiàn)并調(diào)用它部署的服務(wù)。官方的解釋就是：WebService主要是為了使原來各孤立的站點之間的信息能夠相互通信、共享而提出的一種接口。WebServices技術(shù)可以理解為：各個站點之間互相調(diào)用方法實現(xiàn)功能，不受操作系統(tǒng)，編程語言等等的限制，比如：工行的網(wǎng)上銀行系統(tǒng)是使用java編寫的，中行的網(wǎng)上銀行系統(tǒng)是使用.net編寫的，可是他們各自提供轉(zhuǎn)賬的對外接口，實現(xiàn)跨語言、平臺的信息交互。在工行的提款機上可以使用中行的卡取錢，它其實是調(diào)用了人家中行的系統(tǒng)的方法和中行的數(shù)據(jù)庫交互，中行的數(shù)據(jù)庫是不允許工行的程序去訪問的。1.3WebService技術(shù)的體系結(jié)構(gòu)Web服務(wù)的一個主要思想，就是未來的應(yīng)用將由一組應(yīng)用了網(wǎng)絡(luò)的服務(wù)組合而成。只要兩個等同的服務(wù)使用統(tǒng)一標(biāo)準(zhǔn)和中性的方法在網(wǎng)絡(luò)上宣傳自己，那么從理論上說，一個應(yīng)用程序就可以根據(jù)價格或者性能的標(biāo)準(zhǔn)，從兩個彼此競爭的服務(wù)之中選出一個。除此之外，一些服務(wù)允許在機器之間復(fù)制，因而可以通過把有用的服務(wù)復(fù)制到本地儲存庫，來提高允許運行在特定的計算機（群）上的應(yīng)用程序的性能。WebServices體系結(jié)構(gòu)是面向?qū)ο蠓治雠c設(shè)計（OOAD）的一種合理發(fā)展（logical evolution），同時也是電子商務(wù)解決方案中，面向體系結(jié)構(gòu)、設(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)受住了考驗。和面向?qū)ο笙到y(tǒng)一樣，封裝、消息傳遞、動態(tài)綁定、服務(wù)描述和查詢也是WebServices中的基本概念，而且，WebServices另外一個基本概念就是：所有東西都是服務(wù)，這些服務(wù)發(fā)布一個API供網(wǎng)絡(luò)中的其他服務(wù)使用，并且封裝了實現(xiàn)細節(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ù)，并且對使用自身服務(wù)的請求進行響應(yīng)。Service broker：注冊已經(jīng)發(fā)布的Service provider，對其進行分類，并提供搜索服務(wù)。Service requester：利用Service broker查找所需的服務(wù)，然后使用該服務(wù)。SOA體系結(jié)構(gòu)中的組件必須具有上述一種或多種角色。在這些角色之間使用了三種操作：publish操作：使Service provider可以向Service broker注冊自己的功能及訪問接口。find操作：使Service requester可以通過Service broker查找特定種類的服務(wù)。bind操作：使Service requester能夠真正使用Service provider。為支持結(jié)構(gòu)中的三種操作（publish、find和bind），SOA需要對服務(wù)進行一定的描述，這種服務(wù)描述（Service Description）應(yīng)具有下面幾個重要特點：首先，它要聲明Service provider的語義特征。Service broker使用語義特征將Service provider進行分類，以幫助具體服務(wù)的查找。Service requester根據(jù)語義特征來匹配那些滿足要求的Service provider。（因此，語義特征中重要的一點就是對Service provider的分類）其次，服務(wù)描述應(yīng)該聲明接口特征，以訪問特定的服務(wù)。最后，服務(wù)描述還應(yīng)聲明各種非功能特征，如安全要求，事務(wù)要求，使用Service provider的費用等等。接口特征和非功能特征也可以用來幫助Service requester對Service provider的查找。注意，服務(wù)描述和服務(wù)實現(xiàn)是分離的，這使得Service requester可以在Service provider的一個具體實現(xiàn)（implementation）正處于開發(fā)階段、部署階段或完成（execution）階段時，對其（具體實現(xiàn)）進行綁定。另外，SOA中的組件相互之間必須能夠進行交互，才能進行上述三種操作。所以WebServices體系結(jié)構(gòu)的另一個基本原則就是使用標(biāo)準(zhǔn)的技術(shù)，包括服務(wù)描述、通訊協(xié)議以及數(shù)據(jù)格式等。這樣一來，開發(fā)者就可以開發(fā)出平臺獨立、編程語言獨立的WebServices，從而能夠充分利用現(xiàn)有的軟硬件資源和人力資源。最后，SOA體系結(jié)構(gòu)沒有對WebService的粒度進行限制，因此一個WebService即可以是一個組件（小粒度），該組件必須和其他組件結(jié)合才能進行完整的業(yè)務(wù)處理；WebService也可以是一個應(yīng)用程序（大粒度）5。1.4WebService技術(shù)的工作流程在使用WebService時，包括三個階段的通信。第一階段的通信被稱為發(fā)現(xiàn)階段(Discover)，其主要作用是確定在服務(wù)器上有哪些服務(wù)。經(jīng)過發(fā)現(xiàn)階段我們一般可以確定服務(wù)器一共提供了哪些服務(wù)，在使用這些服務(wù)之前我們還必須知道這些服務(wù)支持什么樣的界面。第二階段的通信就是發(fā)送請求獲得WebService描述語言WSDL。 第三階段的通信主要是向WebService服務(wù)器發(fā)送信息服務(wù)請求，并等待服務(wù)器的應(yīng)答。1.5WebService技術(shù)的優(yōu)缺點1.5.1WebService技術(shù)的優(yōu)點在以下四種情況下，使用WebService會帶來極大的好處。長項一：跨防火墻的通信如果應(yīng)用程序有成千上萬的用戶，而且分布在世界各地，那么客戶端和服務(wù)器之間的通信將是一個棘手的問題。因為客戶端和服務(wù)器之間通常會有防火墻或者代理服務(wù)器。在這種情況下，使用DCOM就不是那么簡單，通常也不便于把客戶端程序發(fā)布到數(shù)量如此龐大的每一個用戶手中。傳統(tǒng)的做法是，選擇用瀏覽器作為客戶端，寫下一大堆ASP頁面，把應(yīng)用程序的中間層暴露給最終用戶。這樣做的結(jié)果是開發(fā)難度大，程序很難維護。舉個例子，在應(yīng)用程序里加入一個新頁面，必須先建立好用戶界面(Web頁面)，并在這個頁面后面，包含相應(yīng)商業(yè)邏輯的中間層組件，還要再建立至少一個ASP頁面，用來接受用戶輸入的信息，調(diào)用中間層組件，把結(jié)果格式化為HTML形式，最后還要把“結(jié)果頁”送回瀏覽器。要是客戶端代碼不再如此依賴于HTML表單，客戶端的編程就簡單多了。如果中間層組件換成WebService的話，就可以從用戶界面直接調(diào)用中間層組件，從而省掉建立ASP頁面的那一步。要調(diào)用WebService，可以直接使用MicrosoftSOAPToolkit或.NET這樣的SOAP客戶端，也可以使用自己開發(fā)的SOAP客戶端，然后把它和應(yīng)用程序連接起來。不僅縮短了開發(fā)周期，還減少了代碼復(fù)雜度，并能夠增強應(yīng)用程序的可維護性。同時，應(yīng)用程序也不再需要在每次調(diào)用中間層組件時，都跳轉(zhuǎn)到相應(yīng)的“結(jié)果頁”。從經(jīng)驗來看，在一個用戶界面和中間層有較多交互的應(yīng)用程序中，使用WebService這種結(jié)構(gòu)，可以節(jié)省花在用戶界面編程上20%的開發(fā)時間。另外，這樣一個由WebService組成的中間層，完全可以在應(yīng)用程序集成或其它場合下重用。最后，通過WebService把應(yīng)用程序的邏輯和數(shù)據(jù)“暴露”出來，還可以讓其它平臺上的客戶重用這些應(yīng)用程序。長項二：應(yīng)用程序集成企業(yè)級的應(yīng)用程序開發(fā)者都知道，企業(yè)里經(jīng)常都要把用不同語言寫成的、在不同平臺上運行的各種程序集成起來，而這種集成將花費很大的開發(fā)力量。應(yīng)用程序經(jīng)常需要從運行在IBM主機上的程序中獲取數(shù)據(jù)；或者把數(shù)據(jù)發(fā)送到主機或UNIX應(yīng)用程序中去。即使在同一個平臺上，不同軟件廠商生產(chǎn)的各種軟件也常常需要集成起來。通過WebService，應(yīng)用程序可以用標(biāo)準(zhǔn)的方法把功能和數(shù)據(jù)“暴露”出來，供其它應(yīng)用程序使用。例如，有一個訂單登錄程序，用于登錄從客戶來的新訂單，包括客戶信息、發(fā)貨地址、數(shù)量、價格和付款方式等內(nèi)容；還有一個訂單執(zhí)行程序，用于實際貨物發(fā)送的管理。這兩個程序來自不同軟件廠商。一份新訂單進來之后，訂單登錄程序需要通知訂單執(zhí)行程序發(fā)送貨物。通過在訂單執(zhí)行程序上面增加一層WebService，訂單執(zhí)行程序可以把“AddOrder”函數(shù)“暴露”出來。這樣，每當(dāng)有新訂單到來時，訂單登錄程序就可以調(diào)用這個函數(shù)來發(fā)送貨物了。長項三：B2B的集成用WebService集成應(yīng)用程序，可以使公司內(nèi)部的商務(wù)處理更加自動化。但當(dāng)交易跨越供應(yīng)商和客戶、突破公司的界限時會怎么樣呢？跨公司的商務(wù)交易集成通常叫做B2B集成。WebService是B2B集成成功的關(guān)鍵。通過WebService，公司可以把關(guān)鍵的商務(wù)應(yīng)用“暴露”給指定的供應(yīng)商和客戶。例如，把電子下單系統(tǒng)和電子發(fā)票系統(tǒng)“暴露”出來，客戶就可以以電子的方式發(fā)送訂單，供應(yīng)商則可以以電子的方式發(fā)送原料采購發(fā)票。當(dāng)然，這并不是一個新的概念，EDI(電子文檔交換)早就是這樣了。但是，WebService的實現(xiàn)要比EDI簡單得多，而且WebService運行在Internet上，在世界任何地方都可輕易實現(xiàn)，其運行成本就相對較低。不過，WebService并不像EDI那樣，是文檔交換或B2B集成的完整解決方案。WebService只是B2B集成的一個關(guān)鍵部分，還需要許多其它的部分才能實現(xiàn)集成。用WebService來實現(xiàn)B2B集成的最大好處在于可以輕易實現(xiàn)互操作性。只要把商務(wù)邏輯“暴露”出來，成為WebService，就可以讓任何指定的合作伙伴調(diào)用這些商務(wù)邏輯，而不管他們的系統(tǒng)在什么平臺上運行，使用什么開發(fā)語言。這樣就大大減少了花在B2B集成上的時間和成本，讓許多原本無法承受EDI的中小企業(yè)也能實現(xiàn)B2B集成。長項四：軟件和數(shù)據(jù)重用軟件重用是一個很大的主題，重用的形式很多，重用的程度有大有小。最基本的形式是源代碼模塊或者類一級的重用，另一種形式是二進制形式的組件重用。當(dāng)前，像表格控件或用戶界面控件這樣的可重用軟件組件，在市場上都占有很大的份額。但這類軟件的重用有一個很大的限制，就是重用僅限于代碼，數(shù)據(jù)不能重用。原因在于，發(fā)布組件甚至源代碼都比較容易，但要發(fā)布數(shù)據(jù)就沒那么容易，除非是不會經(jīng)常變化的靜態(tài)數(shù)據(jù)。WebService在允許重用代碼的同時，可以重用代碼背后的數(shù)據(jù)。使用WebService，再也不必像以前那樣，要先從第三方購買、安裝軟件組件，再從應(yīng)用程序中調(diào)用這些組件；只需要直接調(diào)用遠端的WebService就可以了。舉個例子，要在應(yīng)用程序中確認用戶輸入的地址，只需把這個地址直接發(fā)送給相應(yīng)的WebService，這個WebService就會幫你查閱街道地址、城市、省區(qū)和郵政編碼等信息，確認這個地址是否在相應(yīng)的郵政編碼區(qū)域。WebService的提供商可以按時間或使用次數(shù)來對這項服務(wù)進行收費。這樣的服務(wù)要通過組件重用來實現(xiàn)是不可能的，那樣的話你必須下載并安裝好包含街道地址、城市、省區(qū)和郵政編碼等信息的數(shù)據(jù)庫，而且這個數(shù)據(jù)庫還是不能實時更新的。另一種軟件重用的情況是，把好幾個應(yīng)用程序的功能集成起來。例如，要建立一個局域網(wǎng)上的門戶站點應(yīng)用，讓用戶既可以查詢聯(lián)邦快遞包裹，查看股市行情，又可以管理自己的日程安排，還可以在線購買電影票。現(xiàn)在Web上有很多應(yīng)用程序供應(yīng)商，都在其應(yīng)用中實現(xiàn)了這些功能。一旦他們把這些功能都通過WebService“暴露”出來，就可以非常容易地把所有這些功能都集成到你的門戶站點中，為用戶提供一個統(tǒng)一的、友好的界面。將來，許多應(yīng)用程序都會利用WebService，把當(dāng)前基于組件的應(yīng)用程序結(jié)構(gòu)擴展為組件/WebService的混合結(jié)構(gòu)，可以在應(yīng)用程序中使用第三方的WebService提供的功能，也可以把自己的應(yīng)用程序功能通過WebService提供給別人。兩種情況下，都可以重用代碼和代碼背后的數(shù)據(jù)。1.5.2WebService技術(shù)的缺點從以上論述可以看出，WebService在通過Web進行互操作或遠程調(diào)用的時候是最有用的。不過，也有一些情況，WebService不能帶來任何好處。短處一：單機應(yīng)用程序目前，企業(yè)和個人還使用著很多桌面應(yīng)用程序。其中一些只需要與本機上的其它程序通信。在這種情況下，最好就不要用WebService，只要用本地的API就可以了。COM非常適合于在這種情況下工作，因為它既小又快。運行在同一臺服務(wù)器上的服務(wù)器軟件也是這樣。最好直接用COM或其它本地的API來進行應(yīng)用程序間的調(diào)用。當(dāng)然WebService也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。短處二：局域網(wǎng)的同構(gòu)應(yīng)用程序在許多應(yīng)用中，所有的程序都是用VB或VC開發(fā)的，都在Windows平臺下使用COM，都運行在同一個局域網(wǎng)上。例如，有兩個服務(wù)器應(yīng)用程序需要相互通信，或者有一個Win32或WinForm的客戶程序要連接局域網(wǎng)上另一個服務(wù)器的程序。在這些程序里，使用DCOM會比SOAP/HTTP有效得多。與此相類似，如果一個.NET程序要連接到局域網(wǎng)上的另一個.NET程序，應(yīng)該使用.NETremoting。有趣的是，在.NET Remoting中，也可以指定使用SOAP/HTTP來進行WebService調(diào)用。不過最好還是直接通過TCP進行RPC調(diào)用，那樣會有效得多?？傊瑧?yīng)當(dāng)從具體應(yīng)用環(huán)境出發(fā)，選擇最適當(dāng)?shù)慕鉀Q方案。第二章WebService技術(shù)與CORBA技術(shù)CORBA是20世紀90年代由OMG提出的分布式對象計算規(guī)范，經(jīng)過十幾年的的發(fā)展，已經(jīng)在很多關(guān)鍵業(yè)務(wù)處理中得到了廣泛的應(yīng)用。CORBA和WebService都是實現(xiàn)分布式技術(shù)的技術(shù)框架，在體系結(jié)構(gòu)、組成、技術(shù)實現(xiàn)甚至研究方法上都有可比之處，因此，將CORBA和WebService進行比較，借鑒CORBA研究和應(yīng)用中的成果，是發(fā)展和完善WebService技術(shù)的一種途徑。2.1CORBA技術(shù)的簡介CORBA實現(xiàn)了分布異構(gòu)環(huán)境中對象之間的透明請求調(diào)用，應(yīng)用程序無需考慮底層硬件平臺、操作系統(tǒng)、通信協(xié)議等細節(jié)，保證了分布式應(yīng)用的互操作性，其體系結(jié)構(gòu)如圖2-1所示。ORB核心（GIOPIIOP）動態(tài)調(diào)用IDL存根ORB界面靜態(tài)IDL框架動態(tài)框架調(diào)用對象適配器客 戶服 務(wù) 器圖 2-1 CORBA組成部分對象請求代理ORB負責(zé)接收客戶端的請求，并傳遞到目標(biāo)對象，將執(zhí)行結(jié)果返回給客戶程序。ORB是CORBA的核心，使應(yīng)用程序無需關(guān)心目標(biāo)對象的物理位置、實現(xiàn)和現(xiàn)行狀態(tài)等。CORBA使用OMG IDL定義了對象接口，并通過語言映射技術(shù)翻譯成對應(yīng)的編程語言，生成客戶端的存根和服務(wù)端的框架。存根將請求進行封裝以及對響應(yīng)進行解封裝；框架則在服務(wù)端完成互補的類似工作?？蛻舳顺绦蛲ㄟ^IDL存根發(fā)起對遠程對象的請求、請求到達服務(wù)端的對象適配器。對象適配器負責(zé)對象登記、定位、激活和撤銷等，它將請求調(diào)度到適合的對象實現(xiàn)，并將執(zhí)行結(jié)果返回給客戶。2.2 WebService技術(shù)和CORBA技術(shù)CORBA和WebService的共同點在于，它們都提供了一中分布計算領(lǐng)域的技術(shù)框架，因而都對分布式應(yīng)用面臨的問題提出了解決方法。分布式應(yīng)用最基本的要求是應(yīng)用能夠跨平臺調(diào)用，而CORBA和WebService都能夠屏蔽底層平臺的差異，使應(yīng)用程序與操作系統(tǒng)、通信協(xié)議無關(guān)，簡化了分布式應(yīng)用的開發(fā)。分布式應(yīng)用請求模式客戶端調(diào)用服務(wù)端的功能，這使二者都在體系結(jié)構(gòu)上有一個對方的概念。因為客戶端要調(diào)用服務(wù)端，要求客戶端對服務(wù)端有一定理解，因此，二者都采用了某種語言來描述服務(wù)方的接口。客戶端和服務(wù)端的分離，使客戶端在請求服務(wù)的時候，總需要一定方式來標(biāo)識服務(wù)方。如果客戶端不知道服務(wù)方的標(biāo)識，它就需要某種方式來查找所需的服務(wù)。CORBA和WebService都通過唯一標(biāo)識來識別服務(wù)方，并且都提供了服務(wù)的查找手段。應(yīng)用在進行關(guān)鍵業(yè)務(wù)處理時，要求操作的可靠性、安全性和服務(wù)質(zhì)量，而CORBA和WebService中都制訂了對應(yīng)的規(guī)范來滿足這些要求。表 2-1 WebService和CORBA對比項目WebServiceCORBA問題域Internet企業(yè)計算環(huán)境基本模型面向服務(wù)面向?qū)ο篑詈闲运缮Ⅰ詈暇o密耦合數(shù)據(jù)描述XML格式文檔二進制接口描述語言WSDLIDL傳輸協(xié)議SOAP（HTTP,SMTP）等HOP,GIOP位置表示URLIOR防火墻穿越容易難查找UDDI名字服務(wù)，交易服務(wù)安全性研究中安全服務(wù)事務(wù)處理研究中對象事物服務(wù)靈活的通信機制研究中事件、通知服務(wù)從表2-1中可以看到，WebServices與CORBA最根本的差異在與出發(fā)點不同。CORBA是20世紀90年代提出來的，主要是針對企業(yè)環(huán)境中業(yè)務(wù)處理所面臨的問題。面向?qū)ο笫菍嶋H應(yīng)用中證明非常有效的設(shè)計和開放模式，因此CORBA采用了面向?qū)ο蟮挠嬎隳Ｊ剑ㄟ@也決定了服務(wù)位置標(biāo)示采用對象引用的方式）；并且在企業(yè)環(huán)境中，業(yè)務(wù)聯(lián)系比較緊密，體現(xiàn)在處理業(yè)務(wù)的應(yīng)用程序之間也是緊密耦合的，因此其數(shù)據(jù)描述也采用了二進制方式。企業(yè)環(huán)境中關(guān)系可能很復(fù)雜，這要求非常靈活的通信機制，因此CORBA提供了事件、通知等多種方式。WebServices是伴隨著Internet的飛速發(fā)展而出現(xiàn)的。Internet中主要應(yīng)用是基于Web服務(wù)的應(yīng)用，因此WebServices采用了面向服務(wù)的模型。在廣闊的Internet上，業(yè)務(wù)之間的關(guān)系本身比企業(yè)內(nèi)的應(yīng)用簡單，這可以從早期的Web應(yīng)用主要是無狀態(tài)的請求/應(yīng)答模式看到，因此，WebServices中，請求方和服務(wù)之間也沒有始終保持的鏈接通道，是非常松散的耦合關(guān)系。為了保證松散耦合應(yīng)用程序能夠互相理解，具有自描述性的XML成了WebServices的數(shù)據(jù)描述方式，這也使WebServices具有可擴展性好、易于集成的優(yōu)點。在Internet上，URL成為WebServices標(biāo)示目標(biāo)服務(wù)自然的選擇。從上述分析可知，WebServices環(huán)境中，請求方和服務(wù)方是松散的耦合，請求以XML文檔的形式進行傳輸，接口的細微變化不會影響程序的正常執(zhí)行，具有更好的課擴展性；而CORBA環(huán)境中對象請求采用二進制傳輸，請求方和服務(wù)方是緊密耦合的，服務(wù)端接口一旦發(fā)生變化，客戶端就必須作相應(yīng)修改，否則就可能崩潰。CORBA采用IIOP進行傳輸，端口是動態(tài)分配的，請求很可能被防火墻拒絕；而WebServices主要基于HTTP，很容易穿越防火墻。在WebServices中，業(yè)務(wù)處理在Intenet上進行，這使參與者的信息更容易被竊聽和非法訪問，因此安全性要求更高。WebServices一個明顯的劣勢在于性能。XML文檔比同等信息量的CDR數(shù)據(jù)耗費更多內(nèi)存，也增加了網(wǎng)絡(luò)流量和傳輸時間，XML文檔的解析和轉(zhuǎn)換比CDR數(shù)據(jù)的編解碼需要更多內(nèi)容和處理時間。因此，一般來講，面向Internet的業(yè)務(wù)處理選擇WebService技術(shù)框架較為適宜。在企業(yè)環(huán)境中，如果業(yè)務(wù)之間關(guān)系緊密，或者對性能要求較高，CORBA等分布式對象模式更合適，如果業(yè)務(wù)關(guān)系較為松散，更關(guān)注開放性，則WebService是更佳選擇。11商丘科技職業(yè)學(xué)院畢業(yè)論文第三章WebService技術(shù)中的關(guān)鍵技術(shù)WebService涉及的最基本的技術(shù)規(guī)范包括XML、SOAP、WSDL和UDDI。WSDL是程序員描述WebService的編程接口。WebService可以通過UDDI來注冊自己的特性，其他應(yīng)用程序可以通過UDDI找到Web服務(wù)。SOAP則可提供了應(yīng)用程序和Web服務(wù)之間的通信手段。而WSDL、SOAP、和UDDI都是建立在XML基礎(chǔ)之上。3.1XML3.1.1簡介為了實現(xiàn)異構(gòu)系統(tǒng)(不同的平臺、編程語言和組件模型等)之間的互操作性，需提供一套標(biāo)準(zhǔn)通用的數(shù)據(jù)語言?？蓴U展標(biāo)記語言(XML Extensible Markup Language)已經(jīng)成為Internet的通用語言。在WebServices平臺中，采用XML表示數(shù)據(jù)的基本格式。XML能創(chuàng)建不依賴于平臺、編程語言的開放數(shù)據(jù)，具有平臺無關(guān)性。作為一個服務(wù)平臺，WebServices必須提供一種標(biāo)準(zhǔn)的數(shù)據(jù)類型系統(tǒng)，用于溝通不同系統(tǒng)之間的不同類型。萬維網(wǎng)聯(lián)盟(W3C)制定的XML Schema(XSL)定義了一套標(biāo)準(zhǔn)的數(shù)據(jù)類型來擴展這套數(shù)據(jù)類型。WebServices平臺采用XSD(XML Schema Definition)作為其數(shù)據(jù)類型系統(tǒng)。無論使用哪種語言構(gòu)造WebServices，最終都將被轉(zhuǎn)換為XSD類型。在實際應(yīng)用中，開發(fā)工具一般會幫助開發(fā)者完成這一轉(zhuǎn)換過程。3.1.2XML和HTML的差異XML和HTML的不同可以歸納為三點：1. XML擴展性優(yōu)于HTMLXML（Extensible Markup Languages）是擴展標(biāo)記語言的英語縮寫，他可以創(chuàng)建個性化的標(biāo)記語言，可以稱之為元語言。XML的標(biāo)記語言可以自定義，這樣可以提供更多的數(shù)據(jù)操作，而不像HTML一樣，只能局限于按一定的格式在終端顯示出來。HTML的功能只有瀏覽器放入顯示和打印，僅僅適合靜態(tài)網(wǎng)頁的要求。2. XML的語法比HTML嚴格由于XML的擴展性強，它需要穩(wěn)定的基礎(chǔ)規(guī)則來支持擴展。它的嚴格規(guī)則為： 起始和結(jié)束的標(biāo)簽相匹配 嵌套標(biāo)簽不能相互嵌套 區(qū)分大小寫相對應(yīng)XML的嚴格規(guī)則，HTML語言并沒有規(guī)定標(biāo)簽的絕對位置，也不區(qū)分大小寫，而這些全部由瀏覽器來完成識別和更正。3. XML與HTML互補XML可以獲得應(yīng)用之間的相應(yīng)信息，提供終端的多項處理要求，也能被其他的解析器和工具所使用，在現(xiàn)階段，XML可以轉(zhuǎn)化成相應(yīng)的HTML，來適應(yīng)當(dāng)前瀏覽器的需求。3.2SOAP簡單對象訪問協(xié)議（SOAP Simple Object Access Protocol）是一種輕量的、簡單的、基于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)當(dāng)處理它以及它是可選的還是必須的。 SOAP的編碼規(guī)則：它定義了一種序列化的機制，用于交換應(yīng)用程序所定義的數(shù)據(jù)類型的實例。 SOAP的RPC表示：它定義了用于表示遠程過程調(diào)用和應(yīng)答的協(xié)定。 SOAP協(xié)議的消息基本上是從發(fā)送端到接收端的單向傳輸，但它們常常結(jié)合起來執(zhí)行類似于請求/應(yīng)答的模式。所有的SOAP消息都使用XML編碼。一條SOAP消息就是一個包含有一個必需的SOAP的封裝包，一個可選的SOAP標(biāo)頭和一個必需的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é)議綁定。SOAP也可以綁定到TCP和UDP協(xié)議上。性能：SOAP用XML將消息編碼，因此在調(diào)用過程的任何一步都極易處理消息。另外，調(diào)試SOAP消息的方便性使各種SOAP執(zhí)行能快速聚合在一起，這點很重要因為SOAP就是要達到大范圍的協(xié)同工作。（CORBA、DCOM和RMI對參數(shù)和返回值使用二進制編碼。除此之外，他們假設(shè)發(fā)送端和接收端充分了解消息的前后關(guān)系，因此對諸如參數(shù)名稱或類型的任何元信息都不編碼。這種方法產(chǎn)生了良好的性能，但使中介很難處理消息。因為每個系統(tǒng)使用不同的二進制編碼，所以建立互操作的系統(tǒng)很難）。表面看來，基于XML的模式本應(yīng)比基于二進制的慢，但它并不像表面那么簡單。首先，當(dāng)SOAP被用于通過因特網(wǎng)發(fā)送消息時，在每個端點給消息編碼/解碼的時間與在端點間傳輸字節(jié)的時間相比較是微不足道的，所以這種情況下使用XML沒太大問題。其次，當(dāng)SOAP用于封閉環(huán)境下的點對點間的消息傳送，如在同一公司部門間的傳送時，各端點可能將運行相同的SOAP執(zhí)行。這樣，這個特定執(zhí)行就擁有專門的優(yōu)化機會。例如，一個SOAP客戶端可添加一個HTTP header標(biāo)記到SOAP請求上，這個請求說明它支持一個特定的優(yōu)化。如果SOAP服務(wù)器也支持那個優(yōu)化，它會在第一個SOAP響應(yīng)中返回一個HTTP header標(biāo)記，告訴客戶端可以在下面的通信中使用這種優(yōu)化。接下來，客戶端和服務(wù)器可以開始使用這種優(yōu)化了。3.3WSDL和UDDI規(guī)范作為一個服務(wù)平臺，WebServices必須具備相應(yīng)的一套機制。用機器能閱讀的方式提供一個正式的描述文檔，為程序員調(diào)用服務(wù)提供幫助，使其更易于了解和使用WebServices，所采用的解決辦法是通過WSDL和UDDI協(xié)議達到其目的。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ù)的屬性，例如它做什么，它位于哪里和怎樣調(diào)用它）。WSDL文檔可用于動態(tài)發(fā)布WebServices、查找已發(fā)布的WebServices以及綁定WebServices。WSDL 文件包含以下元素：Type：使用某種語法（如XML模式）的數(shù)據(jù)類型定義（string、int）。 Message：要傳遞的數(shù)據(jù)。Part：消息參數(shù)。Operation：服務(wù)支持的操作的抽象描述。Port Type / Interface：一個或多個端點支持的操作的抽象集，此名稱已更改，因此可能會遇到兩者中的任何一個。 Binding：特定端口類型的具體協(xié)議和數(shù)據(jù)格式規(guī)范。Port / Endpoint：綁定和網(wǎng)絡(luò)地址的組合，此名稱也已更改，因此可能會遇到兩者中的任何一個。Service：相關(guān)端點的集合，包括其關(guān)聯(lián)的接口、操作、消息等。在WSDL中包含了使用SOAP的服務(wù)描述的綁定，也包含了使用簡單HTTP GET和POST請求的服務(wù)描述的綁定。WSDL將Web服務(wù)定義成一系列的端口（port），每個端口用來表示從抽象端口類型（port type）到用于調(diào)用Web服務(wù)的具體通信協(xié)議的一個映射。端口類型由一組與Service provider交換信息的操作組成，它支持對包含消息的數(shù)據(jù)類型的定義。一個完整的WSDL服務(wù)描述是由一個服務(wù)接口和一個服務(wù)實現(xiàn)文檔組成的。 由于服務(wù)接口表示服務(wù)的可重用定義，它在UDDI注冊中心被作為tModel發(fā)布。服務(wù)實現(xiàn)描述服務(wù)的實例。每個實例都是使用一個WSDL service元素定義的。服務(wù)實現(xiàn)文檔中的每個service元素都被用于發(fā)布UDDI businessService。因為WSDL包含了對服務(wù)接口的完整描述，所以可以使用它來創(chuàng)建能簡化服務(wù)訪問的存根，該存根為一段Java代碼（假設(shè)使用Java），它自動生成了訪問Web服務(wù)的類。如果需要訪問Web服務(wù)，只需調(diào)用該類中對應(yīng)的方法即可，而不用在客戶端程序中再寫入那些令人頭疼的配置信息了。通過IBM提供的工具包可以輕松創(chuàng)建WSDL文檔對應(yīng)的存根。（由此看出，不用WSDL也可以訪問Web服務(wù)）WSDL取代了IBM的NASSL（Network-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ù)注冊，以及使用SOAP訪問這些注冊信息的約定來實現(xiàn)上述目標(biāo)。UDDI計劃的核心組件是UDDI商業(yè)注冊，它使用一個XML文檔來描述企業(yè)及其提供的Web服務(wù)。從概念上來說，UDDI商業(yè)注冊所提供的信息包含三個部分：“白頁(White Page)”包括了地址，聯(lián)系方法，和已知的企業(yè)標(biāo)識；“黃頁(Yellow page)”包括了基于標(biāo)準(zhǔn)分類法的行業(yè)類別；“綠頁(Green Page)”則包括了關(guān)于該企業(yè)所提供的Web服務(wù)的技術(shù)信息，其形式可能是一些指向文件或是URL的指針，而這些文件或URL是為服務(wù)發(fā)現(xiàn)機制服務(wù)的。所有的UDDI商業(yè)注冊信息存儲在UDDI商業(yè)注冊中心中。 借助XML和SOAP，集成和交互的問題將從層次上被簡化。XML提供了跨平臺的數(shù)據(jù)編碼和組織方法，而SOAP建立在XML之上，定義了一種跨系統(tǒng)平臺的信息交換的簡單包裝方法。綁定于HTTP之上的SOAP協(xié)議，可以跨語言、跨操作系統(tǒng)進行遠程過程調(diào)用(RPC)，實現(xiàn)了編程語言和系統(tǒng)平臺的無關(guān)性。而以前的調(diào)用方式則和復(fù)雜的分布式對象標(biāo)準(zhǔn)或是中間件有密切的關(guān)系，從長期的眼光來看，這些都不是高效的解決方案。XML和SOAP這樣的跨語言、跨平臺的解決方案大大簡化了不同企業(yè)系統(tǒng)之間的交互問題。但如果僅僅是XML和SOAP的話，對于公司間的交流仍存在著巨大的鴻溝。UDDI規(guī)范在XML和SOAP的基礎(chǔ)之上定義了新的一層，在這一層次，不同企業(yè)可以用相同的方法描述自己所能提供的，并能查詢對方所能提供的服務(wù)。UDDI注冊使用的核心信息模型由XML Schema定義。使用XML 是因為它提供了平臺無關(guān)的數(shù)據(jù)描述并很自然的描述了數(shù)據(jù)的層次關(guān)系。而選擇XML Schema是因為它支持豐富的數(shù)據(jù)類型，便捷的描述方式及其按信息模型對數(shù)據(jù)進行驗證的能力。UDDI XML Schema定義了四種主要信息類型，它們是技術(shù)人員在需要使用合作伙伴所提供的Web服務(wù)時必須了解的技術(shù)信息。它們是：商業(yè)實體信息、服務(wù)信息、綁定信息和服務(wù)調(diào)用規(guī)范的說明信息。UDDI程序員API規(guī)范分為兩個邏輯部分：查詢API和發(fā)布API。查詢API又分為兩個部分：一部分被用來構(gòu)造搜索和瀏覽UDDI注冊信息的程序，另一部分在Web服務(wù)出現(xiàn)錯誤時使用。程序員可以利用發(fā)布API創(chuàng)建各種類型的工具，以直接與UDDI注冊中心進行交互，便于企業(yè)技術(shù)人員管理businessEntity