開發中經常會用到遠端呼叫技術（本人常用webservice （使用CXF框架），httpclient(使用okclient框架) ），所以查查常用技術的有哪些，下面是轉的一篇內容，用於理解還可以，但是見解已經比較偏舊了，後面找找合適的資料，再寫一篇合適的

一、綜述

本文比較了RMI，Hessian，Burlap，Httpinvoker，web service等5種通訊協議的在不同的資料結構和不同資料量時的傳輸效能。

RMI是java語言本身提供的遠端通訊協議，穩定高效，是EJB的基礎。但它只能用於JAVA程式之間的通訊。
Hessian和Burlap是caucho公司提供的開源協議，基於HTTP傳輸，服務端不用開防火牆埠。協議的規範公開，可以用於任意語言。
Httpinvoker是SpringFramework提供的遠端通訊協議，只能用於JAVA程式間的通訊，且服務端和客戶端必須使用SpringFramework。
Web service是連線異構系統或異構語言的首選協議，它使用SOAP形式通訊，可以用於任何語言，目前的許多開發工具對其的支援也很好。
—SOAP
SOAP即簡單物件訪問協議(Simple Object Access Protocol)，它是用於交換XML編碼資訊的輕量級協議。它有三個主要方面：XML-envelope為描述資訊內容和如何處理內容定義了框架，將程式物件編碼成為XML物件的規則，執行遠端過程呼叫(RPC)的約定。SOAP可以執行在任何其他傳輸協議上。Web Service 希望實現不同的系統之間能夠用“軟體-軟體對話”的方式相互呼叫，打破了軟體應用、網站和各種裝置之間的格格不入的狀態，實現“基於Web無縫整合”的目標。
—WSDL
Web Service描述語言WSDL　就是用機器能閱讀的方式提供的一個正式描述文件而基於XML的語言，用於描述Web Service及其函式、引數和返回值。因為是基於XML的，所以WSDL既是機器可閱讀的，又是人可閱讀的。
測試結果顯示，幾種協議的通訊效率依次為：
RMI > Httpinvoker >= Hessian >> Burlap >> web service
RMI不愧是JAVA的首選遠端呼叫協議，非常高效穩定，特別是在大資料量的情況下，與其他通訊協議的差距尤為明顯。
HttpInvoker使用java的序列化技術傳輸物件，與RMI在本質上是一致的。從效率上看，兩者也相差無幾，HttpInvoker與RMI的傳輸時間基本持平。
Hessian在傳輸少量物件時，比RMI還要快速高效，但傳輸資料結構複雜的物件或大量資料物件時，較RMI要慢20%左右。
Burlap僅在傳輸1條資料時速度尚可，通常情況下，它的耗時是RMI的3倍。
Web Service的效率低下是眾所周知的，平均來看，Web Service的通訊耗時是RMI的10倍。

二、結果分析 

1、RMI呼叫
與設想的一樣，RMI理所當然是最快的，在幾乎所有的情況下，它的毫時都是最少的。特別是在資料結構複雜，資料量大的情況下，與其他協議的差距尤為明顯。
為了充分發揮RMI的效能，另外做了測試類，不使用Spring，用原始的RMI形式（繼承UnicastRemoteObject物件）提供服務並遠端呼叫，與Spring對POJO包裝成的RMI進行效率比較。結果顯示：兩者基本持平，Spring提供的服務還稍快些。
初步認為，這是因為Spring的代理和快取機制比較強大，節省了物件重新獲取的時間。
2、Hessian呼叫
caucho公司的resin伺服器號稱是最快的伺服器，在java領域有一定的知名度。Hessian做為resin的組成部分，其設計也非常精簡高效，實際執行情況也證明了這一點。平均來看，Hessian較RMI要慢20%左右，但這只是在資料量特別大，資料結構很複雜的情況下才能體現出來，中等或少量資料時，Hessian並不比RMI慢。
Hessian的好處是精簡高效，可以跨語言使用，而且協議規範公開，我們可以針對任意語言開發對其協議的實現。目前已有實現的語言有：java, c++, .net, python, ruby。還沒有delphi的實現。
另外，Hessian與WEB伺服器結合非常好，藉助WEB伺服器的成熟功能，在處理大量使用者併發訪問時會有很大優勢，在資源分配，執行緒排隊，異常處理等方面都可以由成熟的WEB伺服器保證。而RMI本身並不提供多執行緒的伺服器。而且，RMI需要開防火牆埠，Hessian不用。
3、Burlap呼叫
Burlap與Hessian都是caucho公司的開源產品，只不過Hessian採用二進位制的方式，而Burlap採用xml的格式。
測試結果顯示，Burlap在資料結構不復雜，資料量中等的情況下，效率還是可以接受的，但如果資料量大，效率會急劇下降。平均計算，Burlap的呼叫耗時是RMI的3倍。
我認為，其效率低有兩方面的原因，一個是XML資料描述內容太多，同樣的資料結構，其傳輸量要大很多；另一方面，眾所周知，對xml的解析是比較費資源的，特別對於大資料量情況下更是如此。
4、HttpInvoker呼叫
HttpInvoker是SpringFramework提供的JAVA遠端呼叫方法，使用java的序列化機制處理物件的傳輸。從測試結果看，其效率還是可以的，與RMI基本持平。
不過，它只能用於JAVA語言之間的通訊，而且，要求客戶端和服務端都使用spring框架。
另外，HttpInvoker 並沒有經過實踐的檢驗，目前還沒有找到應用該協議的專案。
5、web service呼叫
本次測試選用了apache的AXIS元件作為WEB SERVICE的實現，AXIS在WEB SERVICE領域相對成熟老牌。
為了僅測試資料傳輸和編碼、解碼的時間，客戶端和服務端都使用了快取，物件只需例項化一次。但是，測試結果顯示，web service的效率還是要比其他通訊協議慢10倍。
如果考慮到多個引用指向同一物件的傳輸情況，web service要落後更多。因為RMI，Hessian等協議都可以傳遞引用，而web service有多少個引用，就要複製多少份物件實體。
Web service傳輸的冗餘資訊過多是其速度慢的原因之一，監控發現，同樣的訪問請求，描述相同的資料，web service返回的資料量是hessian協議的6.5倍。另外，WEB SERVICE的處理也很耗時，目前的xml解析器效率普遍不高，處理xml <—-> bean很耗資源。從測試結果看，異地呼叫比本地呼叫要快，也從側面說明了其毫時主要用在編碼和解碼xml檔案上。這比冗餘資訊更為嚴重，冗餘資訊佔用的只是網路頻寬，而每次呼叫的資源耗費直接影響到伺服器的負載能力。（MS的工程師曾說過，用WEB SERVICE不能負載100個以上的併發使用者。）
測試過程中還發現，web service編碼不甚方便，對非基本型別需要逐個註冊序列化和反序列化類，很麻煩，生成stub更累，不如spring + RMI/hessian處理那麼流暢簡潔。而且，web service不支援集合型別，只能用陣列，不方便。