WebService究竟是什麼？

一、序言

  大家或多或少都聽過WebService（Web服務），有一段時間非常多計算機期刊、書籍和站點都大肆的提及和宣傳WebService技術，當中不乏非常多吹噓和做廣告的成分。可是不得不承認的是WebService真的是一門新興和有前途的技術，那麼WebService究竟是什麼？何時應該用？

   目前的應用程式開發逐漸的呈現了兩種迥然不同的傾向：一種是基于浏覽器的瘦client應用程式，一種是基于浏覽器的富client應用程式（RIA），當然後一種技術相對來說更加的時髦一些（如如今非常流行的Html5技術），這裡主要講前者。

   基于浏覽器的瘦client應用程式并非由于瘦客戶可以提供更好的使用者界面，而是由于它可以避免花在桌面應用程式公布上的高成本。公布桌面應用程式成本非常高，一半是由于應用程式安裝和配置的問題，還有一半是由于客戶和server之間通信的問題。傳統的Windows富客戶應用程式使用DCOM來與server進行通信和調用遠端對象。配置好DCOM使其在一個大型的網絡中正常工作将是一個極富挑戰性的工作，同一時候也是很多ITproject師的噩夢。其實，很多ITproject師甯願忍受浏覽器所帶來的功能限制，也不願在區域網路上去執行一個DCOM。關于client與server的通信問題，一個完美的解決方法是使用HTTP協定來通信。這是由于不論什麼執行Web浏覽器的機器都在使用HTTP協定。同一時候，目前很多防火牆也配置為僅僅同意HTTP連接配接。很多商用程式還面臨還有一個問題，那就是與其它程式的互操作性。假設全部的應用程式都是使用COM或.NET語言寫的，并且都執行在Windows平台上，那就天下太平了。然而，其實大多數商業資料仍然在大型主機上以非關系檔案(VSAM)的形式存放，并由COBOL語言編寫的大型機程式訪問。并且，眼下還有非常多商用程式繼續在使用C++、Java、Visual Basic和其它各種各樣的語言編寫。如今，除了最簡單的程式之外，全部的應用程式都須要與執行在其它異構平台上的應用程式內建并進行資料交換。這種任務通常都是由特殊的方法，如檔案傳輸和分析，消息隊列，還有僅适用于某些情況的的API，如IBM的進階程式到程式交流(APPC)等來完畢的。在曾經，沒有一個應用程式通信标準，是獨立于平台、組模組化型和程式設計語言的。僅僅有通過Web Service，client和server才可以自由的用HTTP進行通信，不論兩個程式的平台和程式設計語言是什麼。

二、WebService究竟是什麼？

   一言以蔽之：WebService是一種跨程式設計語言和跨作業系統平台的遠端調用技術。

   所謂跨程式設計語言和跨操作平台，就是說服務端程式採用java編寫，client程式則能夠採用其它程式設計語言編寫，反之亦然！跨作業系統平台則是指服務端程式和client程式能夠在不同的作業系統上執行。

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

   事實上能夠從多個角度來了解WebService，從表面上看，WebService就是一個應用程式向外界暴露出一個能通過Web進行調用的API，也就是說能用程式設計的方法通過Web來調用這個應用程式。我們把調用這個WebService的應用程式叫做client，而把提供這個WebService的應用程式叫做服務端。從深層次看，WebService是建立可互操作的分布式應用程式的新平台，是一個平台，是一套标準。它定義了應用程式怎樣在Web上實作互操作性，你能夠用不論什麼你喜歡的語言，在不論什麼你喜歡的平台上寫Web service ，僅僅要我們能夠通過Web service标準對這些服務進行查詢和訪問。 

   WebService平台須要一套協定來實作分布式應用程式的建立。不論什麼平台都有它的資料表示方法和類型系統。要實作互操作性，WebService平台必須提供一套标準的類型系統，用于溝通不同平台、程式設計語言群組件模型中的不同類型系統。Web service平台必須提供一種标準來描寫叙述Web service，讓客戶能夠得到足夠的資訊來調用這個Web service。最後，我們還必須有一種方法來對這個Web service進行遠端調用,這樣的方法實際是一種遠端過程調用協定(RPC)。為了達到互操作性，這樣的RPC協定還必須與平台和程式設計語言無關。

