Web Service

Web Service

Web service是一個平臺獨立的，低耦合的，自包含的、基於可編程的web的應用程序，可以使用開放的XML（標準通用標記語言下的一個子集）標準來描述、發佈、發現、協調和配置這些應用程序，用於開發分佈式的互操做的應用程序。 ^[1]  

Web Service技術， 能使得運行在不一樣機器上的不一樣應用無須藉助附加的、專門的第三方軟件或硬件， 就可相互交換數據或集成。依據Web Service規範實施的應用之間， 不管它們所使用的語言、 平臺或內部協議是什麼， 均可以相互交換數據。Web Service是自描述、 自包含的可用網絡模塊， 能夠執行具體的業務功能。Web Service也很容易部署， 由於它們基於一些常規的產業標準以及已有的一些技術，諸如標準通用標記語言下的子集XML、HTTP。Web Service減小了應用接口的花費。Web Service爲整個企業甚至多個組織之間的業務流程的集成提供了一個通用機制。

 

歷史

web普遍用到的技術：

1. TCP/IP：通用網絡協議，被各類設備使用
2. HTML（標準通用標記語言下的一個應用）：通用用戶界面，可使用HTML標籤顯示數據
3. .NET: 不一樣應用程序間共享數據與數據交換
4. Java：寫一次能夠在任何系統運行的通用編程語言，由於java具備跨平臺特性
5. XML（標準通用標記語言下的一個子集）：通用數據表達語言，在web上傳送結構化數據的容易方法

他們的特色是其開放性，跨平臺性，開放性正是Web services的基礎。

近幾年來，Internet的迅猛發展使其成爲全球信息傳遞與共享的巨大 的資源庫。愈來愈多的網絡環境下的Web應用系統被創建起來，利用HTML、CGI等Web技術能夠輕鬆地在Internet環境下實現電子商務、電子政 務等多種應用。然而這些應用可能分佈在不一樣的地理位置，使用不一樣的數據組織形式和操做系統平臺，加上應用不一樣所形成的數據不一致性，使得如何將這些高度分 布的數據集中起來並得以充分利用成爲急需解決的問題。

隨着網絡技術、網絡運行理念的發展，人們提出一種新的利用網絡進行應用集 成的解決方案——Web Service。Web Service是一種新的Web應用程序分支，其能夠執行從簡單的請求到複雜商務處理的任何功能。一旦部署之後，其餘Web Service應用程序能夠發現並調用它部署的服務。所以，Web Service是構造分佈式、模塊化應用程序和麪向服務應用集成的最新技術和發展趨勢。

趨勢

內容更動態化

1. 帶寬Bandwidth更便宜，易於得到
2. 存儲器Storage更便宜，更易得到
3. 廣泛式計算變得更加劇要：大量的設備，例如移動電話，頁面，電腦，pc，已經在Internet上變得廣泛，平臺變得更多元化，像XML（標準通用標記語言下的一個子集）這樣的跨平臺技術變得更重要

趨勢

上述的這些趨勢意味着，更加智能的處理，操做和彙總內容變得十分重要。讓咱們看看按照Web services角度所預示的四個趨勢：

1. 內容更加動態：一個web service必須能合併從多個不一樣來源的內容，能夠包括股票，天氣，新聞等，在傳統環境中的內容，如存貨水平，購物訂單或者目錄信息等，都從後端系統而來；
2. 帶寬更加便宜：web services能夠分發各類類型的內容（音頻，視頻流等）；
3. 存儲更便宜:：web services必須能聰明地處理大量數據，意味着要使用數據庫，LDAP目錄，緩衝，和負載平衡軟件等技術保持可擴展能力；
4. 廣泛式計算更重要：web services不能要求客戶使用某一版本的windows的傳統瀏覽器，必須支持各類設備，平臺，瀏覽器類型，各類內容類型；

兩種重要技術

