WebService學習總結（一）--WebService的相關概念

1、序言

　　你們或多或少都聽過 WebService（Web服務），有一段時間不少計算機期刊、書籍和網站都大肆的說起和宣傳WebService技術，其中不乏不少吹噓和作廣告的成 分。可是不得不認可的是WebService真的是一門新興和有前途的技術，那麼WebService究竟是什麼？什麼時候應該用？

　　當前的應用程序開發逐步的呈現了兩種迥然不一樣的傾向：一種是基於瀏覽器的瘦客戶端應用程序，一種是基於瀏覽器的富客戶端應用程序（RIA），固然後一種技術相對來講更加的時髦一些（如如今很流行的Html5技術），這裏主要講前者。

　　基於瀏覽器的瘦客戶端應用程序並非 由於瘦客戶可以提供更好的用戶界面，而是由於它可以避免花在桌面應用程序發佈上的高成本。發佈桌面應用程序成本很高，一半是由於應用程序安裝和配置的問 題，另外一半是由於客戶和服務器之間通訊的問題。傳統的Windows富客戶應用程序使用DCOM來與服務器進行通訊和調用遠程對象。配置好DCOM使其在 一個大型的網絡中正常工做將是一個極富挑戰性的工做，同時也是許多IT工程師的噩夢。事實上，許多IT工程師寧願忍受瀏覽器所帶來的功能限制，也不肯在局 域網上去運行一個DCOM。關於客戶端與服務器的通訊問題，一個完美的解決方法是使用HTTP協議來通訊。這是由於任何運行Web瀏覽器的機器都在使用 HTTP協議。同時，當前許多防火牆也配置爲只容許HTTP鏈接。許多商用程序還面臨另外一個問題，那就是與其餘程序的互操做性。若是全部的應用程序都是使 用COM或.NET語言寫的，而且都運行在Windows平臺上，那就天下太平了。然而，事實上大多數商業數據仍然在大型主機上以非關係文件(VSAM) 的形式存放，並由COBOL語言編寫的大型機程序訪問。並且，目前還有不少商用程序繼續在使用C++、Java、Visual Basic和其餘各類各樣 的語言編寫。如今，除了最簡單的程序以外，全部的應用程序都須要與運行在其餘異構平臺上的應用程序集成並進行數據交換。這樣的任務一般都是由特殊的方法， 如文件傳輸和分析，消息隊列，還有僅適用於某些狀況的的API，如IBM的高級程序到程序交流(APPC)等來完成的。在之前，沒有一個應用程序通訊標 準，是獨立於平臺、組建模型和編程語言的。只有經過Web Service，客戶端和服務器纔可以自由的用HTTP進行通訊，不論兩個程序的平臺和編程語言是什麼。

2、WebService究竟是什麼

   一言以蔽之：WebService是一種跨編程語言和跨操做系統平臺的遠程調用技術。

   所謂跨編程語言和跨操做平臺，就是說服務端程序採用java編寫，客戶端程序則能夠採用其餘編程語言編寫，反之亦然！跨操做系統平臺則是指服務端程序和客戶端程序能夠在不一樣的操做系統上運行。

    所謂遠程調用，就是一臺計算機a上 的一個程序能夠調用到另一臺計算機b上的一個對象的方法，譬如，銀聯提供給商場的pos刷卡系統，商場的POS機轉帳調用的轉帳方法的代碼實際上是跑在銀 行服務器上。再好比，amazon，天氣預報系統，淘寶網，校內網，百度等把本身的系統服務以webservice服務的形式暴露出來，讓第三方網站和程 序能夠調用這些服務功能，這樣擴展了本身系統的市場佔有率，往大的概念上吹，就是所謂的SOA應用。

   其實能夠從多個角度來理解 WebService，從表面上看，WebService就是一個應用程序向外界暴露出一個能經過Web進行調用的API，也就是說能用編程的方法經過 Web來調用這個應用程序。咱們把調用這個WebService的應用程序叫作客戶端，而把提供這個WebService的應用程序叫作服務端。從深層次 看，WebService是創建可互操做的分佈式應用程序的新平臺，是一個平臺，是一套標準。它定義了應用程序如何在Web上實現互操做性，你能夠用任何 你喜歡的語言，在任何你喜歡的平臺上寫Web service ，只要咱們能夠經過Web service標準對這些服務進行查詢和訪問。 

   WebService平臺須要一套協議來實現分佈式應用程序的建立。任何平臺都有它的數據表示方法和類型系統。要實現互操做性，WebService平臺 必須提供一套標準的類型系統，用於溝通不一樣平臺、編程語言和組件模型中的不一樣類型系統。Web service平臺必須提供一種標準來描述 Web service，讓客戶能夠獲得足夠的信息來調用這個Web service。最後，咱們還必須有一種方法來對這個Web service進行遠 程調用,這種方法實際是一種遠程過程調用協議(RPC)。爲了達到互操做性，這種RPC協議還必須與平臺和編程語言無關。

