webservice簡單瞭解
WebService是一種跨編程語言和跨操做系統平臺的遠程調用技術java
所謂遠程調用，就是一臺計算機a上的一個程序能夠調用到另一臺計算機b上的一個對象的方法，譬如，銀聯提供給商場的pos刷卡系統（採用交互提問的方式來加深你們對此技術的理解）。web
遠程調用技術有什麼用呢？商場的POS機轉帳調用的轉帳方法的代碼是在銀行服務器上，仍是在商場的pos機上呢？編程
什麼狀況下可能用到遠程調用技術呢？例如，amazon，天氣預報系統，淘寶網，校內網，百度等把本身的系統服務以webservice服務的形式暴露出來，讓第三方網站和程序能夠調用這些服務功能，這樣擴展了本身系統的市場佔有率，往大的概念上吹，就是所謂的SOA應用。服務器
所謂跨編程語言和跨操做平臺，就是說服務端程序採用java編寫，客戶端程序則能夠採用其餘編程語言編寫，反之亦然！跨操做系統平臺則是指服務端程序和客戶端程序能夠在不一樣的操做系統上運行。網絡
除了WebService外，常見的遠程調用技術還有RMI（Remote method invoke）和CORBA，因爲WebService的跨平臺和跨編程語言特色，所以比其餘兩種技術應用更爲普遍，但性能略低。框架
二： webservice的調用原理
WebService使用SOAP協議實現跨編程語言和跨操做系統平臺eclipse
WebService採用HTTP協議傳輸數據，採用XML格式封裝數據（即XML中說明調用遠程服務對象的哪一個方法，傳遞的參數是什麼，以及服務對象的返回結果是什麼）。WebService經過HTTP協議發送請求和接收結果時，發送的請求內容和結果內容都採用XML格式封裝，並增長了一些特定的HTTP消息頭，以說明HTTP消息的內容格式，這些特定的HTTP消息頭和XML內容格式就是SOAP協議(simple object access protocol,簡單對象訪問協議) 。編程語言
SOAP協議 = HTTP協議 + XML數據格式 ide
SOAP協議是基於HTTP協議的，二者的關係就比如高速公路是基於普通公路改造的，在一條公路上加上隔離欄後就成了高速公路。工具
商店的服務員只要收到了錢就給客戶提供貨物，商店服務員不用關心客戶是什麼性質的人，客戶也不用關心商店服務員是什麼性質的人。一樣， WebService客戶端只要能使用HTTP協議把遵循某種格式的XML請求數據發送給WebService服務器， WebService服務器再經過HTTP協議返回遵循某種格式的XML結果數據就能夠了，WebService客戶端與服務器端不用關心對方使用的是什麼編程語言。
HTTP協議和XML是被普遍使用的通用技術，各類編程語言對HTTP協議和XML這兩種技術都提供了很好的支持，WebService客戶端與服務器端使用什麼編程語言均可以完成SOAP的功能，因此，WebService很容易實現跨編程語言，跨編程語言天然也就跨了操做系統平臺。
三：WebService調用以前的工做
1.WSDL文件
比如咱們去商店買東西，首先要知道商店裏有什麼東西可買，而後再來購買，商家的作法就是張貼廣告海報。 WebService客戶端要調用一個WebService服務，首先要有知道這個服務的地址在哪，以及這個服務裏有什麼方法能夠調用，因此，WebService服務器端首先要經過一個WSDL文件來講明本身家裏有啥服務能夠對外調用，服務是什麼（服務中有哪些方法，方法接受的參數是什麼，返回值是什麼），服務的網絡地址用哪一個url地址表示，服務經過什麼方式來調用。
WSDL（webservice description language）是基於XML格式的，它是WebService客戶端和服務器端都能理解的標準格式，其中描述的信息能夠分爲what,where,how等部分!
WSDL文件保存在Web服務器上，經過一個url地址就能夠訪問到它。客戶端要調用一個WebService服務以前，要知道該服務的WSDL文件的地址。WebService服務提供商能夠經過兩種方式來暴露它的WSDL文件地址：
註冊到UDDI服務器，以便被人查找
直接告訴給客戶端調用者，例如，在本身網站給出信息或郵件告訴。
四：WebSevice的工做過程
五： WebService的開發應用
WebService開發能夠分爲服務器端開發和客戶端開發兩個方面：
把公司內部系統的業務方法發佈成WebService服務，供遠程合做單位和我的調用。（藉助一些WebService框架能夠很輕鬆地把本身的業務對象發佈成WebService服務，Java方面的典型WebService框架包括：axis，xfire，cxf等，java ee服務器一般也支持發佈WebService服務，例如JBoss。這框架應用不是學習的重點，看看相關的技術手冊都很輕鬆地掌握，關鍵仍是要了解WebService的工做原理。）
調用別人發佈的WebService服務，大多數人從事的開發都屬於這個方面，例如，調用天氣預報WebService服務。（使用廠商的WSDL2Java之類的工具生成靜態調用的代理類代碼；使用廠商提供的客戶端編程API類；使用SUN公司早期標準的jax-rpc開發包；使用SUN公司最新標準的jax-ws開發包。）
六：WebService的客戶端編程原理1.咱們給這各種WebService客戶端API傳遞wsdl文件的url地址，這些API就會建立出底層的代理類，我調用這些代理，就能夠訪問到webservice服務。代理類把客戶端的方法調用變成soap格式的請求數據再經過HTTP協議發出去，並把接收到的soap數據變成返回值返回。
2.工具類生成靜態代理類的方式
xfire的WSGen
還須要額外導入ant.jar包
axis的WSDL2java
寫批處理或直接在eclipse中運行這個類
jdk6的wsimport
cxf的…
3.動態代理類的方式
使用jax-rpc
第一步是建立xxx.Service實例對象
調用getPort返回代理，客戶端的接口要實現remote接口,由於客戶端代理是用java技術生成的，java生成的遠程調用的代理必須實現remote接口，即我實現的代理靠的是java的remote技術。
使用jax-ws
第一步就是建立出javax.xml.ws.Service實例對象
4.動態方法的調用
使用jax-rpc
第一步是建立xxx.Service實例對象
調用getCall返回Call對象，call的invoke實現動態調用。
使用jax-ws
第一步就是建立出javax.xml.ws.Service實例對象
七：WebService框架的底層原理
各種WebService框架的本質就是一個大大的Servlet，當遠程調用客戶端給它經過http協議發送過來soap格式的請求數據時，它分析這個數據，就知道要調用哪一個java類的哪一個方法，因而去查找或建立這個對象，並調用其方法，再把方法返回的結果包裝成soap格式的數據，經過http響應消息回給客戶端。
1.不一樣框架之間的比較
JAX-WS
Jax-WS是Java1.6中才有的,新的WebService模式,基於註解的方式配置WebService,很相似Asp中的WebService,難度已經比Xfire方式的配置下降了不少.
JAX-WS——Java API for XML Web Services (JAX-WS)是Java程序設計語言一個用來建立Web服務的API。
REST(JAX-RS)
用的比較少
Xfire（已過期）
配置比較繁瑣
八：HttpService和WebService的區別
HTTPService基於http協議，而WebService基於soap協議
在處理數據上HTTPService效率較高，WebService能處理較複雜的數據類型
簡單說
httpservice經過post和get獲得你想要的東西
webservice就是使用soap協議獲得你想要的東西，相比httpservice能處理些更加複雜的數據類型
XML
可擴展的標記語言(XML)是Web service平臺中表示數據的基本格式。除了易於創建和易於分析外，XML主要的優勢在於它既是平臺無關的，又是廠商無關的。無關性是比技術優越性更重要的：軟件廠商是不會選擇一個由競爭對手所發明的技術的。
SOAP
SOAP是web service的標準通訊協議，SOAP爲simple object access protocoll的縮寫，簡單對象訪問協議. 它是一種標準化的傳輸消息的XML消息格式。
WSDL
WSDL的全稱是web service Description Language,是一種基於XML格式的關於web服務的描述語言。其主要目的在於web service的提供者將本身的web服務的全部相關內容,如所提供的服務的傳輸方式，服務方法接口，接口參數，服務路徑等，生成相應的徹底文檔，發佈給使用者。使用者能夠經過這個WSDL文檔，建立相應的SOAP請求消息，經過HTTP傳遞給webservice提供者；web服務在完成服務請求後，將SOAP返回消息傳回請求者，服務請求者再根據WSDL文檔將SOAP返回消息解析成本身可以理解的內容。
UDDI
將web service進行UDDI註冊發佈,UDDI是一種建立註冊表服務的規範,以便你們將本身的web service進行註冊發佈供使用者查找.然而當服務提供者想將本身的web service向全世界公佈，以便外部找到其服務時，那麼服務提供者能夠將本身的web service註冊到相應的UDDI商用註冊網站，目前全球有IBM等4家UDDI商用註冊網站。由於WSDL文件中已經給定了web service的地址URI，外部能夠直接經過WSDL提供的URI進行相應的web service調用。因此UDDI並非一個必需的web service組件，服務方徹底能夠不進行UDDI的註冊。