一棠绘、綜述
本文比較了RMI件相，Hessian，WebService等3種通信協(xié)議的在不同的數(shù)據(jù)結(jié)構(gòu)和不同數(shù)據(jù)量時(shí)的傳輸性能氧苍。
1夜矗、Java RMI 為Remote Method Invocation的縮寫，即遠(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ū)ο蟮南⑼ㄐ拧essian的初衷就是支持動(dòng)態(tài)類型般眉，格式緊湊了赵，跨語(yǔ)言Hessian是使用自己的序列化機(jī)制實(shí)現(xiàn)的編組和反編組，其支持的數(shù)據(jù)類型是有限制的甸赃，不支持復(fù)雜的對(duì)象柿汛，可以穿透防火墻。
3埠对、WebService是連接異構(gòu)系統(tǒng)或異構(gòu)語(yǔ)言的首選通信技術(shù)络断，它使用SOAP通訊協(xié)議，是一種輕量級(jí)的獨(dú)立的通訊技術(shù)项玛。SOAP為Simple Object Access Protocol的縮寫貌笨，即簡(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)封裝各種不同類型的數(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ì)非基本類型需要逐個(gè)注冊(cè)序列化和反序列化類碴裙，很麻煩钢悲，生成stub更累灌具，不如spring + RMI/hessian處理那么流暢簡(jiǎn)潔。而且譬巫，web service不支持集合類型咖楣，只能用數(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