3、WebService平臺技術

  XML+XSD,SOAP和WSDL就是構成WebService平臺的三大技術。

3.一、XML+XSD

　　WebService採用HTTP協議傳輸數據，採用XML格式封裝數據（即XML中說明調用遠程服務對象的哪一個方法，傳遞的參數是什麼，以及服務對象的 返回結果是什麼）。XML是WebService平臺中表示數據的格式。除了易於創建和易於分析外，XML主要的優勢在於它既是平臺無關的，又是廠商無關 的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。 

　　XML解決了數據表示的問題，但它沒有定義一套標準的數據類型，更沒有說怎麼去擴展這套數據類型。例如，整形數到底表明什麼？16位，32位，64位？這 些細節對實現互操做性很重要。XML Schema(XSD)就是專門解決這個問題的一套標準。它定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。WebService平臺就 是用XSD來做爲其數據類型系統的。當你用某種語言(如VB.NET或C#)來構造一個Web service時，爲了符合WebService標準，所 有你使用的數據類型都必須被轉換爲XSD類型。你用的工具可能已經自動幫你完成了這個轉換，但你極可能會根據你的須要修改一下轉換過程。

3.二、SOAP

   WebService經過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都採用XML格式封裝，並增長了一些特定的HTTP消息頭，以說明 HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議。SOAP提供了標準的RPC方法來調用Web Service。

  SOAP協議 = HTTP協議 + XML數據格式

  SOAP協議定義了SOAP消息的格式，SOAP協議是基於HTTP協議的，SOAP也是基於XML和XSD的，XML是SOAP的數據編碼方式。打個比 喻：HTTP就是普通公路，XML就是中間的綠色隔離帶和兩邊的防禦欄，SOAP就是普通公路通過加隔離帶和防禦欄改造過的高速公路。

3.三、WSDL

　　比如咱們去商店買東西，首先要知道商店裏有什麼東西可買，而後再來購買，商家的作法就是張貼廣告海報。 WebService也同樣，WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務裏有什麼方 法能夠調用，因此，WebService務器端首先要經過一個WSDL文件來講明本身家裏有啥服務能夠對外調用，服務是什麼（服務中有哪些方法，方法接受 的參數是什麼，返回值是什麼），服務的網絡地址用哪一個url地址表示，服務經過什麼方式來調用。

　　WSDL(Web Services Description Language)就是這樣一個基於XML的語言，用於描述Web Service及其函數、參數和返回值。它是WebService客戶端和服務器端都 能理解的標準格式。由於是基於XML的，因此WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的 Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應WebService的代理類代碼。

　　WSDL 文件保存在Web服務器上，經過一個url地址就能夠訪問到它。客戶端要調用一個WebService服務以前，要知道該服務的WSDL文件的地址。 WebService服務提供商能夠經過兩種方式來暴露它的WSDL文件地址：1.註冊到UDDI服務器，以便被人查找；2.直接告訴給客戶端調用者。

4、WebService開發

　　WebService開發能夠分爲服務器端開發和客戶端開發兩個方面

4.一、服務端開發

　　把公司內部系統的業務方法發佈成WebService服務，供遠程合做單位和我的調用。(藉助一些WebService框架能夠很輕鬆地把本身的業務對象發佈成WebService服務，Java方面的典型WebService框架包括：axis，xfire，cxf 等，java ee服務器一般也支持發佈WebService服務，例如JBoss。)

4.二、客戶端開發 

　　調用別人發佈的WebService服務，大多數人從事的開發都屬於這個方面，例如，調用天氣預報WebService服務。（使用廠 商的WSDL2Java之類的工具生成靜態調用的代理類代碼；使用廠商提供的客戶端編程API類；使用SUN公司早期標準的jax-rpc開發包；使用 SUN公司最新標準的jax-ws開發包。固然SUN已被ORACLE收購)

4.三、WebService 的工做調用原理

   對客戶端而言，咱們給這各種WebService客戶端API傳遞wsdl文件的url地址，這些API就會建立出底層的代理類，我調用 這些代理，就能夠訪問到webservice服務。代理類把客戶端的方法調用變成soap格式的請求數據再經過HTTP協議發出去，並把接收到的soap 數據變成返回值返回。對服務端而言，各種WebService框架的本質就是一個大大的Servlet，當遠程調用客戶端給它經過http協議發送過來 soap格式的請求數據時，它分析這個數據，就知道要調用哪一個java類的哪一個方法，因而去查找或建立這個對象，並調用其方法，再把方法返回的結果包裝成 soap格式的數據，經過http響應消息回給客戶端。