要達到這樣的目標，Web services要使用兩種技術：

1. XML（標 準通用標記語言下的一個子集）：XML是在web上傳送結構化數據的偉大方式，Web services要以一種可靠的自動的方式操做數據，HTML（標準通用標記語言下的一個應用）不會知足要求，而XML可使web services十分方便的處理數據，它的內容與表示的分離十分理想；
2. SOAP：SOAP使用XML消息調用遠程方法，這樣web services能夠經過HTTP協議的post和get方法與遠程機器交互，並且，SOAP更加健壯和靈活易用；

其餘像UDDI和WSDL技術與XML和SOAP技術緊密結合用於服務發現。

支持

技術支持

Web Service平臺須要一套協議來實現分佈式應用程序的建立。任何平臺都有它的數據表示方法和類型系統。要實現互操做性，Web Service平臺必須提供一套標準的類型系統，用於溝通不一樣平臺、編程語言和組件模型中的不一樣類型系統。這些協議有：

XML和XSD

可擴展的標記語言（標準通用標記語言下的一個子集）是Web Service平臺中表示數據的基本格式。除了易於創建和易於分析外，XML主要的優勢在於它既與平臺無關，又與廠商無關。XML是由萬維網協會 (W3C)建立，W3C制定的XML SchemaXSD　定義了一套標準的數據類型，並給出了一種語言來擴展這套數據類型。

Web Service平臺是用XSD來做爲數據類型系統的。當你用某種語言如VB. NET或C#　來構造一個Web Service時，爲了符合Web Service標準，全部你使用的數據類型都必須被轉換爲XSD類型。如想讓它使用在不一樣平臺和不一樣軟件的不一樣組織間傳遞，還須要用某種東西將它包裝起 來。這種東西就是一種協議，如 SOAP。

xml web service

SOAP

SOAP即簡單對象訪問協議(Simple Object Access Protocol)，它是用於交換XML（標準通用標記語言下的一個子集）編碼信息的輕量級協議。它有三個主要方面：XML-envelope爲描述信息 內容和如何處理內容定義了框架，將程序對象編碼成爲XML對象的規則，執行遠程過程調用(RPC)的約定。SOAP能夠運行在任何其餘傳輸協議上。例如， 你可使用 SMTP，即因特網電子郵件協議來傳遞SOAP消息，這但是頗有誘惑力的。在傳輸層之間的頭是不一樣的，但XML有效負載保持相同。

Web Service 但願實現不一樣的系統之間可以用「軟件-軟件對話」的方式相互調用，打破了軟件應用、網站和各類設備之間的格格不入的狀態，實現「基於Web無縫集成」的目標。

WSDL

Web Service描述語言WSDL　就是用機器能閱讀的方式提供的一個正式描述文檔而基於XML（標準通用標記語言下的一個子集）的語言，用於描述Web Service及其函數、參數和返回值。由於是基於XML的，因此WSDL既是機器可閱讀的，又是人可閱讀的。

UDDI

UDDI 的目的是爲電子商務創建標準；UDDI是一套基於Web的、分佈式的、爲Web Service提供的、信息註冊中心的實現標準規範，同時也包含一組使企業能將自身提供的Web Service註冊，以使別的企業可以發現的訪問協議的實現標準。

調用RPC與消息傳遞

Web Service自己實際上是在實現應用程序間的通訊。咱們有兩種應用程序通訊的方法：RPC遠程過程調用　和消息傳遞。使用RPC的時候，客戶端的概念是調 用服務器上的遠程過程，一般方式爲實例化一個遠程對象並調用其方法和屬性。RPC系統試圖達到一種位置上的透明性：服務器暴露出遠程對象的接口，而客戶端 就好像在本地使用的這些對象的接口同樣，這樣就隱藏了底層的信息，客戶端也就根本不須要知道對象是在哪臺機器上。

軟件支持

