webService基本概念、元素及簡單編碼實現

webService

"網絡服務"（Web Service）的本質，就是經過網絡調用其餘網站的資源。網絡服務是相對於本地服務來講的，本機完成本機須要完成的任務，叫「本地服務」，而「網絡服務」則是經過網絡來調用其餘服務器提供的服務。html

webService和中間件的關係：webService是一種技術手段，是一種網絡中系統之間進行交互的方式。而中間件則是實現這種交互的一種手段（一種軟件、服務）。java

定義：WebService是一種跨編程語言和跨操做系統平臺的遠程調用技術（rpc）。實現平臺無關性和語言無關性的關鍵是用一種標準來統必定義相互通訊的接口，而WebService平臺技術就是旨在解決統一標準的問題。引用：Web service是什麼？web

WebService平臺技術 XML+XSD,SOAP和WSDL就是構成WebService平臺的三大技術。 SOAP和WSDL的詳細格式和解析可見：SOAP和WSDL的一些必要知識 or 備用地址apache

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類型。你用的工具可能已經自動幫你完成了這個轉換，但你極可能會根據你的須要修改一下轉換過程。編程

xsd就是基於xml，本身定義了一套標籤，用來對webService中的數據表示格式進一步規範。api

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就是普通公路通過加隔離帶和防禦欄改造過的高速公路。服務器

soap基於xml和http，在http的請求頭中加入屬性用以標記請求內容格式是soap類型的，而且用soap也是和xsd同樣，基於xml的基礎上本身定義一套標籤，來規範webService請求的一系列參數。網絡

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

WSDL也是在xml的基礎上進行擴展，它是用來描述webservice的，描述了WebService有哪些方法、參數類型、訪問路徑等等。框架

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

Web Service調用方式

網絡上隨處可見的「四種調用webService的方式」都是經過jdk1.6以後集成的組件api進行調用。隨處找來的：WebService的四種客戶端調用方式（基本）還有其餘的開源框架實現了Web Service，好比axis和cxf。

在SOA領域，咱們認爲Web Service是SOA體系的構建單元（building block）。對於服務開發人員來講，AXIS和CXF必定都不會陌生。這兩個產品都是Apache孵化器下面的Web Service開源開發工具。 Axis2的最新版本是1.3.CXF如今已經到了2.0版本。

這兩個框架都是從已有的開源項目發展起來的。Axis2是從Axis1.x系列發展而來。CXF則是XFire和Celtix項目的結合產品。Axis2是從底層所有從新實現，使用了新的擴展性更好模塊架構。 CXF也從新的深化了XFire和Celtix這兩個開發工具。

新產品的退出致使了幾個問題。是否是現有的使用Axis 1.x，XFire和Celix的應用須要遷移的新的版本上。若是一個開發人員肯定要遷移它的應用到新的框架上，那麼他應該選擇哪個呢？相反的，若是一個開發者決定從頭開發一個新的Web Service，他應該使用哪一個呢？這兩個框架哪個更好一些呢？

對於系統遷移來講，也許遷移到新的框架並不難。Axis和CXF都提供了遷移的指導。可以給開發者一些遷移的技巧和經驗。可是對於這樣遷移，這兩個開源項目都沒有提供遷移的工具。對於這樣的遷移工做，儘管很值得去尋找全部的可行方案。Axis2和CXF都有各自不一樣的WebService開發方法，每一個方法都有至關數量擁護者。

經過一個比較矩陣來比較Axis2和CXF變得有現實的意義。這兩個項目都開發不夠成熟，可是最主要的區別在如下幾個方面：

1.CXF支持 WS-Addressing，WS-Policy， WS-RM， WS-Security和WS-I Basic Profile。Axis2不支持WS-Policy，可是承諾在下面的版本支持。

CXF能夠很好支持Spring。Axis2不能
AXIS2支持更普遍的數據並對，如XMLBeans，JiBX，JaxMe和JaxBRI和它自定義的數據綁定ADB。注意JaxME和JaxBRI都仍是試驗性的。CXF只支持JAXB和Aegis。在CXF2.1
Axis2支持多語言-除了Java,他還支持C/C++版本。

