一、綜述

本文比較了RMI，Hessian，WebService等3種通信協(xié)議的在不同的數(shù)據(jù)結(jié)構(gòu)和不同數(shù)據(jù)量時(shí)的傳輸性能。

1、Java RMI 為Remote Method Invocation的縮寫(xiě)，即遠(yuǎn)程方法調(diào)用。它是一種機(jī)制，能夠讓在某個(gè) Java 虛擬機(jī)上的對(duì)象調(diào)用另一個(gè) Java 虛擬機(jī)中的對(duì)象上的方法。Java RMI在Java1.1的時(shí)代就已經(jīng)出現(xiàn)，是非常重要的底層技術(shù)，大名鼎鼎的EJB就是建立在RMI基礎(chǔ)之上。它具有穩(wěn)定高效的特點(diǎn)，缺點(diǎn)為只適合于java程序之間的通信，并且只能通過(guò)RMI協(xié)議來(lái)進(jìn)行訪問(wèn)而無(wú)法通過(guò)HTTP協(xié)議訪問(wèn)，而且無(wú)法穿透防火墻。

2、Hessian是caucho公司提供的開(kāi)源協(xié)議，基于HTTP傳輸，服務(wù)端不用開(kāi)防火墻端口。協(xié)議的規(guī)范公開(kāi)，可以用于任意語(yǔ)言。它是一個(gè)輕量級(jí)的remoting on http工具，使用簡(jiǎn)單的方法提供了RMI的功能，因?yàn)椴捎昧硕M(jìn)制RPC協(xié)議，所以它很適合于發(fā)送二進(jìn)制數(shù)據(jù)，主要作面向?qū)ο蟮南⑼ㄐ?。Hessian的初衷就是支持動(dòng)態(tài)類(lèi)型，格式緊湊，跨語(yǔ)言Hessian是使用自己的序列化機(jī)制實(shí)現(xiàn)的編組和反編組，其支持的數(shù)據(jù)類(lèi)型是有限制的，不支持復(fù)雜的對(duì)象，可以穿透防火墻。

3、WebService是連接異構(gòu)系統(tǒng)或異構(gòu)語(yǔ)言的首選通信技術(shù)，它使用SOAP通訊協(xié)議，是一種輕量級(jí)的獨(dú)立的通訊技術(shù)。SOAP為Simple Object Access Protocol的縮寫(xiě)，即簡(jiǎn)單對(duì)象存取協(xié)議，它以XML為基礎(chǔ)。通過(guò)SOAP在Web上提供的軟件服務(wù)，使用WSDL文件進(jìn)行說(shuō)明，并通過(guò)UDDI進(jìn)行注冊(cè)。WSDL 文件是一個(gè) XML 文檔，用于說(shuō)明一組 SOAP 消息以及如何交換這些消息。UDDI是一種根據(jù)描述文檔來(lái)引導(dǎo)系統(tǒng)查找相應(yīng)服務(wù)的機(jī)制，它采用XML格式來(lái)封裝各種不同類(lèi)型的數(shù)據(jù)，并且發(fā)送到注冊(cè)中心或者由注冊(cè)中心來(lái)返回需要的數(shù)據(jù)。

二、結(jié)果分析

1、直接調(diào)用直接調(diào)用的所有毫?xí)r都接近0，這說(shuō)明程序處理幾乎沒(méi)有花費(fèi)時(shí)間，記錄的全部時(shí)間都是遠(yuǎn)程調(diào)用耗費(fèi)的。

2、RMI調(diào)用與設(shè)想的一樣，是最快的。在幾乎所有的情況下，它的毫?xí)r都是最少的。特別是在數(shù)據(jù)結(jié)構(gòu)復(fù)雜，數(shù)據(jù)量大的情況下，與其他協(xié)議相比它的優(yōu)勢(shì)尤為明顯。為了驗(yàn)證RMI的性能，在使用原始的RMI形式（即繼承UnicastRemoteObject對(duì)象）提供服務(wù)并遠(yuǎn)程調(diào)用的情況下，與使用Spring對(duì)POJO包裝成的RMI的情況下進(jìn)行效率對(duì)比。結(jié)果顯示：兩者基本持平，Spring提供的服務(wù)還稍快些。初步認(rèn)為，這是由于Spring的代理和緩存機(jī)制比較強(qiáng)大，節(jié)省了對(duì)象重新獲取的時(shí)間的原因。

