1. Java遠程方法調用
Java遠程方法調用，即Java RMI（Java Remote Method Invocation）是Java編程語言裏，一種用於實現遠程過程調用的應用程序編程接口。
1.1 遠程調用方案比較
1、Java RMI (Remote Method Invocation)
2、EJB遠程接口調用
3、WebService，如jax-ws axis xfire cfx
4、Hessian以及Spring HttpInvoker
5、直接動態請求返回JSON數據
6、等。。。
本文從配置複雜性、編碼難度、執行效率、跨語言性、兼容性、安全性、協議類型、是否綁定特定框架等方面做一個簡單的比較分析。
JavaRMI是jdk中內嵌的一個最底層的解決方案，它應用起來最輕量級，也最簡單，它不需要任何的web服務器，直接在代碼中綁定IP地址和相應的端口，如果是非常簡單的小微應用比較適合，因爲最底層其效率應該不錯，接下來的幾種調用方式其他有一些都是以這個爲基礎擴展而來的。其缺點也很明顯，如果業務非常多而複雜、接口調用非常頻繁需要分佈在多臺服務器，那麼其編碼很不優雅、也難於實現分佈式等，且所有的東西都集中在代碼裏了，可讀性可維護性等都不太理想，不具備跨語言的調用。
EJB遠程接口調用，其最本質的底層仍然是JavaRMI，通過JNDI來調用服務。不過EJB遠程接口調用的優點是，可以非常輕鬆的實現分佈式，客戶端編碼有些版本比較複雜，但多數代碼一般可以藉助IDE自動完成，EJB3.0以後的版本編碼和配置起來也更簡單。缺點是，EJB是個重量級的框架，需要EJB容器的支撐，很多web服務器都不具備這個功能，如resin、tomcat等，如果業務代碼不是使用EJB的話，遠程調用自然不適用。目前互聯網開發中EJB已經非常少見了，可能是spring的崛起以及非常有名的那本書《Expert One-on-One J2EE Development without EJB》，有中文版。
WebService是很常見的遠程調用方法，其最大的優勢就是跨平臺語言，無論客戶端是Java還是.NET都能輕鬆的調用。它採用SOAP(Simple Object Access Protocol)協議來封裝序列化的消息，實際上是形成一個xml文件，可以通過http進行網絡傳輸。WebService的客戶端調用其實是使用生成文件的方式，只要知道發佈接口的URL即可，而不需要額外傳遞jar包或者class文件。常見的WebService實現有jax-ws2.0、axis、xfire以及cfx，其中jax-ws2.0是jdk中封裝好的，有一定的靈活性，但是這種把框架內嵌進入JVM其實對其可控性大大降低；axis有1.0和2.0兩個版本，這個不是太瞭解；xfire和cfx其實是一個源頭，xfire在07年停止開發，和另外一個框架合併形成了cfx，是一個比較受歡迎的WebService實現。
Hessian是另外一個非常常用的遠程調用方案，它基於Binary-RPC協議，這個協議把請求和響應的數據統統使用標準的二進制格式進行封裝，所以它也具有跨語言平臺傳輸數據的能力，而且它有自己的高效的序列化和反序列化機制。不過hessian在版本控制中經常出現互不兼容的情況，服務器端和客戶端通常要保持一致的版本，否則會出現莫名其妙的問題，還有常見的各種錯誤，如使用nginx反向代理後返回411錯誤等。spring對hessian提供了很好的支持，通常配合使用；同時spring還有一套自己的遠程調用方法HttpInvoker。如果你使用過Hessian和HttpInvoker的話，就會發現它倆的配置幾乎一模一樣，包括接口名稱、類名、字段名、調用和發佈代碼。。。而且不能同時使用，會相互產生衝突。它們都是通過servlet進行請求處理，需要servlet容器支持，效率不錯。
直接動態請求返回JSON數據，是一個直觀上的方式，嚴格來說不屬於遠程方法的調用。這種方式就是通過一個servlet請求直接由容器返回封裝好的JSON數據，數據結構不夠靈活，安全性也不足。不過實現起來簡單，和業務代碼一起就順帶寫完了，幾乎都不需要客戶端的概念，只要請求數據足夠簡單、安全措施做好也可以使用。
1.2 遠程調用技術舉例
Dubbo、RMI、Webservice、Hessian、netty等。
1.3 基本原理
在底層層面去看，就是將流從一臺計算機傳輸到另外一臺計算機，基於傳輸協議（ http、tcp、udp等等）和網絡IO（ bio、nio、aio ）來實現。
1.4 關鍵技術點
1. 通信協議：傳輸層:socket(tcp,udp) 應用層: http
2. 應用級的協議（dubbo, JRMP,SOAP, xml-rpc(xml+http),binary-RPC(二進制+http)）
2.1. 提供更加易用的標準傳輸格式,避免直接做流操作.
2.2. 實現網絡通信機制
將傳輸格式轉化爲流
通過某種傳輸協議傳輸至遠端計算機
遠端計算機將流轉化爲傳輸格式
3.網絡IO
bio(阻塞)、
nio(非阻塞)、
aio(異步，jdk7中新特性)。
4. MultiThread,在服務端爲每個請求啓用一個線程
5. 本地調用與遠程調用的透明化方案
Java classloader、Dynamic Proxy
6. 網絡通信處理機制
自動重連、廣播、異常、池處理等等
7. 序列化
各種協議的序列化機制
2. 什麼是webservice？
Web service 即web服務，它是一種跨編程語言和跨操作系統平臺的遠程調用技術即跨平臺遠程調用技術。
採用SAOP(Simple Object Access Protocol) 協議傳輸，SAOP屬於w3c標準。SAOP協議是基於HTTP的應用層協議，SAOP協議傳輸是xml數據。SAOP是一種應用層協議，基於HTTP的二次封裝（在HTTP 基礎又定義一套協議）。簡單理解:SAOP=(HTTP+xml)
採用WSDL作爲描述語言即webservice使用說明書，WSDL屬w3c標準.
xml是webservice的跨平臺的基礎，XML主要的優點在於它既與平臺無關，又與廠商無關。
XSD，W3C爲webservice制定了一套傳輸數據類型，使用xml進行描述，即XSD(XML Schema Datatypes)，任何編程語言寫的webservice接口在發送數據時都要轉換成webservice標準的XSD發送。
當前非SAOP協議的webService以輕量爲首要目標，比如HTTP rest方式也是webservice的一種方式，或者直接使用HTTP自定義數據協議，比如HTTP傳輸json數據，HTTP傳輸xml數據等。
3. Webservice三要素
3.1 SAOP（通信協議）
SAOP 即 Simple Object AccessProtocol 也就是簡單對象訪問協議。
SAOP是webservice 的傳輸協議，SAOP=HTTP+xml。
因爲 SAOP 基於XML 和 HTTP ，其通過XML 來實現消息描述，然後再通過 HTTP 實現消息傳輸。
SAOP當前有兩個版本 SAOP1.1.和SAOP1.2 。
SAOP協議不是webservice的專有協議。
例如，SMTP、tr069協議在SAOP協議的基礎上定義的新協議等。
3.2 WSDL（使用說明書）
WSDL 即Web Services Description Language也就是 Web 服務描述語言。
是基於 XML的用於描述 Web 服務以及如何訪問 Web 服務的語言。
基於 XML 的用於描述Web Service及其函數、參數和返回值。通俗理解WSDL是webservice的使用說明書。
使用方法：
服務端發佈了一個webservice 接口之後，通過WSDL說明書(xml格式)查詢接口內容。
WSDL 描述了 Web服務的三個基本屬性：
（1）服務所提供的操作
（2）如何訪問服務
（3）服務位於何處（通過 URL 來確定就 OK 了）
3.3 UDDI（目錄）
UDDI 即 Universal Description，Discovery and Integration，也就是通用的描述，發現以及整合。
UDDI 是一種目錄服務，企業可以通過 UDDI 來註冊和搜索 Web 服務。
簡單來時候話，UDDI 就是一個目錄，只不過在這個目錄中存放的是一些關於 Web 服務的信息而已。
並且 UDDI 通過SOAP 進行通訊，構建於 . Net 之上。
4. Java中webservice開發規範？
4
4.1 JAX-WS（掌握）
JAX-WS 的全稱爲 Java API for XML-Based Webservices ，通過java api面向對象開發webservice。
jax-ws採用SAOP協議。
4.2 JAXM&SAAJ
JAXM（JAVA API For XML Message）主要定義了包含了發送和接收消息所需的API，通過JAXM更多操作 SAOP協議細節。
JAXM&SAAJ在webservice通信時傳輸附件。
4.3 JAX-RS（掌握）
JAX-RS 是JAVA 針對REST(Representation State Transfer)風格制定的一套Web 服務規範，由於推出的較晚，該規範（JSR 311，目前JAX-RS 的版本爲1.0）並未隨JDK1.6 一起發行。
JAX-RS可以直接基於HTTP方式開發。
接口更輕量。
使用cxf來實現rest方式。
傳輸層tcp協議
tcp：面向連接協議，這種協議很穩定，客戶端經過三次握手可以和服務端建立一個通道,在這個通道進行通信。
udp:數據報協議，不穩定，客戶端只管向服務發送數據，服務端可能接收不到。
總結：
接口開發使用的基礎協議包括tcp和udp。
5. 使用jaxws調用公網天氣查詢
4.1 服務端
公網已經提供天氣查詢服務。
4.2 客戶端
使用wsimport生成調用代碼。
1、 找到公網天氣查詢WSDL說明書。
2、 生成代碼。
3、客戶端代碼。
|
package cn.com.client;
|
6. Socket優缺點？
優點：
socket是傳輸層工作，基於tcp/ip封裝一個接口規範。
可以跨平臺（客戶端操作系統、和編程語言和服務端不一樣）。
傳輸速度是很快的，要傳輸一些大數據可以採用socket。
缺點：
socket在開發時需要手動通過流解析數據流，此時遵循的是一種自定義的協議。
自定義協議：客戶端和服務端通信內容是需要在代碼中手動特殊的解析，比如：客戶端和服務端發送xml數據，xml數據的內容就是自定義的，客戶端和服務端編程時需要在代碼對xml數據的解析特殊處理。
7. Webservice優缺點？
優點：
採用xml支持跨平臺遠程調用。
基於HTTP的SAOP協議，可跨越防火牆。
基於 SAOP協議使用webservice服務程序可以部署在tocmat中，通過80對外提供服務。
支持面向對象開發。
有利於軟件和數據重用，實現鬆耦合。
缺點：
SAOP協議基於xml方式傳輸，傳輸效率不高。
|
|
|||||
SAOP爲了支持面向對象開發，兩端都有序列化過程。
建議：
如果對接口速度要求不高，爲了協議標準，建議使用SAOP。
8. Webservice和Socket的區別？
7.1 關係
底層基於tcp/ip協議,使用socket進行通信。
上層jaxws使用SAOP協議，SAOP基於HTTP傳輸xml數據。
通過socket編程方式實現jaxws通信。
結論：
Webservice採用SAOP協議進行通信，底層基於socket通信，webservice不需專門針對數據流的發送和接收進行處理，是一種跨平臺的面向對象遠程調用技術。
7.2 區別
網絡七層協議爲：物理層、數據鏈路層、網絡層、傳輸層、會話層、表示層、應用層。
socket 只是 java在網絡層定義的類，用來實現網絡層。上面的各層需要我們自己在程序裏實現。例如端口可以自己定義 、數據包的定義、 數據包的加密解密等
而webService java實現了應用層的工具，他基於的服務爲HTTP協議，通過服務器纔可以發佈出去。這樣內部的端口的定義、數據包的定義和數據包的加密解密都做好了，所以我們就直接可以用了。
webService 內部數據格式爲xml格式、由於基於HTTP協議，所以可以不受防火牆的影響。因爲他的通信協議和我們瀏覽網頁的協議是相同的。
9. Webservice 技術選型
9.1 協議約定
服務端採用什麼協議，客戶端也使用什麼協議。
9.2 通用性(公開性)
對於一個webservice主要考慮接口的通用性時，在不要求性能的前提下可以使用SAOP協議(w3c標準)。
如果有性能要求，還要求通用性：哪個接口技術性能高並且還通用，優先推薦HTTP。
9.3 高性能
幾種技術性能從高到低是：
socket>RMI（客戶端和服務端都爲java）>hessian>HTTP>SAOP
9.4 企業開發規範
如果企業定義開發規範，其中包括接口規範，已經確定接口使用技術，使用什麼協議。
比如：有些公司統一確定採用HTTP+json方式。
10. Webservice技術實現方法
博客：Java開發中經常使用到的幾種WebService技術實現方案
http://blog.csdn.net/zolalad/article/details/25158995
博客：幾種流行Webservice框架性能對比（轉載、拼接）
http://blog.csdn.net/chenleixing/article/details/44958549
目前三種主流的web服務實現方法：
REST（新型）：表象化狀態轉變 (軟件架構風格）RESTEasy、Wink、CXF、Axis2……
SOAP（比較成熟）：簡單對象訪問協議 Xfire、Axis2、CXF、Axis1
XML-RPC（淘汰）：遠程過程調用協議（慢慢被soap 所取代）
如何選擇？
Apache CXF是CodehausXFire的第二代產品，目前在不同框架中性能最佳，應該是開發者不錯的選擇，這與它本身的架構設計不無關係。相比其他框架，CXF具有幾個突出的特性：支持JAX-WS、Spring集成、Aegi數據綁定、支持RESTful services、支持WS-*、Apache協議、代碼實現簡潔。
Apache Axis2是Apache Axis1的第二代產品，架構上也非常不錯，關鍵特性：支持多語言（C/C++）、支持各種規範、可插拔模塊化設計、支持熱部署等。與CXF相比性能也非常優異。
RESTEasy也許也是個不錯的框架！（個人觀點）