一、綜述
本文比擬了RMI，Hessian，Burlap，Httpinvoker，web service等5種通信協(xié)議的在不同的數(shù)據(jù)構(gòu)造和不同數(shù)據(jù)量時的傳輸功能。
RMI是java語言本身供給的長途通信協(xié)議，安寧高效，是EJB的基礎(chǔ)。但它只能用于JAVA過程之間的通信。
Httpinvoker是SpringFramework供給的長途通信協(xié)議，只能用于JAVA過程間的通信，且服務(wù)端和客戶端定然利用SpringFramework。
Hessian和Burlap是caucho公司供給的開源協(xié)議，基于HTTP傳輸，服務(wù)端無須開防火墻端口。協(xié)議的規(guī)范公布，能夠用于任意語言。
Web service是連接異構(gòu)系統(tǒng)或異構(gòu)語言的首選協(xié)議，它利用SOAP形式通信，能夠用于任何語言，現(xiàn)在的眾多開發(fā)工具對其的扶持也很好。
測驗收獲揭示，幾種協(xié)議的通信效率順次為：
RMI > Httpinvoker >=Hessian > > Burlap > > web service
RMI不愧是JAVA的首選長途調(diào)用協(xié)議，極其高效安寧，尤其是在大數(shù)據(jù)量的情形下，與其他通信協(xié)議的差距尤為顯明。
HttpInvoker利用java的序列化技巧傳輸對象，與RMI在性質(zhì)上是統(tǒng)一的。從效率上看，兩者也相差無幾，HttpInvoker與RMI的傳輸工夫大約持平。
Hessian在傳輸少量對象時，比RMI還要迅速高效，但傳輸數(shù)據(jù)構(gòu)造混雜的對象或許多數(shù)據(jù)對象時，較RMI要慢20%左右。
Burlap僅在傳輸1條數(shù)據(jù)時速度尚可，通常情形下，它的毫?xí)r是RMI的3倍。
Web Service的效率低下是眾所周知的，平衡來看，Web Service的通信耗時是RMI的10倍。
二、收獲分析
1、直接調(diào)用
直接調(diào)用的所有耗時都接近0，這解釋過程處理幾乎未曾花費工夫，登記的全副工夫都是長途調(diào)用花費的。
2、RMI調(diào)用
與假象的一樣，RMI天公單純是最快的，在幾乎所有的情形下，它的耗時都是起碼的。尤其是在數(shù)據(jù)構(gòu)造混雜，數(shù)據(jù)量大的情形下，與其他協(xié)議的差距尤為顯明。
為了富余施展RMI的功能，另外做了測驗類，不利用Spring，用原始的RMI形式（繼承UnicastRemoteObject對象）供給服務(wù)并長途調(diào)用，與Spring對POJO包裝成的RMI舉行效率比擬。收獲揭示：兩者大約持平，Spring供給的服務(wù)還稍快些。
開始感受，這是因為Spring的代辦緩和存機制比擬壯大，勤儉了對象重新獲得的工夫。
3、Hessian調(diào)用
caucho公司的resin服務(wù)器號稱是最快的服務(wù)器，在java領(lǐng)土有定然的知名度。Hessian做為resin的構(gòu)成局部，其設(shè)計也極其精簡高效，切實運行情形也驗證了這一點。平衡來看，Hessian較RMI要慢20%左右，但這只是在數(shù)據(jù)量尤其大，數(shù)據(jù)構(gòu)造很混雜的情形下能力揭示出來，中等或少量數(shù)據(jù)時，Hessian并不比RMI慢。
Hessian的利益是精簡高效，能夠跨語言利用，而且協(xié)議規(guī)范公布，我們能夠針對任意語言開發(fā)對其協(xié)議的告終。現(xiàn)在已有告終的語言有：java,dbmjj.com c++, .net, python, ruby。還未曾delphi的告終。
另外，Hessian與WEB服務(wù)器聯(lián)合極其好，借助WEB服務(wù)器的成熟功能，在處理許多用戶并發(fā)拜會時會有很大優(yōu)勢，在資源分配，線程排隊，失常處理等方面都能夠由成熟的WEB服務(wù)器保證。而RMI本身并不供給多線程的服務(wù)器。而且，RMI必需開防火墻端口，Hessian無須。
4、Burlap調(diào)用
Burlap與Hessian都是caucho公司的開源產(chǎn)品，只不過Hessian批準(zhǔn)二進制的措施，而Burlap批準(zhǔn)xml的款式。
測驗收獲揭示，Burlap在數(shù)據(jù)構(gòu)造不混雜，數(shù)據(jù)量中等的情形下，效率還是能夠接受的，但萬一數(shù)據(jù)量大，效率會飛快降落。平衡計算，Burlap的調(diào)用耗時是RMI的3倍。
我感受，其效率低有雙邊面的起因，一個是XML數(shù)據(jù)描寫內(nèi)容太多，同樣的數(shù)據(jù)構(gòu)造，其傳輸量要大許多；另一方面，眾所周知，對xml的解析是比擬費資源的，尤其對于大數(shù)據(jù)量情形下更是如此。
5、HttpInvoker調(diào)用
HttpInvoker是SpringFramework供給的JAVA長途調(diào)用措施，利用java的序列化機制處理對象的傳輸。從測驗收獲看，其效率還是能夠的，與RMI大約持平。
不過，它只能用于JAVA語言之間的通信，而且，要求客戶端和服務(wù)端都利用SPRING框架。
另外，HttpInvoker 并未曾穿越實踐的驗證，現(xiàn)在還未曾找到利用該協(xié)議的項目。
6、web service調(diào)用
本次測驗撥取了apache的AXIS組件作為WEB SERVICE的告終，AXIS在WEB SERVICE領(lǐng)土相對成熟老牌。
為了僅測驗數(shù)據(jù)傳輸和編碼、解碼的工夫，客戶端和服務(wù)端都利用了緩存，對象只需實例化順次。然而，測驗收獲揭示，web service的效率還是要比其他通信協(xié)議慢10倍。
萬一琢磨到多個引用指向統(tǒng)一對象的傳輸情形，web service要掉隊更多。因為RMI，Hessian等協(xié)議都能夠遞交引用，而web service有多少個引用，即將復(fù)制多少份對象實體。
Web service傳輸?shù)娜哂嘞⑦^多是其速度慢的起因之一，監(jiān)控覺察，同樣的拜會哀求，描寫雷同的數(shù)據(jù)，web service歸來的數(shù)據(jù)量是hessian協(xié)議的6.5倍。另外，WEB SERVICE的處理也很耗時，現(xiàn)在的xml解析器效率普遍不高，處理xml<->bean很耗資源。從測驗收獲看，異地調(diào)用比本地調(diào)用要快，也從側(cè)面解釋了其耗時重要用在編碼和解碼xml文件上。這比冗余消息更為嚴(yán)重，冗余消息挪借的只是網(wǎng)絡(luò)帶寬，而每次調(diào)用的資源花費直接波及到服務(wù)器的負載力氣。（MS的工程師曾說過，用WEB SERVICE不能負載100個以上的并發(fā)用戶。）
測驗過程中還覺察，web service編碼不甚得體，對非大約種類必需逐個登記序列化和反序列化類，很繁瑣，生成stub更累，不及spring + RMI/hessian處理那么通暢簡明。而且，web service不扶持聚集種類，只能用數(shù)組，不得體。
(###)