3、Hessian調(diào)用caucho公司的resin服務(wù)器號(hào)稱是最快的服務(wù)器，在java領(lǐng)域有一定的知名度。Hessian做為resin的組成部分，其設(shè)計(jì)也非常精簡(jiǎn)高效，實(shí)際運(yùn)行情況也證明了這一點(diǎn)。平均來(lái)看，Hessian較RMI要慢20%左右，但這只是在數(shù)據(jù)量特別大，數(shù)據(jù)結(jié)構(gòu)很復(fù)雜的情況下才能體現(xiàn)出來(lái)，中等或少量數(shù)據(jù)時(shí)，Hessian并不比RMI慢。Hessian的好處是精簡(jiǎn)高效，可以跨語(yǔ)言使用，而且協(xié)議規(guī)范公開(kāi)，我們可以針對(duì)任意語(yǔ)言開(kāi)發(fā)對(duì)其協(xié)議的實(shí)現(xiàn)。目前已有實(shí)現(xiàn)的語(yǔ)言有：java, c++, .net, python, ruby。還沒(méi)有delphi的實(shí)現(xiàn)。另外，Hessian與WEB服務(wù)器結(jié)合非常好，借助WEB服務(wù)器的功能，在處理大量用戶并發(fā)訪問(wèn)時(shí)會(huì)有很大優(yōu)勢(shì)，在資源分配，線程排隊(duì)，異常處理等方面都可以由成熟的WEB服務(wù)器保證。而RMI本身并不提供多線程的服務(wù)器。而且，RMI需要開(kāi)防火墻端口，Hessian不用。

3、web service調(diào)用 ? ? ? 本次測(cè)試選用了apache的AXIS組件作為WEB SERVICE的實(shí)現(xiàn)，AXIS在WEB SERVICE領(lǐng)域相對(duì)成熟老牌。為了僅測(cè)試數(shù)據(jù)傳輸和編碼、解碼的時(shí)間，客戶端和服務(wù)端都使用了緩存，對(duì)象只需實(shí)例化一次。但是，測(cè)試結(jié)果顯示，web service的效率還是要比其他通訊協(xié)議慢10倍。如果考慮到多個(gè)引用指向同一對(duì)象的傳輸情況，web service要落后更多。因?yàn)镽MI，Hessian等協(xié)議都可以傳遞引用，而web service有多少個(gè)引用，就要復(fù)制多少份對(duì)象實(shí)體。Web service傳輸?shù)娜哂嘈畔⑦^(guò)多是其速度慢的原因之一，監(jiān)控發(fā)現(xiàn)，同樣的訪問(wèn)請(qǐng)求，描述相同的數(shù)據(jù)，web service返回的數(shù)據(jù)量是hessian協(xié)議的6.5倍。另外，WEB SERVICE的處理也很毫?xí)r，目前的xml解析器效率普遍不高，處理xml <-> bean很毫資源。從測(cè)試結(jié)果看，異地調(diào)用比本地調(diào)用要快，也從側(cè)面說(shuō)明了其毫?xí)r主要用在編碼和解碼xml文件上。這比冗余信息更為嚴(yán)重，冗余信息占用的只是網(wǎng)絡(luò)帶寬，而每次調(diào)用的資源耗費(fèi)直接影響到服務(wù)器的負(fù)載能力。（MS的工程師曾說(shuō)過(guò)，用WEB SERVICE不能負(fù)載100個(gè)以上的并發(fā)用戶。）測(cè)試過(guò)程中還發(fā)現(xiàn)，web service編碼不甚方便，對(duì)非基本類(lèi)型需要逐個(gè)注冊(cè)序列化和反序列化類(lèi)，很麻煩，生成stub更累，不如spring + RMI/hessian處理那么流暢簡(jiǎn)潔。而且，web service不支持集合類(lèi)型，只能用數(shù)組，不方便。

相關(guān)引用：

http://www.cnblogs.com/yeahwell/p/4684492.html

http://lavasoft.blog.51cto.com/62575/91679/

http://www.cnblogs.com/Jessy/p/3528341.html