操做系統離不開豐富的應用軟件的支持。一樣，Web Service這項技術只有經過日益普遍的應用才能體現出其價值，比較流行的實現方法是使用.NET 和 Java兩種技術，而且兩種實現方法能夠互相操做；現在咱們已經能夠看到使用微軟、Oracle、SUN、Borland等不一樣廠商的Web Service構建工具創建的Web Service應用。

微軟.NET

微軟的.NET技術應該算是時下最爲流行的Web Service 開發技術。首先由於其公司在之前相應的產品就佔有至關大的市場份額，以致使新推出的.NET得以有比較穩定的用戶羣；其次也是更重要的是 .NET平臺不只延續了微軟一向的編程風格，並且還增長了許多支持Web 服務的關鍵性技術，使得.NET在操做的簡單性和執行的穩定性，高效性上達到了一個很是好的結合。

微軟的Visual Studio. NET即是一個便於 Web 服務的開發工具。微軟的目標是，將其新編程語言——C#做爲Web Service的首選語言。雖然C#看起來與Java相似，可是還有一些Java中沒有的獨特的功能。.NET技術中用於Web Service 開發的主要工具是ASP. NET。從技術上說，ASP. net　 提供了一些超出ASP之前版本的優勢(例如：代碼和HTML（標準通用標記語言下的一個應用）的分離，與腳本語言相比較，對「真正」的編程語言如 C# 的支持)。

IBM的WebSphere

IBM公司是業界第一家可以提供全面支持Web服務的電子商務基礎設施中 間件的公司。經過多年來與W3C(The World Wide Web Consortium)的共同努力，包括DB二、Lotus、Tivoli 和WebSphere在內的全部IBM軟件都實現了對SOAP、WSDL、UDDI、Linux、XML（標準通用標記語言下的一個子集）、J2EE等開 放技術和標準的全面支持。

IBM公司的WebSphere也是比較好的基礎架構軟件開發平臺。 WebSphere軟件平臺及開發工具包括WebSphere Studio Application DeveloperWSAD　 基於J2EE、XML 和Web服務等開放標準，並具有 IBM 在可靠性、擴展性和安全性上的主要優點。WebSphere 是 IBM 在 Web Services策略中的核心平臺，它支持全部開發、發佈、部署 Web Services應用所必需的開放標準和技術，包括 UDDI，SOAP，J2EE，WSDL，和對 XML 技術集成的加強，這使得它在全球有不少用戶。

Borland的JBuilder

Borland公司在 JBuilder7中，用戶能夠用其Borland Web Services Kit for Java和Borland JBuilder MobileSet 3進行更快捷地開發Web Service和無線應用。這樣將使開發者可以在同一個開發環境中輕鬆地建立和集成Web Service。新推出的JBuidler8更是針對Web Service開發更提供了方便和高效的方法。

總之，在Web Service開發上，.NET 和Java都是很好的選擇，儘管二者都有一些須要完善的地方，可是它們仍是最好的開發手段和技術。具體選擇哪一種開發工具，也是仁者見仁，智者見智的問題。 從根本上說，這兩種方法沒有孰優孰劣的問題，只是根據使用者對這兩種方法的掌握程度和對具體語言的偏心程度來決定。

應用

Web service究竟是什麼；在什麼狀況下你應該使用Web service。

研究一下當前的應用程序開發，你會發現一個絕對的傾向：人們開始偏心基於 瀏覽器的客戶端應用程序。這固然不是由於客戶端可以提供更好的用戶界面，而是由於它可以避免花在桌面應用程序發佈上的高成本。發佈桌面應用程序成本很高， 一半是由於應用程序安裝和配置的問題，另外一半是由於客戶端和服務器之間通訊的問題。