比較這兩個框架的Web Service開發方法與比較它們的特性一樣重要。從開發者的角度，兩個框架的特性至關的不一樣。 Axis2的開發方式相似一個小型的應用服務器，Axis2的開發包要以WAR的形式部署到Servlet容器中，好比Tomcat，經過這些容器能夠對工做中的Web Service進行很好的監控和管理。Axis2 的Web administrion模塊可讓咱們動態的配置Axis2.一個新的服務能夠上載，激活，使之失效，修改web服務的參數。管理UI也能夠管理一個或者多個處於運行狀態的服務。這種界面化管理方式的一個弊端是全部在運行時修改的參數沒有辦法保存，由於在重啓動以後，你所作的修改就會所有失效。

Axis2容許本身做爲獨立的應用來發布Web Service，並提供了大量的功能和一個很好的模型，這個模型能夠經過它自己的架構（modular architecture）不斷添加新的功能。有些開發人員認爲這種方式對於他們的需求太過於繁瑣。這些開發人員會更喜歡CXF。

CXF更注重開發人員的工效（ergonomics）和嵌入能力（embeddability）。大多數配置均可以API來完成，替代了比較繁瑣的XML配置文件， Spring的集成性常常的被說起，CXF支持Spring2.0和CXF's API和Spring的配置文件能夠很是好的對應。CXF強調代碼優先的設計方式（code-first design)，使用了簡單的API使得從現有的應用開發服務變得方便。

不過你選擇Axis2仍是CXF，你均可以從開源社區獲得大量的幫助。這兩個框架都有商業公司提供服務，WSO2提供AXIS2的支持，Iona提供CXF的支持。這兩公司都有很活躍的開發者社區。 Axis2出現的時間較早，CXF的追趕速度快。個人建議是：若是你須要多語言的支持，你應該選擇AXIS2。若是你須要把你的實現側重JAVA並但願和Spring集成，CXF就是更好的選擇，特別是把你的Web Service嵌入其餘的程序中。若是你以爲這兩個框架的新特性對於你並無太大的用處，你會以爲Axis1也是不錯的選擇，你應該繼續使用它知道你有充分的理由去更換它。

cxf方式調用webService

參考連接：CXF提供Client調用WebService接口的方法

一、 JaxWsProxyFactoryBean
簡介：調用方式採用了和RMI相似的機制，即客戶端直接服務器端提供的服務接口(interface),CXF經過運行時代理生成遠程服務的代理對象，在客戶端完成對webservice的訪問; 幾個必填的字段：setAddress-這個就是咱們發佈webservice時候的地址，保持一致缺點：這種調用service的好處在於調用過程很是簡單，就幾行代碼就完成一個webservice的調用，可是客戶端也必須依賴服務器端的接口，這種調用方式限制是很大的，要求服務器端的webservice必須是java實現--這樣也就失去了使用webservice的意義

import org.apache.cxf.jaxws.JaxWsProxyFactoryBean;
public class Client {  
    public static void main(String[] args) {  
        JaxWsProxyFactoryBean bean = new JaxWsProxyFactoryBean();  
        bean.setServiceClass(HelloWorldService.class);  
        bean.setAddress("http://localhost:9090/helloWorldService");  
        HelloWorldService helloWorldService = (HelloWorldService)bean.create();  
        String result = helloWorldService.sayHello("Kevin");  
        System.out.println(result);  
    }

二、 JaxWsDynamicClientFactory [Dynamic：動態的] 簡介：只要指定服務器端wsdl文件的位置，而後指定要調用的方法和方法的參數便可，不關心服務端的實現方式。 wsdl [Web Services Description Language]網絡服務描述語言是Web Service的描述語言，它包含一系列描述某個web service的定義

import org.apache.cxf.jaxws.endpoint.dynamic.JaxWsDynamicClientFactory;
public class Client2 {  
    public static void main(String[] args) throws Exception {  
        JaxWsDynamicClientFactory clientFactory = JaxWsDynamicClientFactory.newInstance();  
        Client client = clientFactory.createClient("http://localhost:9090/helloWorldService?wsdl");  
        Object[] result = client.invoke("sayHello", "KEVIN");  
        System.out.println(result[0]);  
    }  
}

三、JaxWsServerFactoryBean 用JaxWsServerFactoryBean發佈，須要獨立的jetty包。