一、序言
大家或多或少都聽過 WebService（Web服務），有一段時間很多電腦期刊、書籍和網站都大肆的提及和宣傳WebService技術，其中不乏很多吹噓和做廣告的成 分。但不得不承認的是WebService真的是一門新興且有前景的技術，那麼WebService到底是什麼？何時該用？
當前的應用程式開發逐步的呈現了兩種迥然不同的傾向：一種是基於瀏覽器的瘦客戶端應用程序，一種是基於瀏覽器的富客戶端應用程序（RIA），當然後一種技術相對來說更加的時髦一些（如現在很流行的Html5技術），這裡主要講前者。
基於瀏覽器的瘦客戶端應用程式並不是 因為瘦客戶能夠提供更好的使用者介面，而是因為它能夠避免花在桌面應用程式發布上的高成本。發布桌面應用程式成本很高，一半是因為應用程式安裝和配置的問 題，另一半是因為客戶和伺服器之間通訊的問題。傳統的Windows豐富客戶應用程式使用DCOM來與伺服器進行通訊並呼叫遠端物件。配置DCOM使其在 一個大型的網路中正常工作將是一個極富挑戰性的工作，同時也是許多IT工程師的噩夢。事實上，許多IT工程師寧願忍受瀏覽器所帶來的功能限制，也不願在區域 域網路上去執行一個DCOM。關於客戶端與伺服器的通訊問題，一個完美的解決方法是使用HTTP協定來通訊。這是因為任何執行網頁瀏覽器的機器都在使用 HTTP協定。同時，目前許多防火牆也配置為只允許HTTP連線。許多商用程式還面臨另一個問題，那就是與其他程式的互通性。如果所有的應用程式都是使 用COM或.NET語言寫的，並且都運行在Windows平台上，那就天下太平了。然而，事實上大多數商業資料仍然在大型主機上以非關聯式檔案(VSAM) 的形式存放，並由COBOL語言編寫的大型主機程式存取。而且，目前還有很多商用程式繼續在使用C++、Java、Visual Basic和其他各種各樣的語言編寫中。現在，除了最簡單的程式之外，所有的應用程式都需要與運行在其他異質平台上的應用程式整合並進行資料交換。這樣的任務通常都是由特殊的方法， 如檔案傳輸和分析，訊息佇列，還有僅適用於某些情況的的API，如IBM的高階程式到程式交流(APPC)等來完成的。在以前，沒有一個應用程式通訊標 準，是獨立於平台、組成模型和程式語言的。只有透過Web Service，客戶端和伺服器才能夠自由的用HTTP進行通信，不論兩個程式的平台和程式語言是什麼。
二、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協定也必須與平台和程式語言無關。
三、WebService平台技術
XML+XSD,SOAP和WSDL就是構成WebService平台的三大技術。
3.1、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.2、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.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.直接告訴給客戶端呼叫者。
四、WebService開發
WebService開發可以分為伺服器端開發和客戶端開發兩個面向
4.1、服務端開發
把公司內部系統的業務方法發布成WebService，供遠端合作單位和個人化單位調用。 (借助一些WebService框架可以很輕鬆地把自己的業務對象發布成WebService服務，Java方面的典型WebService框架包括：axis，xfire，cxf 等，java ee伺服器通常也支援發布WebService服務，例如JBoss。)
4.2.客戶開發
呼叫別人發布的WebService服務，大多數人從事的開發都屬於這個方面，例如，呼叫天氣預報WebService服務。 （使用廠商的WSDL2Java之類的工具產生靜態呼叫的代理程式碼；使用廠商提供的客戶端程式設計API類別；使用SUN公司早期標準的jax-rpc開發包；使用SUN公司最新標準的jax-ws開發包。類，我呼叫這些代理，就可以存取到webservice服務。代理類別把客戶端的方法呼叫變成soap格式的請求資料再透過HTTP協定發出去，並且把接收到的soap 資料變成回傳值回傳。對服務端而言，各類WebService框架的本質就是一個大大的Servlet，當遠端呼叫客戶端給它透過http協定發送過來soap格式的請求資料時，它會分析這個數據，就知道要呼叫哪個java類別的哪個方法，於是去尋找或建立這個對象，並呼叫其方法，再把方法返回的結果包裝成soap格式的數據，透過http回應訊息回給客戶端。
五、適用場合
1、跨防火牆通訊
如果應用程式有成千上萬的用戶，而且分佈在世界各地，那麼客戶端和伺服器之間的通訊將是一個棘手的問題。因為客戶端和伺服器之間通常會有防火牆或代理服 務器。在這種情況下，使用DCOM就不是那麼簡單，通常也不便於把客戶端程式發佈到數量如此龐大的每一個用戶手中。傳統的做法是，選擇用瀏覽器作為客戶 端，寫下一大堆ASP頁面，把應用程式的中間層暴露給最終用戶。這樣做的結果是開發難度高，程式很難維護。如果中間層元件換成WebService的話， 就可以從使用者介面直接呼叫中間層元件。從大多數人的經驗來看，在一個使用者介面和中間層有較多互動的應用程式中，使用WebService這種結構，可以節 省花在使用者介面編程上20%的開發時間。
2、應用程式整合
企業級的應用程式開發者都知道，企業裡經常都要把用不同語言寫成的、在不同平台上運行的各種程式整合起來，而這種整合將花費很大的開發力量。應用程式經常 需要從執行在IBM主機上的程式取得資料；或將資料傳送到主機或UNIX應用程式中去。即使在同一個平台上，不同軟體廠商生產的各種軟體也常常需要集 成起來。透過WebService，可以輕鬆的整合不同結構的應用程式。
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非常適合在這種情況下工作，因為它既小又快。運行在同一台伺服器上的伺服器軟體也是這樣。最好直接用COM或其它本地的API來 進行應用程式間的呼叫。當然WebService也能用在這些場合，但那樣不僅消耗太大，而且不會帶來任何好處。
2、區域網路的同構應用程式
在許多應用中，所有的程式都是以VB或VC開發的，且在Windows平台下使用COM，都運作在同一個區域網路上。例如，有兩個伺服器應用程式需要相互通 信，或有一個Win32或WinForm的客戶程式要連接區域網路上另一個伺服器的程式。在這些程式裡，使用DCOM會比SOAP/HTTP有效許多。與 此相類似，如果一個.NET程式要連接到區域網路上的另一個.NET程序，則應該使用.NETremoting。有趣的是，在.NETremoting 中，也可以指定使用SOAP/HTTP來進行WebService呼叫。不過最好還是直接透過TCP進行RPC調用，那樣會有效得多。
更多WebService的相關概念相關文章請關注PHP中文網！