三、WebService平台技術

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

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類型。你用的工具可能已經自己主動幫你完畢了這個轉換，但你非常可能會依據你的須要改動一下轉換過程。

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就是普通公路經過加隔離帶和防護欄改造過的快速公路。

WSDL：

   好比我們去商店買東西，首先要知道商店裡有什麼東西可買，然後再來購買，商家的做法就是張貼廣告海報。 WebService也一樣，WebServiceclient要調用一個WebService服務，首先要有知道這個服務的位址在哪，以及這個服務裡有什麼方法能夠調用，是以，WebService務器端首先要通過一個WSDL檔案來說明自己家裡有啥服務能夠對外調用，服務是什麼（服務中有哪些方法，方法接受的參數是什麼，傳回值是什麼），服務的網絡位址用哪個url位址表示，服務通過什麼方式來調用。

   WSDL(Web Services Description Language)就是這樣一個基于XML的語言，用于描寫叙述Web Service及其函數、參數和傳回值。它是WebServiceclient和server端都能了解的标準格式。由于是基于XML的，是以WSDL既是機器可閱讀的，又是人可閱讀的，這将是一個非常大的優點。一些最新的開發工具既能依據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用對應WebService的代理類代碼。

  WSDL檔案儲存在Webserver上，通過一個url位址就能夠訪問到它。client要調用一個WebService服務之前，要知道該服務的WSDL檔案的位址。WebService服務提供商能夠通過兩種方式來暴露它的WSDL檔案位址：1.注冊到UDDIserver，以便被人查找；2.直接告訴給client調用者。

四、WebService開發

  WebService開發能夠分為server端開發和client開發兩個方面：

   服務端開發：把公司内部系統的業務方法公布成WebService服務，供遠端合作機關和個人調用。(借助一些WebService框   架能夠非常輕松地把自己的業務對象公布成WebService服務，Java方面的典型WebService架構包含：axis，xfire，cxf等，java eeserver通常也支援公布WebService服務，比如JBoss。)

   client開發：調用别人公布的WebService服務，大多數人從事的開發都屬于這個方面，比如，調用天氣預報WebService服務。（使用廠商的WSDL2Java之類的工具生成靜态調用的代理類代碼；使用廠商提供的client程式設計API類；使用SUN公司早期标準的jax-rpc開發包；使用SUN公司最新标準的jax-ws開發包。當然SUN已被ORACLE收購)

   WebService的工作調用原理：對client而言，我們給這各類WebServiceclientAPI傳遞wsdl檔案的url位址，這些API就會建立出底層的代理類，我調用這些代理，就能夠訪問到webservice服務。代理類把client的方法調用變成soap格式的請求資料再通過HTTP協定發出去，并把接收到的soap資料變成傳回值傳回。對服務端而言，各類WebService架構的本質就是一個大大的Servlet，當遠端調用client給它通過http協定發送過來soap格式的請求資料時，它分析這個資料，就知道要調用哪個java類的哪個方法，于是去查找或建立這個對象，并調用其方法，再把方法傳回的結果包裝成soap格式的資料，通過http響應消息回給client。

五、适用場合

