WebService《JavaEE6權威指南 基礎篇第4版》

 

---

【Web服務】

爲運行在不一樣平臺和框架之上的軟件提供了互操做的標準方式。良好的互操做性和可擴展性。消息採用自包含文檔的形式。

——解決異構系統之間交互。 解決異構系統通訊問題： 

1.經過XML，JSON，字符串進行多語言的通信。

2.共享數據庫。

3.共享文件。

4.使用消息中間件。

 

Axis互通訊比較好，對其餘語言訪問的兼容性比較多；

CXF很是容易的整合到Spring架構中；

 

【REST風格】

Representational State Transfer，表述性狀態轉移。Web應用：多使用JAX-RS服務類型。

 

隨着雲技術的發展，JAX-RS將會變得更加劇要。

 

【JAX-WS】

調用與應答經過HTTP協議，以SOAP消息（XML文件）的形式在服務器端與客戶端之間傳輸。

javax.jws.WebService註解將類聲明爲Web服務端點。

【對JAX-WS端點的要求】

實現類的業務方法必須是公有類型，且不能聲明爲static或final。

實現類不能聲明爲final或avstract。

實現類必須有一個默認的公有構造函數。

實現類不能定義finalize方法。

 

 

 

第13章 用JAX-RS構建REST式Web服務

---

REST風格實際上是指一種架構風格，設定諸如統一接口之類的約束條件。

 

性能，可擴展性，可修改性等方面的提高。 

在這種架構風格中，數據和功能都被視爲資源。能夠用URL（統一資源描述符）來訪問。

必須使用無狀態的通訊協議，典型的例子就是HTTP協議。

在REST架構風格里，客戶端和服務器經過標準化的接口和協議來操做資源。

 

如下特性使得REST式應用簡單、輕量化、開發速度也快：

---

1.經過URI識別資源。URI還能夠用於服務發現。

2.統一接口。經過使用4個固定的操做來使用資源。PUT建立資源，GET讀取資源，POST更新資源，DELETE刪除資源。

3.自描述的消息。資源和它們的展現是鬆耦合的。與資源相關的元數據能夠用於諸如控制緩存機制、檢測傳輸錯誤、協商合適的展示格式、以及執行身份驗證或者訪問控制。

4.經過超連接實現有狀態的交互。

 

建立一個REST式根資源類

---

根資源類（root resource class）使用@Path註解。或者POJO類使用「請求方法指示符」註解如@GET@POST@PUT@DELETE。

資源方法（resource method）是指在資源類中使用了請求方法指示符註解的方法。

本節內容講述如何使用JAX-RS來註解Java類，以建立REST式Web服務。

 

JAX-RS 是Java提供的API，使用Java語言提供的註解功能。

定義資源、及可以用在資源上的操做。

 

JAX-RS註解是運行時的註解，所以運行時的反射功能能會爲資源生成輔助類以及中間文件。

JavaEE應用歸檔文件包含：JAX-RS資源類、配置的資源、輔助類以及和中間文件、還有暴露給客戶端的資源。

 

《JAX-RS註解總結》

---

@Path：註解的值是一個相對URI路徑，/helloworld，/helloworld/{username}

@Produces("text/plain") 指定資源能夠生成併發送給客戶端的MIME媒體類型。

 

要獲得用戶輸入的名字，能夠在請求的方法參數裏使用@PathParam註解。

 

@Path("/user/{username}") public class UserResource{     @GET     @Produces("text/xml")     public String getUser(@PathParam("username") String userName){         ...     } }

響應HTTP資源

1.請求方法指示符註解

 

 

參考博客講解

---

《使用JAX-RS建立RESTful Web Service》

 

《SOA，微服務與Docker》
 繼面向對象編程思想又一種較新的編程思想面向服務編程，這樣咱們就不用顧慮語言的差異，提供規範的服務接口，咱們不管使用什麼語言，就均可以訪問使用了，大大提升了程序的複用率。

 

 

 

---

《主流Web Service框架介紹：CXF和Axis2》

CXF和Axis2是目前java平臺上最主流的兩個框架，雖然兩個項目都隸屬ASF，但倒是基於不一樣思想和風格實現的，所以也各有所長。

 

CXF：http://cxf.apache.org/

是由過去的Celtix和XFire兩個框架合併而來，CXF在java社區有普遍的接受度是得益於它能很好的集成Spring。我認爲CXF最突出的兩個優點是：

1.對JAX-WS規範的完整實現。 做爲java平臺上的WebService標準，過去既有的WebService產品必然會向這一標準靠攏，而JAX-WS標準自己大大地下降了開發WebService的工做量，對於開發人員來講，是很是受歡迎的。

2.對Spring的友好支持。 CXF從Xfire繼承而來，對Spring有着很是友好的支持。鑑於Spring的普遍應用，對不少團隊來講這是很是有吸引力的一點。

 