5、適用場合

一、跨防火牆通訊

　　若是應用程序有成千上萬的用戶，並且分佈在世界各地，那麼客戶端和服務器之間的通訊將是一個棘手的問題。由於客戶端和服務器之間一般會有防火牆或者代理服 務器。在這種狀況下，使用DCOM就不是那麼簡單，一般也不便於把客戶端程序發佈到數量如此龐大的每個用戶手中。傳統的作法是，選擇用瀏覽器做爲客戶 端，寫下一大堆ASP頁面，把應用程序的中間層暴露給最終用戶。這樣作的結果是開發難度大，程序很難維護。若是中間層組件換成WebService的話， 就能夠從用戶界面直接調用中間層組件。從大多數人的經驗來看，在一個用戶界面和中間層有較多交互的應用程序中，使用WebService這種結構，能夠節 省花在用戶界面編程上20%的開發時間。

二、應用程序集成

　　企業級的應用程序開發者都知道，企業裏常常都要把用不一樣語言寫成的、在不一樣平臺上運行的各類程序集成起來，而這種集成將花費很大的開發力量。應用程序常常 須要從運行在IBM主機上的程序中獲取數據；或者把數據發送到主機或UNIX應用程序中去。即便在同一個平臺上，不一樣軟件廠商生產的各類軟件也經常須要集 成起來。經過WebService，能夠很容易的集成不一樣結構的應用程序。

三、B2B集成

　　用WebService集成應用程序，可使公司內部的商務處理更加自動化。但當交易跨越供應商和客戶、突破公司的界限時會怎麼樣呢？跨公司的商務交易集成一般叫作B2B集成。WebService是B2B集成成功的關鍵。經過WebService，公司能夠把關鍵的商務應用「暴露」給指定的供應商和客戶。例如，把電子下單系統和電子發票系統「暴露」出來，客戶就能夠以電子的方式發送訂單，供應商則能夠以電子的方式發送原料採購發票。固然，這並非一個 新的概念，EDI(電子文檔交換)早就是這樣了。可是，WebService的實現要比EDI簡單得多，並且WebService運行在Internet 上，在世界任何地方均可輕易實現，其運行成本就相對較低。不過，WebService並不像EDI那樣，是文檔交換或B2B集成的完整解決方案。 WebService只是B2B集成的一個關鍵部分，還須要許多其它的部分才能實現集成。

　　用WebService來實現B2B集成的最大好處在於能夠輕易實現互操做性。只要把商務邏輯「暴露」出來，成爲WebService，就可讓任何指定 的合做夥伴調用這些商務邏輯，而無論他們的系統在什麼平臺上運行，使用什麼開發語言。這樣就大大減小了花在B2B集成上的時間和成本，讓許多本來沒法承受 EDI的中小企業也能實現B2B集成。

四、軟件和數據重用

      軟件重用是一個很大的主題，重用的形式不少，重用的程度有大有小。最基本的形式是源代碼模塊或者類一級的重用，一種形式是二進制形式的組件重用。採用 WebService應用程序能夠用標準的方法把功能和數據「暴露」出來，供其它應用程序使用，達到業務級重用。

6、不適用場合

一、單機應用程序

      目前，企業和我的還使用着不少桌面應用程序。其中一些只須要與本機上的其它程序通訊。在這種狀況下，最好就不要用WebService，只要用本地的 API就能夠了。COM很是適合於在這種狀況下工做，由於它既小又快。運行在同一臺服務器上的服務器軟件也是這樣。最好直接用COM或其它本地的API來 進行應用程序間的調用。固然WebService也能用在這些場合，但那樣不只消耗太大，並且不會帶來任何好處。

二、局域網的同構應用程序

      在許多應用中，全部的程序都是用VB或VC開發的，都在Windows平臺下使用COM，都運行在同一個局域網上。例如，有兩個服務器應用程序須要相互通 信，或者有一個Win32或WinForm的客戶程序要鏈接局域網上另外一個服務器的程序。在這些程序裏，使用DCOM會比SOAP/HTTP有效得多。與 此相相似，若是一個.NET程序要鏈接到局域網上的另外一個.NET程序，應該使用.NETremoting。有趣的是，在.NETremoting 中，也能夠指定使用SOAP/HTTP來進行WebService調用。不過最好仍是直接經過TCP進行RPC調用，那樣會有效得多。