1、跨防火牆通信：

   假設應用程式有成千上萬的使用者，并且分布在世界各地，那麼client和server之間的通信将是一個棘手的問題。由于client和server之間一般會有防火牆或者代理server。在這樣的情況下，使用DCOM就不是那麼簡單，通常也不便于把client程式公布到數量如此龐大的每個使用者手中。傳統的做法是，選擇用浏覽器作為client，寫下一大堆ASP頁面，把應用程式的中間層暴露給終于使用者。這樣做的結果是開發難度大，程式非常難維護。假設中間層元件換成WebService的話，就能夠從使用者界面直接調用中間層元件。從大多數人的經驗來看，在一個使用者界面和中間層有較多互動的應用程式中，使用WebService這樣的結構，能夠節省花在使用者界面程式設計上20%的開發時間。

2、應用程式內建：

   企業級的應用程式開發人員都知道，企業裡常常都要把用不同語言寫成的、在不同平台上執行的各種程式內建起來，而這樣的內建将花費非常大的開發力量。應用程式常常須要從執行在IBM主機上的程式中擷取資料；或者把資料發送到主機或UNIX應用程式中去。即使在同一個平台上，不同軟體廠商生産的各種軟體也常常須要內建起來。通過WebService，能夠非常easy的內建不同結構的應用程式。

3、B2B內建：

   用WebService內建應用程式，能夠使公司内部的商務處理更加自己主動化。但當交易跨越供應商和客戶、突破公司的界限時會怎麼樣呢？跨公司的商務交易內建通常叫做B2B內建。WebService是B2B內建成功的關鍵。通過WebService，公司能夠把關鍵的商務應用“暴露”給指定的供應商和客戶。比如，把電子下單系統和電子發票系統“暴露”出來，客戶就能夠以電子的方式發送訂單，供應商則能夠以電子的方式發送原料採購發票。當然，這并非一個新的概念，EDI(電子文檔交換)早就是這樣了。可是，WebService的實作要比EDI簡單得多，并且WebService執行在Internet上，在世界不論什麼地方都可輕易實作，其執行成本就相對較低。隻是，WebService并不像EDI那樣，是文檔交換或B2B內建的完整解決方式。WebService僅僅是B2B內建的一個關鍵部分，還須要很多其他的部分才幹實作內建。

   用WebService來實作B2B內建的最大優點在于能夠輕易實作互操作性。僅僅要把商務邏輯“暴露”出來，成為WebService，就能夠讓不論什麼指定的合作夥伴調用這些商務邏輯，而無論他們的系統在什麼平台上執行，使用什麼開發語言。這樣就大大降低了花在B2B內建上的時間和成本，讓很多原本無法承受EDI的中小企業也能實作B2B內建。

4、軟體和資料重用：    

      軟體重用是一個非常大的主題，重用的形式非常多，重用的程度有大有小。最主要的形式是源碼子產品或者類一級的重用，一種形式是二進制形式的元件重用。採用WebService應用程式能夠用标準的方法把功能和資料“暴露”出來，供其他應用程式使用，達到業務級重用。

六、不适用場合

1、單機應用程式：

      眼下，企業和個人還使用着非常多桌面應用程式。當中一些僅僅須要與本機上的其他程式通信。在這樣的情況下，最好就不要用WebService，僅僅要用本地的 API就能夠了。COM非常适合于在這樣的情況下工作，由于它既小又快。執行在同一台server上的server軟體也是這樣。最好直接用COM或其他本地的API來進行應用程式間的調用。當然WebService也能用在這些場合，但那樣不僅消耗太大，并且不會帶來不論什麼優點。

2、區域網路的同構應用程式：

      在很多應用中，全部的程式都是用VB或VC開發的，都在Windows平台下使用COM，都執行在同一個區域網路上。比如，有兩個server應用程式須要互相通信，或者有一個Win32或WinForm的客戶程式要連接配接區域網路上還有一個server的程式。在這些程式裡，使用DCOM會比SOAP/HTTP有效得多。與此相類似，假設一個.NET程式要連接配接到區域網路上的還有一個.NET程式，應該使用.NETremoting。有趣的是，在.NETremoting 中，也能夠指定使用SOAP/HTTP來進行WebService調用。隻是不妨直接通過TCP進行RPC調用，那樣會有效得多。