WebService - RoadMap

Why RoadMap

因爲網絡帶寬的發展，WebService做爲分佈式計算的解決方案愈來愈重要。若是想學習WebService，那應該首先從最高層次瞭解WebService的工做原理，以及技術構成。而後再往底層深化，細分，瞭解每個細節。

WebService發展

WSDL+SOAP

WebService是一種通用的，誇語言，誇平臺，誇系統的分佈式解決方案。首先，咱們須要拋開全部的平臺，語言和實現細節，從最初設計WebService時的想法，來討論一下WebService的基礎構成。

WebService依賴於4個標準，HTTP, XML, SOAP和WSDL。

讓咱們來設想一個場景。存在一個網站A，A的數據庫數據愈來愈豐富，A的功能也愈來愈多。A發現，若是對外提供服務，可使其它網站使用本身的功能和數據，那豈不是能夠賺更多的錢？因而A作了如下幾個步驟：

1. 開發了一些服務項目，作好對外開放的準備。

2. A須要把本身開放的服務制定一個描述文件（WSDL），好讓其它網站可以遵守描述的方式，使用開放的服務。

3. 網站B想使用網站A的服務，因而A把WSDL所有發給了B.

4. B遵守WSDL的描述，產生請求。這個請求的數據格式爲SOAP，編碼格式爲XML。

5. 載着SOAP格式數據的XML實體，經過HTTP協議發往A。

6. A接收HTTP請求帶來的XML數據，因爲XML數據是遵循SOAP協議組織的，A知道如何解析其中的內容。

7. A執行服務，產生響應。這個響應的數據格式爲SOAP，編碼格式爲XML。

8. 載着SOAP格式數據的XML實體，經過HTTP協議發往B。

9. B根據WSDL的描述，明白A返回的數據如何解析。

上面的步驟，粗略的解釋了HTTP, XML, SOAP與WSDL在WebService中的做用。

Restfull

使用WSDL和SOAP的代價挺大，首先，做爲一個java web程序員，須要額外的學習WSDL相關的知識。其次，因爲客戶端須要導入WSDL，這使得耦合度加大。再其次，SOAP協議使得HTTP承載的body比較大，浪費帶寬。最後，生成和解析SOAP協議也要花時間。

隨着AJAX和JSON的流行，逐漸興起了一種更加寬鬆，靈活，輕量級的WebService，這就是Restfull API. Restfull是使用HTTP傳輸XML或JSON或任意格式的數據。這拋棄了WSDL, SOAP。

Java WebService

不管是WSDL+SOAP方式，仍是Restfull方式，產生和解析傳輸數據實體，都是比較費代碼的。因而Java提供了一種機制，能夠幫助咱們自動的產生傳輸數據，咱們在編程的時候，只須要專一於服務接口的調用。這個幫助咱們產生傳輸數據的就像是一個Proxy。在WSDL和SOAP模式下，Proxy能夠根據WSDL產生相應的SOAP數據，也能夠解析返回的SOAP數據。

在J2EE 1.4時代，有JAX-RPC作proxy。後來從J2EE5開始，多了JAX-WS. 到了J2EE6，又有了JAX-RS.

當前開發WebService最經常使用的框架就是Axis2和Metro，也有用Spring-WS的。

Metro與Axis2

Metro是由sun，如今的oracle開發的服務棧，Metro只支持JAXB與JAX-WS，因爲歷史緣由，也支持JAX-RPC。而Axis2不只支持JAXB和JAX-WS，還支持其它全部可能的技術。因此，JAXB與JAX-WS技術幾乎就是Metro的所有，而JAXB與JAX-WS只是Axis2的一方面，在Axis2下，也能夠不適用JAX-WS。

在發佈方面，Metro引擎須要被部署的webservice war包含sun-jaxws.xml。而Metro的servlet會爲全部的webservice請求服務。

由於oracle的緣由，咱們接下來所學的均是Metro框架。https://metro.java.net/2.3/ 

下面是Metro對WebService的支持所指定的規範，其中J2EE部分是Proxy的實現，咱們在開發的時候，會任選一個。XML部分是對XML使用的規範，這部分屬於XML的知識範疇。

後面的文章，我會從實例出發，描述WebService在Java的實現方式。