Axis2: http://axis.apache.org/axis2/java/core/

與CXF這類嵌入式的框架相比，Axis2更像是一種是WS容器，它要求應用程序以aar包的形式部署到本身裏面，這對於既有系統，特別是那些基於servlet容器的web應用來講，改造的代價可能會很大。Axis2的優點在於一方面它對WS-*協議族的支持比較全面，另外一方面是它還支持C平臺，這是一個值得咱們關注的優點。

 

總得來講，若是是新生項目，選擇CXF或Axis2在工做量上不會有太大的差異，對於那些使用了Spring的既有項目來講，CXF應該是首選，由於CXF是基於註解的。所以對於那些基於jvm1.4構建陳舊系統可能並不適用。Axis2的優點是支持C平臺和比較全的WS-*協議族。（以上的考量都尚未考慮ESB的因素。）

 

 

【WebService優缺點】

 

From : http://blog.csdn.net/chaobeyond/article/details/2247117

 

最近作的幾個項目都用到了webservice，經過本身的實踐和網上資料的彙總，如今作個小結：        當前WebService是一個熱門話題。可是，WebService到底是什麼？，WebService有什麼優勢和缺點，什麼狀況下應該用WebService？什麼狀況下不該該用WebService？是須要咱們正確認識的。實際上，WebService的主要目標是跨平臺的可互操做性。爲了達到這一目標，WebService徹底基於XML（可擴展標記語言）、XSD （XMLSchema）等獨立於平臺、獨立於軟件供應商的標準，是建立可互操做的、分佈式應用程序的新平臺。由此能夠看出，在如下三種狀況下，使用 WebService會帶來極大的好處。優勢一：跨防火牆的通訊若是應用程序有成千上萬的用戶，並且分佈在世界 各地，那麼客戶端和服務器之間的通訊將是一個棘手的問題。由於客戶端和服務器之間一般會有防火牆或者代理服務器。在這種狀況下，使用DCOM就不是那麼簡 單，一般也不便於把客戶端程序發佈到數量如此龐大的每個用戶手中。傳統的作法是，選擇用瀏覽器做爲客戶端，寫下一大堆ASP頁面，把應用程序的中間層暴 露給最終用戶。這樣作的結果是開發難度大，程序很難維護。舉個例子， 在應用程序里加入一個新頁面，必須先創建好用戶界面(Web頁面)，並在這個頁面後面，包含相應商業邏輯的中間層組件，還要再創建至少一個ASP頁面，用 來接受用戶輸入的信息，調用中間層組件，把結果格式化爲HTML形式，最後還要把「結果頁」送回瀏覽器。要是客戶端代碼再也不如此依賴於HTML表單，客戶 端的編程就簡單多了。若是中間層組件換成WebService的話，就能夠從用戶界面直接調用中間層組件，從而省掉創建ASP頁面的 那一步。要調用WebService，能夠直接使用MicrosoftSOAPToolkit或.NET這樣的SOAP客戶端，也可使用本身開發的 SOAP客戶端，而後把它和應用程序鏈接起來。不只縮短了開發週期，還減小了代碼複雜度，並可以加強應用程序的可維護性。同時，應用程序也再也不須要在每次 調用中間層組件時，都跳轉到相應的「結果頁」。從經驗來看，在一個用戶界面和中間層有較多交互的應用程序中，使用 WebService這種結構，能夠節省花在用戶界面編程上20%的開發時間。另外，這樣一個由WebService組成的中間層，徹底能夠在應用程序集 成或其它場合下重用。最後，經過WebService把應用程序的邏輯和數據「暴露」出來，還可讓其它平臺上的客戶重用這些應用程序。優勢二：應用程序集成企業級的應用程序開發者都知道，企業裏常常都要把用不一樣語言寫成的、在不一樣平臺上運行的各類程序集成起來，而這種集成將花費很大的開發力量。應用程序經 常須要從運行在IBM主機上的程序中獲取數據；或者把數據發送到主機或UNIX應用程序中去。即便在同一個平臺上，不一樣軟件廠商生產的各類軟件也經常須要 集成起來。經過WebService，應用程序能夠用標準的方法把功能和數據「暴露」出來，供其它應用程序使用。例如，有一個訂單登 錄程序，用於登陸從客戶來的新訂單，包括客戶信息、發貨地址、數量、價格和付款方式等內容；還有一個訂單執行程序，用於實際貨物發送的管理。這兩個程序來 自不一樣軟件廠商。一份新訂單進來以後，訂單登陸程序須要通知訂單執行程序發送貨物。經過在訂單執行程序上面增長一層WebService，訂單執行程序可 以把「AddOrder」函數「暴露」出來。這樣，每當有新訂單到來時，訂單登陸程序就能夠調用這個函數來發送貨物了。優勢三：B2B的集成用WebService集成應用程序，可使公司內部的商務處理更加自動化。但當交易跨越供應商和客戶、突破公司的界限時會怎麼樣呢？跨公司的商務交易集成一般叫作B2B集成。WebService是B2B集成成功的關鍵。經過WebService，公司能夠把關鍵的商務應用「暴露」給指定的供應商和客戶。例如，把電子下單系 統和電子發票系統「暴露」出來，客戶就能夠以電子的方式發送訂單，供應商則能夠以電子的方式發送原料採購發票。固然，這並非一個新的概念，EDI(電子 文檔交換)早就是這樣了。可是，WebService的實現要比EDI簡單得多，並且WebService運行在Internet上，在世界任何地方均可 輕易實現，其運行成本就相對較低。不過，WebService並不像EDI那樣，是文檔交換或B2B集成的完整解決方案。WebService只是B2B 集成的一個關鍵部分，還須要許多其它的部分才能實現集成。用WebService來實現B2B集成的最大好處在於能夠輕易實現互操做 性。只要把商務邏輯「暴露」出來，成爲WebService，就可讓任何指定的合做夥伴調用這些商務邏輯，而無論他們的系統在什麼平臺上運行，使用什麼 開發語言。這樣就大大減小了花在B2B集成上的時間和成本，讓許多本來沒法承受EDI的中小企業也能實現B2B集成。優勢四：軟件和數據重用軟件重用是一個很大的主題，重用的形式不少，重用的程度有大有小。最基本的形式是源代碼模塊或者類一級的重用，另外一種形式是二進制形式的組件重用。當前，像表格控件或用戶界面控件這樣的可重用軟件組件，在市場上都佔有很大的份額。但這類軟件的重用有一個很大的限制，就是重用僅限於代碼，數據不能重用。緣由在於，發佈組件甚至源代碼都比較容易，但要發佈數據就沒那麼容易，除非是不會常常變化的靜態數據。WebService在容許重用代碼的同時，能夠重用代碼背後的數據。使用WebService，不再必像之前那樣，要先從第三方購買、安裝軟件組 件，再從應用程序中調用這些組件；只須要直接調用遠端的WebService就能夠了。舉個例子，要在應用程序中確認用戶輸入的地址，只需把這個地址直接 發送給相應的WebService，這個WebService就會幫你查閱街道地址、城市、省區和郵政編碼等信息，確認這個地址是否在相應的郵政編碼區 域。WebService的提供商能夠按時間或使用次數來對這項服務進行收費。這樣的服務要經過組件重用來實現是不可能的，那樣的話你必須下載並安裝好包 含街道地址、城市、省區和郵政編碼等信息的數據庫，並且這個數據庫仍是不能實時更新的。另外一種軟件重用的狀況是，把好幾個應用程序的 功能集成起來。例如，要創建一個局域網上的門戶站點應用，讓用戶既能夠查詢聯邦快遞包裹，查看股市行情，又能夠管理本身的日程安排，還能夠在線購買電影 票。如今Web上有不少應用程序供應商，都在其應用中實現了這些功能。一旦他們把這些功能都經過WebService「暴露」出來，就能夠很是容易地把所 有這些功能都集成到你的門戶站點中，爲用戶提供一個統一的、友好的界面。未來，許多應用程序都會利用WebService，把當前基 於組件的應用程序結構擴展爲組件/WebService的混合結構，能夠在應用程序中使用第三方的WebService提供的功能，也能夠把本身的應用程 序功能經過WebService提供給別人。兩種狀況下，均可以重用代碼和代碼背後的數據。從以上論述能夠看出，WebService在經過Web進行互操做或遠程調用的時候是最有用的。不過，也有一些狀況，WebService根本不能帶來任何好處。缺點一：單機應用程序  目前，企業和我的還使用着不少桌面應用程序。其中一些只須要與本機上的其它程序通訊。在這種狀況下，最好就不要用WebService，只要用本地的 API就能夠了。COM很是適合於在這種狀況下工做，由於它既小又快。運行在同一臺服務器上的服務器軟件也是這樣。最好直接用COM或其它本地的API來 進行應用程序間的調用。固然WebService也能用在這些場合，但那樣不只消耗太大，並且不會帶來任何好處。缺點二：局域網的同構應用程序  在許多應用中，全部的程序都是用VB或VC開發的，都在Windows平臺下使用COM，都運行在同一個局域網上。例如，有兩個服務器應用程序須要相互 通訊，或者有一個Win32或WinForm的客戶程序要鏈接局域網上另外一個服務器的程序。在這些程序裏，使用DCOM會比SOAP/HTTP有效得多。 與此相相似，若是一個.NET程序要鏈接到局域網上的另外一個.NET程序，應該使用.NETremoting。有趣的是，在.NETremoting中， 也能夠指定使用SOAP/HTTP來進行WebService調用。不過最好仍是直接經過TCP進行RPC調用，那樣會有效得多。