傳統的Windows客戶應用程序使用DCOM來與服務器進行通訊和調用 遠程對象。配置好DCOM使其在一個大型的網絡中正常工做將是一個極富挑戰性的工做，同時也是許多IT工程師的噩夢。事實上，許多IT工程師寧願忍受瀏覽 器所帶來的功能限制，也不肯在局域網上去運行一個DCOM。在我看來，結果就是一個發佈容易，但開發難度大並且用戶界面極其受限的應用程序。極端的說，就 是你花了更多的資金和時間，卻開發出從用戶看來功能更弱的應用程序。不信？問問你的會計師對新的基於瀏覽器的會計軟件有什麼想法：絕大多數商用程序用戶希 望使用更加友好的Windows用戶界面。

關於客戶端與服務器的通訊問題，一個完美的解決方法是使用HTTP協議來通訊。這是由於任何運行Web瀏覽器的機器都在使用HTTP協議。同時，當前許多防火牆也配置爲只容許HTTP鏈接。

許多商用程序還面臨另外一個問題，那就是與其餘程序的互操做性。若是全部的 應用程序都是使用COM或.NET語言寫的，而且都運行在Windows平臺上，那就天下太平了。然而，事實上大多數商業數據仍然在大型主機上以非關係文 件(VSAM)的形式存放，並由COBOL語言編寫的大型機程序訪問。並且，還有不少商用程序繼續在使用C++、Java、Visual Basic和其餘各類各樣的語言編寫。除了最簡單的程序以外，全部的應用程序都須要與運行在其餘異構平臺上的應用程序集成並進行數據交換。這樣的任務一般 都是由特殊的方法，如文件傳輸和分析，消息隊列，還有僅適用於某些狀況的的API，如IBM的"高級程序到程序交流(APPC)"等來完成的。在之前，沒 有一個應用程序通訊標準，是獨立於平臺、組建模型和編程語言的。只有經過Web Service，客戶端和服務器纔可以自由的用HTTP進行通訊，不論兩個程序的平臺和編程語言是什麼。

什麼是Web Service

對這個問題，咱們至少有兩種答案。從表面上看，Web service 就是一個應用程序，它向外界暴露出一個可以經過Web進行調用的API。這就是說，你可以用編程的方法經過Web來調用這個應用程序。咱們把調用這個 Web service 的應用程序叫作客戶。例如，你想建立一個Web service ，它的做用是返回當前的天氣狀況。那麼你能夠創建一個ASP頁面，它接受郵政編碼做爲查詢字符串，而後返回一個由逗號隔開的字符串，包含了當前的氣溫和天 氣。要調用這個ASP頁面，客戶端須要發送下面的這個HTTP GET

返回的數據就應該是這樣：

這個ASP頁面就應該能夠算做是Web service 了。由於它基於HTTP GET請求，暴露出了一個能夠經過Web調用的API。固然，Web service 還有更多的東西。

下面是對Web service 更精確的解釋： Web services是創建可互操做的分佈式應用程序的新平臺。做爲一個Windows程序員，你可能已經用COM或DCOM創建過基於組件的分佈式應用程 序。COM是一個很是好的組件技術，可是咱們也很容易舉出COM並不能知足要求的狀況。

Web service平臺是一套標準，它定義了應用程序如何在Web上實現互操做性。你能夠用任何你喜歡的語言，在任何你喜歡的平臺上寫Web service ，只要咱們能夠經過Web service標準對這些服務進行查詢和訪問。

新平臺

Web service平臺須要一套協議來實現分佈式應用程序的建立。Web service平臺必須提供一套標準的類型系統，用於溝通不一樣平臺、編程語言和組件模型中的不一樣類型系統。在傳統的分佈式系統中，基於界面 (interface)的平臺提供了一些方法來描述界面、方法和參數（譯註：如COM和COBAR中的IDL語言）。一樣的，Web service平臺也必須提供一種標準來描述Web service，讓客戶能夠獲得足夠的信息來調用這個Web service。最後，咱們還必須有一種方法來對這個Web service進行遠程調用。這種方法實際是一種遠程過程調用協議(RPC)。爲了達到互操做性，這種RPC協議還必須與平臺和編程語言無關。下面幾個小 節就簡要介紹了組成Web service平臺的這三個技術。

