一、综述
本文比拟了RMI，Hessian，Burlap，Httpinvoker，web service等5种通信协议的在不同的数据构造和不同数据量时的传输功能。
RMI是java语言本身供给的长途通信协议，安宁高效，是EJB的基础。但它只能用于JAVA过程之间的通信。
Httpinvoker是SpringFramework供给的长途通信协议，只能用于JAVA过程间的通信，且服务端和客户端定然利用SpringFramework。
Hessian和Burlap是caucho公司供给的开源协议，基于HTTP传输，服务端无须开防火墙端口。协议的规范公布，能够用于任意语言。
Web service是连接异构系统或异构语言的首选协议，它利用SOAP形式通信，能够用于任何语言，现在的众多开发工具对其的扶持也很好。
测验收获揭示，几种协议的通信效率顺次为：
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、直接调用
直接调用的所有耗时都接近0，这解释过程处理几乎未曾花费工夫，登记的全副工夫都是长途调用花费的。
2、RMI调用
与假象的一样，RMI天公单纯是最快的，在几乎所有的情形下，它的耗时都是起码的。尤其是在数据构造混杂，数据量大的情形下，与其他协议的差距尤为显明。
为
了富余施展RMI的功能，另外做了测验类，不利用Spring，用原始的RMI形式（继承UnicastRemoteObject对象）供给服务并长途调
用，与Spring对POJO包装成的RMI举行效率比拟。收获揭示：两者大约持平，Spring供给的服务还稍快些。
开始感受，这是因为Spring的代办缓和存机制比拟壮大，勤俭了对象重新获得的工夫。
3、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无须。
4、Burlap调用
Burlap与Hessian都是caucho公司的开源产品，只不过Hessian批准二进制的措施，而Burlap批准xml的款式。
测验收获揭示，Burlap在数据构造不混杂，数据量中等的情形下，效率还是能够接受的，但万一数据量大，效率会飞快降落。平衡计算，Burlap的调用耗时是RMI的3倍。
我感受，其效率低有双边面的起因，一个是XML数据描写内容太多，同样的数据构造，其传输量要大许多；另一方面，众所周知，对xml的解析是比拟费资源的，尤其对于大数据量情形下更是如此。
5、HttpInvoker调用
HttpInvoker是SpringFramework供给的JAVA长途调用措施，利用java的序列化机制处理对象的传输。从测验收获看，其效率还是能够的，与RMI大约持平。
不过，它只能用于JAVA语言之间的通信，而且，要求客户端和服务端都利用SPRING框架。
另外，HttpInvoker 并未曾穿越实践的验证，现在还未曾找到利用该协议的项目。
6、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不扶持聚集种类，只能用数组，不得体。
Lambda算子5b：How of Y.
(###)
