WebService

一、序言

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

   基于浏覽器的瘦用戶端應用程式并不是因為瘦客戶能夠提供更好的使用者界面，而是因為它能夠避免花在桌面應用程式釋出上的高成本。釋出桌面應用程式成本很高，一半是因為應用程式安裝和配置的問題，另一半是因為客戶和伺服器之間通信的問題。傳統的windows富客戶應用程式使用dcom來與伺服器進行通信和調用遠端對象。配置好dcom使其在一個大型的網絡中正常工作将是一個極富挑戰性的工作，同時也是許多it工程師的噩夢。事實上，許多it工程師甯願忍受浏覽器所帶來的功能限制，也不願在區域網路上去運作一個dcom。關于用戶端與伺服器的通信問題，一個完美的解決方法是使用http協定來通信。這是因為任何運作web浏覽器的機器都在使用http協定。同時，目前許多防火牆也配置為隻允許http連接配接。許多商用程式還面臨另一個問題，那就是與其他程式的互操作性。如果所有的應用程式都是使用com或.net語言寫的，并且都運作在windows平台上，那就天下太平了。然而，事實上大多數商業資料仍然在大型主機上以非關系檔案(vsam)的形式存放，并由cobol語言編寫的大型機程式通路。而且，目前還有很多商用程式繼續在使用c++、​​​​

​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平台的三大技術。

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也一樣，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開發可以分為伺服器端開發和用戶端開發兩個方面：

   服務端開發：把公司内部系統的業務方法釋出成webservice服務，供遠端合作機關和個人調用。(借助一些webservice框   架可以很輕松地把自己的業務對象釋出成webservice服務，java方面的典型webservice架構包括：axis，xfire，cxf等，java ee伺服器通常也支援釋出webservice服務，例如jboss。)

   用戶端開發：調用别人釋出的webservice服務，大多數人從事的開發都屬于這個方面，例如，調用天氣預報webservice服務。（使用廠商的wsdl2java之類的工具生成靜态調用的代理類代碼；使用廠商提供的用戶端程式設計api類；使用sun公司早期标準的jax-rpc開發包；使用sun公司最新标準的jax-ws開發包。當然sun已被oracle收購)

   webservice的工作調用原理：對用戶端而言，我們給這各類webservice用戶端api傳遞wsdl檔案的url位址，這些api就會建立出底層的代理類，我調用這些代理，就可以通路到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調用，那樣會有效得多。