XML和XSD

可擴展的標記語言（標準通用標記語言下的一個子集）是Web service平臺中表示數據的基本格式。除了易於創建和易於分析外，XML主要的優勢在於它既是平臺無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。

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

SOAP

Web service建好之後，你或者其餘人就會去調用它。簡單對象訪問協議(SOAP)提供了標準的RPC方法來調用Web service。實際上，SOAP在這裏有點用詞不當：它意味着下面的Web service是以對象的方式表示的，但事實並不必定如此：你徹底能夠把你的Web service寫成一系列的C函數，並仍然使用SOAP進行調用。SOAP規範定義了SOAP消息的格式，以及怎樣經過HTTP協議來使用SOAP。 SOAP也是基於XML（標準通用標記語言下的一個子集）和XSD的，XML是SOAP的數據編碼方式。

WSDL

你會怎樣向別人介紹你的Web service有什麼功能，以及每一個函數調用時的參數呢？你可能會本身寫一套文檔，你甚至可能會口頭上告訴須要使用你的Web service的人。這些非正式的方法至少都有一個嚴重的問題：當程序員坐到電腦前，想要使用你的Web service的時候，他們的工具(如Visual Studio)沒法給他們提供任何幫助，由於這些工具根本就不瞭解你的Web service。

解決方法是：用機器能閱讀的方式提供一個正式的描述文檔。Web service描述語言(WSDL)就是這樣一個基於XML（標準通用標記語言下的一個子集）的語言，用於描述Web service及其函數、參數和返回值。WSDL既是機器可閱讀的，又是人可閱讀的，這將是一個很大的好處。一些最新的開發工具既能根據你的Web service生成WSDL文檔，又能導入WSDL文檔，生成調用相應Web service的代碼。

UDDI

Universal Description, Discovery and Integration

爲加速Web Service的推廣、增強Web Service的互操做能力而推出的一個計劃,基於標準的服務描述和發現的規範(specification)。

以資源共享的方式由多個運做者一塊兒以Web Service的形式運做UDDI商業註冊中心。

UDDI計劃的核心組件是UDDI商業註冊，它使用XML文檔來描述企業及其提供的Web Service。

UDDI商業註冊提供三種信息：

White Page包含地址、聯繫方法、已知的企業標識。

Yellow Page包含基於標準分類法的行業類別。

Green Page包含關於該企業所提供的Web Service的技術信息，其形式多是指向文件或URL的指針，而這些文件或URL是爲服務發現機制服務的。

Web Service開發實例

1. 利用WebService實現數據添加
2. 利用WebService實現數據刪除
3. 利用WebService給手機發短信 ^[3]  

適合使用Web Service的狀況

1. 跨越防火牆；
2. 應用程序集成；
3. B2B集成；
4. 軟件重用

不適合使用Web服務的狀況

1. 單機應用程序；
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平臺的三大技術。

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.直接告訴給客戶端調用者。

 

4、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響應消息回給客戶端。

 

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調用，那樣會有效得多。

 

Web Service 的工做原理

Web Service基本概念

Web Service也叫XML Web Service WebService是一種能夠接收從Internet或者Intranet上的其它系統中傳遞過來的請求，輕量級的獨立的通信技術。是:經過SOAP在 Web上提供的軟件服務，使用WSDL文件進行說明，並經過UDDI進行註冊。

XML：(Extensible Markup Language)擴展型可標記語言。面向短時間的臨時數據處理、面向萬維網絡，是Soap的基礎。

Soap：(Simple Object Access Protocol)簡單對象存取協議。是XML Web Service 的通訊協議。當用戶經過UDDI找到你的WSDL描述文檔後，他經過能夠SOAP調用你創建的Web服務中的一個或多個操做。SOAP是XML文檔形式的 調用方法的規範，它能夠支持不一樣的底層接口，像HTTP(S)或者SMTP。

WSDL：(Web Services Description Language) WSDL 文件是一個 XML 文檔，用於說明一組 SOAP 消息以及如何交換這些消息。大多數狀況下由軟件自動生成和使用。

UDDI (Universal Description, Discovery, and Integration) 是一個主要針對Web服務供應商和使用者的新項目。在用戶可以調用Web服務以前，必須肯定這個服務內包含哪些商務方法，找到被調用的接口定義，還要在服 務端來編制軟件，UDDI是一種根據描述文檔來引導系統查找相應服務的機制。UDDI利用SOAP消息機制（標準的XML/HTTP）來發布，編輯，瀏覽 以及查找註冊信息。它採用XML格式來封裝各類不一樣類型的數據，而且發送到註冊中心或者由註冊中心來返回須要的數據。

 

調用原理：

Web服務有兩層含義：一、是指封裝成單個實體併發布到網絡上的功能集合體；二、是指功能集合體被調用後所提供的服務。簡單地講，Web服務是一個URL資源，客戶端能夠經過編程方式請求獲得它的服務，而不須要知道所請求的服務是怎樣實現的，這一點與傳統的分佈式組件對象模型不一樣。

Web服務的體系結構是基於Web服務提供者、Web服務請求者、Web服務中介者三個角色和發佈、發現、綁定三個動做構建的。簡單地說，Web服務提供者就是Web服務的擁有者，它耐心等待爲其餘服務和用戶提供本身已有的功能；Web服務請求者就是Web服務功能的使用者，它利用SOAP消息向Web服務提供者發送請求以得到服務;Web服務中介者的做用是把一個Web服務請求者與合適的Web服務提供者聯繫在一塊兒，它充當管理者的角色，通常是UDDI。這三個角色是根據邏輯關係劃分的，在實際應用中，角色之間極可能有交叉：一個Web服務既能夠是Web服務提供者，也能夠是Web服務請求者，或者兩者兼而有之。顯示了Web服務角色之間的關係:其中，「發佈」是爲了讓用戶或其餘服務知道某個Web服務的存在和相關信息;「查找（發現）」是爲了找到合適的Web服務;「綁定」則是在提供者與請求者之間創建某種聯繫。

 

圖2-1 Web service的體系結構

實現一個完整的Web服務包括如下步驟：

◆ Web服務提供者設計實現Web服務，並將調試正確後的Web服務經過Web服務中介者發佈，並在UDDI註冊中心註冊； （發佈）

◆ Web服務請求者向Web服務中介者請求特定的服務，中介者根據請求查詢UDDI註冊中心，爲請求者尋找知足請求的服務； （發現）

◆ Web服務中介者向Web服務請求者返回知足條件的Web服務描述信息，該描述信息用WSDL寫成，各類支持Web服務的機器都能閱讀；（發現）

◆ 利用從Web服務中介者返回的描述信息生成相應的SOAP消息，發送給Web服務提供者，以實現Web服務的調用；（綁定）

◆ Web服務提供者按SOAP消息執行相應的Web服務，並將服務結果返回給Web服務請求者。（綁定）

調用方式：

1. Net下采用GET/POST/SOAP方式動態調用WebService的簡易靈活方法(C#)

webservice 的調用有3種方式

1). httpget 
2). httppost
3). httpsoap

soap 的優勢是 能夠傳遞結構化的 數據，而前兩種不行。
btw, soap 最終也是使用 HTTP 傳送 XM

安全：

Webservice爲做爲方便的服務被用廣大領域使用的同時，也成爲了黑客們的美食。在這裏，本文將就目前對Webservice安全所能作的改進作簡單介紹。

在Webservice中的安全主要分爲如下三個方面。

傳輸      SSL/HTTPS 對鏈接加密，而不是傳輸數據

消息      數據加密(XML Encryption)   數字簽名(XML-DSIG)

底層架構  利用應用服務安全機制
 
傳輸時的安全是最容易被加入到你的Webservice應用中的，利用現有的SSL 和HTTPS協議，就能夠很容易的得到鏈接過程當中的安全。
 
然 而這種安全實現方法有兩個弱點。一是它只能保證數據傳輸的安全，而不是數據自己的安全，數據一旦到達某地，那麼就能夠被任何人所查看。而在 Webservice中，一份數據可能到達多個地方，而這份數據卻不應被全部的接受者所查看。二是它提供的是要麼全有要麼全無的保護，你不能選擇哪部分數 據要被保護，而這種可選擇性也是在Webservice中所常要用到的。
 
第二層的保護是對於消息自己的保護。你可使用已有的XML安 全擴展標準，實現數字簽名的功能，從而保證你的消息是來自特定方並無被修改過。XML文件的加密技術從更大程度上增強了Webservice的安全，它 可以定製數據傳輸到後，可否被接受者所查看，進一步完善了傳輸後的安全，業界也在不斷的制定Webservice的安全標準，好比SAML 和 WS-Security。
 
最後一層保護就是依靠底層架構的安全，這更多的來自於操做系統和某些中間件的保護。好比在J2EE中，主持 Webservice的應用服務器。目前不少的J2EE應用服務器都支持Java Authentication and Authorization Service (JAAS)，這是最近被加入到J2SE 1.4當中的。利用主持Webservice的服務器，實現一些安全機制這是很天然的作法。另外一種利用底層架構的安全方法就是，作一個獨立的負責安全的服 務器，Webservice的使用者和建立者都須要與之取得安全信任。

 

特色：

Web Service的主要目標是跨平臺的可互操做性。爲了實現這一目標，Web Service 徹底基於XML（可擴展標記語言）、XSD（XML Schema）等獨立於平臺、獨立於軟件供應商的標準，是建立可互操做的、分佈式應用程序的新平臺。所以使用Web Service有許多優勢:

 一、跨防火牆的通訊

若是應用程序有成千上萬的用戶，並且分佈在世界各地，那麼客戶端和服務器之間的通訊將是一個棘手的問題。由於客戶端和服務器之間一般會有防火牆或者 代理服務器。傳統的作法是，選擇用瀏覽器做爲客戶端，寫下一大堆ASP頁面，把應用程序的中間層暴露給最終用戶。這樣作的結果是開發難度大，程序很難維 護。 要是客戶端代碼再也不如此依賴於HTML表單，客戶端的編程就簡單多了。若是中間層組件換成Web Service的話，就能夠從用戶界面直接調用中間層組件，從而省掉創建ASP頁面的那一步。要調用Web Service，能夠直接使用Microsoft SOAP Toolkit或.net這樣的SOAP客戶端，也可使用本身開發的SOAP客戶端，而後把它和應用程序鏈接起來。不只縮短了開發週期，還減小了代碼復 雜度，並可以加強應用程序的可維護性。同時，應用程序也再也不須要在每次調用中間層組件時，都跳轉到相應的"結果頁"。

 二、應用程序集成

企業級的應用程序開發者都知道，企業裏常常都要把用不一樣語言寫成的、在不一樣平臺上運行的各類程序集成起來，而這種集成將花費很大的開發力量。應用程 序常常須要從運行的一臺主機上的程序中獲取數據；或者把數據發送到主機或其它平臺應用程序中去。即便在同一個平臺上，不一樣軟件廠商生產的各類軟件也經常需 要集成起來。經過Web Service，應用程序能夠用標準的方法把功能和數據"暴露"出來，供其它應用程序使用。

XML Web services 提供了在鬆耦合環境中使用標準協議（HTTP、XML、SOAP 和 WSDL）交換消息的能力。消息能夠是結構化的、帶類型的，也能夠是鬆散定義的。

 三、B2B的集成

B2B 指的是Business to Business，as in businesses doing business with other businesses,商家(泛指企業)對商家的電子商務，即企業與企業之間經過互聯網進行產品、服務及信息的交換。通俗的說法是指進行電子商務交易的供 需雙方都是商家(或企業、公司)，她們使用了Internet的技術或各類商務網絡平臺，完成商務交易的過程。

Web Service是B2B集成成功的關鍵。經過Web Service，公司能夠只需把關鍵的商務應用"暴露"給指定的供應商和客戶，就能夠了，Web Service運行在Internet上，在世界任何地方均可輕易實現，其運行成本就相對較低。Web Service只是B2B集成的一個關鍵部分，還須要許多其它的部分才能實現集成。 用Web Service來實現B2B集成的最大好處在於能夠輕易實現互操做性。只要把商務邏輯"暴露"出來，成爲Web Service，就可讓任何指定的合做夥伴調用這些商務邏輯，而無論他們的系統在什麼平臺上運行，使用什麼開發語言。這樣就大大減小了花在B2B集成上 的時間和成本。

 四、軟件和數據重用

Web Service在容許重用代碼的同時，能夠重用代碼背後的數據。使用Web Service，不再必像之前那樣，要先從第三方購買、安裝軟件組件，再從應用程序中調用這些組件；只須要直接調用遠端的Web Service就能夠了。另外一種軟件重用的狀況是，把好幾個應用程序的功能集成起來，經過Web Service "暴露"出來，就能夠很是容易地把全部這些功能都集成到你的門戶站點中，爲用戶提供一個統一的、友好的界面。 能夠在應用程序中使用第三方的Web Service 提供的功能，也能夠把本身的應用程序功能經過Web Service 提供給別人。兩種狀況下，均可以重用代碼和代碼背後的數據。

從以上論述能夠看出，Web Service 在經過Web進行互操做或遠程調用的時候是最有用的。不過，也有一些狀況，Web Service根本不能帶來任何好處，Web Service有一下缺點：

一、 單機應用程序

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

二、 局域網的一些應用程序

在許多應用中，全部的程序都是在Windows平臺下使用COM，都運行在同一個局域網上。在這些程序裏，使用DCOM會比SOAP/HTTP有效 得多。與此相相似，若是一個.net程序要鏈接到局域網上的另外一個.net程序，應該使用.net Remoting。其實在.net Remoting中，也能夠指定使用SOAP/HTTP來進行Web Service 調用。不過最好仍是直接經過TCP進行RPC調用，那樣會有效得多。

1.三、XML Web Service的應用

1.最初的 XML Web Service 一般是能夠方便地併入應用程序的信息來源，如股票價格、天氣預報、體育成績等等。

2.以 XML Web Service 方式提供現有應用程序，能夠構建新的、更強大的應用程序，並利用 XML Web Service 做爲構造塊。

例如，用戶能夠開發一個採購應用程序，以自動獲取來自不一樣供應商的價格信息，從而使用戶能夠選擇供應商，提交訂單，而後跟蹤貨物的運輸，直至收到貨 物。而供應商的應用程序除了在Web上提供服務外，還可使用XML Web Service檢查客戶的信用、收取貨款，並與貨運公司辦理貨運手續。

 

SOAP消息格式：

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

<?xml version= "1.0" ?> <soap:Envelope xmlns:soap= "http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle= "http://www.w3.org/2001/12/soap-encoding" >   <soap:Header>    <m:Trans xmlns:m= "http://www.w3schools.com/transaction/"    soap:mustUnderstand= "1" >234    </m:Trans> </soap:Header>     <soap:Body>    <m:GetPrice xmlns:m= "http://www.w3schools.com/prices" >      <m:Item>Apples</m:Item>    </m:GetPrice> </soap:Body> </soap:Envelope>