RMI、Hessian、Burlap、Httpinvoker、WebService的比较

一、综述 
本文比较了RMI、Hessian、Burlap、Httpinvoker、WebService5这种通讯协议的在不同的数据结构和不同数据量时的传输性能。 
RMI是java语言本身提供的远程通讯协议，稳定高效，是EJB的基础。但它只能用于JAVA程序之间的通讯。 
Hessian和Burlap是caucho公司提供的开源协议，基于HTTP传输，服务端不用开防火墙端口。协议的规范公开，可以用于任意语言。 
Httpinvoker是SpringFramework提供的远程通讯协议，只能用于JAVA程序间的通讯，且服务端和客户端必须使用SpringFramework。 
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不支持集合类型，只能用数组，不方便。

【2】Java远程调用方法性能比较
　现在，Java远程调用方法很多，各种方法的优缺点网络上也有很多的参考文章，这次我对几个典型的Java远程调用方法做了一个简单的性能分析比较，可供大家参考。
　　测试环境
　　CPU：奔腾双核 T4500，内存：DDR3-1067 2G，Web容器：Tomcat6.0.33，操作系统：WinXP-sp3
　　测试项目
　　①RMI:用Spring3集成发布。
　　②hessian：用Spring3集成发布到Tomcat容器。
　　③Java6 WebService：使用Java6原生WebService和注解，直接用Endpoint.publish发布服务。
　　④CXF：用Spring3集成发布到Tomcat容器。
　　测试结果

　　说明：以上测试虽不是非常的精确，但基本能说明一定的问题。每项案例的服务端方法，都是简单方法，接收客户端传递的一个String类型参数，并打印到console。每轮测试取三次时间的平均值。所有单线程访问测试全部完成并正常处理请求，没有请求拒绝情况发生。而并发访问测试，除hessian中途抛异常无法完成，其余均正常完成测试。
　　结论：
　　RMI的性能最高，这已是公认，RMI底层基于Java远程方法协议(JRMP)和对象序列化技术，而JRMP是直接基于TCP/IP协议的封装，在网络上传输2 byte的有效数据，对于TCP而言，总共有478 byte被额外传输，而对于RMI, 1645byte被额外传输。可见RMI的效率还是相当不错的。JavaEE标准的EJB就是基于RMI的调用。
　　hessian是一个轻量级的remoting on http框架。Hessian没有采用WebService标准的SOAP协议，而是自己实现了一种二进制RPC(Remote Procedure Call Protocol，远程过程调用协议)协议。Hessian的设计理念就是简单高效，使用 Hessian 传输数据量比Soap协议要小很多。这也是为什么Hessian的性能要高于WebService。但是，尽管它再简单高效，它始终是基于Http协议上封装的，所以还是比Java的RMI效率要差一些。我看过其他的一些研究测试报告称Hessian在传输少量对象时，比RMI还要快速高效，但传输数据结构复杂的对象或大量数据对象时，较RMI要慢20%左右。这个结论在我的测试中还真没有发现，也许与测试环境或方法有关系吧。
　　Java6WebService 和 CXF的性能应该说是基本同级别，前者略高于后者。众所周知WebService是基于Soap协议实现的，而Soap协议是在Http协议基础上的 XML定义和封装。所有的请求和响应都要被转化成符合SOAP标准的XML格式。显然这直接会导致效率的降低。
　　XML格式的协议是一种易读易理解的协议，但并不高效。解析和组装XML协议数据流都需要耗费系统的处理时间，所以，WebService的性能不如 Hessian。这里要说一下的是Java6原生的WebService，开发起来非常方便，而且无需额外引入一大堆的Jar包。性能又强于CXF，至于 Axis2和Axis1就更不用说，已经有很多测试表明CXF的性能是Axis2的2倍以上，是Axis1的2-6倍。
　　那么既然RMI性能那么好，为什么我们需要那么多其他的远程调用方式呢?这个问题又引发到了一个原始的真理。越原始越底层的技术效率就越高，但局限性也就越大。RMI是Java的特性，那么它必须基于JVM运行，也就是说RMI无法跨语言运行。而WebService就不同了，Soap是基于标准 Http协议的，是一种与语言无关的字符级协议，所以它可以更好的实现异构系统的通信。这在我们现实环境中是非常有用的，相信大家还是 WebService用的比较多点吧。
不足：这次的测试，还是存在很多不足之处。
【3】远程调用服务池或者服务工厂
在现代 J2EE 企业应用系统中，存在着 Hessian 、 HttpInvoker 、 XFire 、 Axis 等多种形式的远程调用技术。尽管有 Spring 等框架对这些技术进行了封装，降低了使用的复杂度，但对普通程序员而言仍是复杂的——至少需要要掌握这些技术的基础知识。
无论使用那种技术，其基本原理都是一样的：服务端生成骨架，对外暴露服务；客户端生成服务代理，访问调用服务。通常情况下，生成服务代理的代价比较高昂，这也是我们第一次访问远程服务速度比较慢的原因，为每个请求生成新的服务代理恐怕不是我们所期望的。更何况，如果采用这种方式，就要在代码里针对各种不同的技术（如 XFire 、 HttpInvoker ）编写不同的服务生成和调用的处理代码。不仅麻烦，而且容易出错。我想，没有人愿意去直接操作各种框架技术的底层代码，这并不是一个好注意！

作为一种替代方案，我们设计了一个“服务池”的功能，或者说“服务工厂”更贴切一点。先看下面这张类图：

如上图所示，针对 HttpInvoker 、 XFire 、 Hessian 等各种远程调用技术，抽象出一个“远程服务池”（服务工厂）既 RemoteServicePool 接口。该接口提供了获取服务及一些其他的辅助功能，并针对 HttpInvoker 、 XFire 、 Hessian 等不同技术提供了相应的具体实现。采用这种方式，开发人员只需在代码中“注入” RemoteServicePool ，并以统一的方式（如 getService() ）获取实际的服务，只是针对不同技术在配置上有些须差异而已。该技术的原理非常简单，在应用启动之前把所有存在的服务提供者提供的服务都配置好，并为它们分配一个唯一的 ID 。应用启动之后，框架会自动生成和这些地址相对应的服务代理（ ServiceProxy ），这些代理已经是可用的服务，服务获取的细节被完全屏蔽掉，开发者只要知道如何从 RemoteServicePool 中获取服务就可以了。看一下服务池的接口定义：
java 代码
1.
9.
10. public interface RemoteServicePool {
11.
12.
26.
27. Object getService(String serviceId);
28.
29. }

xml 代码
1. <bean id="userServicePool" class="com. tonysoft .common.XFireRemoteServicePool">
2. <property name="serviceInterface">
3. <value>com. tonysoft .demo.service.UserServicevalue>
4. property>
5. <property name="serviceUrls">
6. <map>
7. <entry key=" server 1 ">
8. <value>http://localhost:8080/server1/service/userService?WSDLvalue>
9. entry>
10. <entry key="server2">
11. <value>http://localhost:8080/server2/service/userService?WSDLvalue>
12. entry>
13. map> J2EE 企业应用系统中，存在着 Hessian 、 HttpInvoker 、 XFire 、 Axis 等多种形式的远程调用技术。尽管有 Spring 等框架对这些技术进行了封装，降低了使用的复杂度，但对普通程序员而言仍是复杂的——至少需要要掌握这些技术的基础知识。
14. property> 接下来看看如何配置服务：
15. bean>
最后再来看一下访问服务的代码：
java 代码
1.
2. public RemoteServicePool userServicePool ;
3.
6.
7. public void testAddUser() {
8.
9. UserService userService = null ;
10. try {
11. userService =(UserService) userServicePool .getService("server2");
12. } catch (Exception e){
13. throw new RuntimeException( " 获取服务失败，失败原因：" + e);
14. }
15.
16. OperateResult result = userService .addUser( new User( "daodao" , " 技术部" ));
17.
18. assertEquals(result.isSuccess(), true );
19.
20. }
该方案还为“双向关联”的系统服务提供了一个很好解决办法。看下面一张图：

如图，系统 B 和系统 C 都调用系统 A 进行付款操作；同时系统 A 要用远程服务向系统 B 或系统 C 进行认证操作，认证操作的接口（契约）都是一样的，业务逻辑可能有所差异。在这种情况下，配置在系统 A 中的认证服务就比较麻烦，因为要根据不同的系统调用认证服务，既从 B 过来的请求要访问 B 的认证服务，从 C 过来的请求要访问 C 的认证服务。用服务池可以很好的解决这个问题，把两个系统（ B 、 C ）提供的认证服务地址都配置在同一个服务池中，根据不同的 ID （如 B 、 C ）来决定使用那个系统的服务。
ServiceResportApplication.rar
描述:
下载
文件名: ServiceResportApplication.rar
文件大小: 49 KB
下载过的: 文件被下载或查看 104 次
尽管服务池解决了一些问题，在某种程度上降低了复杂度，但仍存在如下一些问题：
服务的运行期动态注册
服务的自动注入（ IoC ）
透明化服务 ID 的传递

在服务池（ ServicePool ）概念的基础上进行扩展，我们得出了如下的系统模型：

在核心位置上是一个服务中心资源库（ ServiceRepository ），存储了系统中用到的所有的远程服务。服务采取动态注册的机制，由对外提供的服务注册器（ ServiceRegister ）提供服务注册功能。外部系统可以实现该接口向资源中心注册服务。提供了一个启动时运行的注册器，可以把静态配置在系统中的服务都注册进来。

服务的生成、管理等均由服务中心自己维护，委托服务代理生成器（ ServiceProxyGenerator ）完成服务的创建。可以针对现有的远程调用方式，如 XFire,HttpInvoker,Hessian 等创建服务代理，也可以针对自己定义的远程调用方式创建服务代理，由 CustomServiceProxyGenerator 完成该功能。
一个服务模型包括 5 个因素：
服务接口 serviceClass
服务 ID serviceId
服务类型 serviceType
服务地址 serviceUrl
附加属性 props
查找一个服务需要两个因素，一个是服务接口，另一个是服务 ID 。这两个因素共同决定了一个服务，既服务中心内部的“服务 ID ”。通过这种方式，可以允许存在多个 ID 相同但接口不同的服务，也可以存在多个接口相同但 ID 不同的服务。

服务 ID 的获取是系统中一个关键的功能，这部分对程序员来说应该是透明的，由系统自己维护。相应的提供了一个服务 ID 提供者 (ServiceIdProvider) 接口，由实现该接口的子类完成服务 ID 获取功能（这是比较关键的地方，需要特殊考虑）。

对于程序员来说，使用服务中心里的服务再也不能比这样再简单了！看看配置：
xml 代码

1. < bean id = "helloHttpInvokerService" parent = "abstractServiceProxyFactory" >
2. < property name = "serviceInterface" >
3. < value > com.tonysoft.common.service.repository.example.HelloHttpInvoker value >
4. property >
5. bean >
再看如何使用这个 bean ：
1. private HelloHttpInvoker helloHttpInvokerService ;
2. public void testHttpInvoker() {
3. assertNotNull( "helloHttpInvokerService can't be null !" , helloHttpInvokerService );
4. assertEquals ( "Hello , HttpInvoker !" , helloHttpInvokerService .sayHello());
5. }
6.
10.
11. public void setHelloHttpInvokerService(HelloHttpInvoker helloHttpInvokerService) {
12. this . helloHttpInvokerService = helloHttpInvokerService;
13. }

就是这样的简单！ Spring 会把这个 bean 自动注入到程序中，可以象使用其他任何 bean 一样使用它！程序员完全不用关心该服务由谁提供、采用什么技术，他只要知道系统中存在这样一个服务就 OK 了。该技术彻底向程序员屏蔽了底层技术的实现细节，以统一的方式访问任何形式的远程服务。至于服务是如何生成、如何配置的将在后面叙述。

服务（ Service Bean ）是如何实现自动注入（ IoC ）的呢？
注意到上面配置的 bean 都继承了“ abstractServiceProxyFactory ”，它是一个工厂 bean ，负责根据给定的接口类型，到服务中心（ ServiceRepository ）查找服务，并生成服务代理。我们来看一下它的核心代码：
java 代码

1.
15. public class ServiceProxyFactory implements FactoryBean {
16.
17.
18. private ServiceRepository serviceRepository ;
19.
20.
21. private ServiceIdProvider serviceIdProvider ;
22.
23. private Class serviceInterface ;
24.
27. public Object getObject() throws Exception {
28. return ProxyFactory.getProxy(getObjectType(), new ServiceProxyInterceptor());
29. // return serviceRepository.getService(serviceInterface, serviceIdProvider.getCurrentServiceId());
30. }
31.
34. public Class getObjectType() {
35. return serviceInterface ;
36. }
37.
40. public boolean isSingleton() {
41. return true ;
42. }
43.
46. private class ServiceProxyInterceptor implements MethodInterceptor {
47.
50. public Object invoke(MethodInvocation invocation) throws Throwable {
51. Method method = invocation.getMethod();
52. Object[] args = invocation.getArguments();
53. Object client = getClient();
54. return method.invoke(client, args);
55. }
56. private Object getClient() {
57. try {
58. return serviceRepository .getService( serviceInterface , serviceIdProvider .getCurrentServiceId());
59. } catch (ServiceException e) {
60. // TODO
61. e.printStackTrace();
62. return null ;
63. }
64. }
65. }
66. // ---- 容器自动注入 ----
67. ••••••

真正的魅力就在这个地方。根据服务接口类型和服务 ID ，从服务中心获取特定的服务。服务接口是配置好的， 而服务 ID 则在运行时才能确定，根据不同的应用、不同的策略提供不同的 ServiceIdProvider 。其中用到了 Spring 的 FactoryBean 和拦截器，至于为什么要在这里使用拦截器，可以参考 Spring 框架的源码。

服务代理生成器（ ServiceProxyGenerator ）也是一个值得一提的地方，我们先看一下它的接口：

1.
6. public interface ServiceProxyGenerator {
7.
8.
20. Object getService(Class serviceClass, String serviceUrl, Properties props) throws Exception;
21. }
22.
23.
24. public void registService(ServiceModel serviceModel) throws ServiceException {
25. ••••••
26. String key = serviceModel.getServiceId() + KEY_SPAR
27. + serviceModel.getServiceClass().getName();
28. if ( serviceNames .contains(key)) {
29. throw new ServiceRegistException( "service is exist!" );
30. }
31. Object proxy = null ;
32. try {
33. ServiceProxyGenerator proxyGenerator = (ServiceProxyGenerator) beanFactory
34. .getBean(serviceModel.getServiceType() + PROXY_GENERATOR_END );
35. proxy = proxyGenerator.getService(serviceModel.getServiceClass(), serviceModel
36. .getServiceUrl(), serviceModel.getProps());
37. } catch (Exception e) {
38. throw new ServiceRegistException( "can't regist service !" , e);
39. }
40. if (proxy != null ) {
41. serviceNames .add(key);
42. serviceContainer .put(key, proxy);
43. } else {
44. throw new ServiceRegistException( "fail to regist service !" );
45. }
46. }

上面做特殊标记的代码就是应用服务代理生成器的地方，这里我们用到了 Spring 的 bean 工厂，根据注册服务的类型（ xfire,httpinvoker,hessian 等）到 Spring 容器里查找相应的生成器，并生成指定类型的服务。看下面配置的几个服务代理生成器：
xml 代码

1. <!-- XFire 类型服务代理生成器 -->
2. < bean id = "xfire_generator" class = "com.tonysoft.common.service.repository.generator.XFireServiceProxyGenerator" lazy-init = "true" >
3. < property name = "serviceFactory" >
4. < ref bean = "xfire.serviceFactory" />
5. property >
6. bean >
7.
8. <!-- Hessian 类型服务代理生成器 -->
9. < bean id = "hessian_generator" class = "com.tonysoft.common.service.repository.generator.HessianServiceProxyGenerator" lazy-init = "true" >
10. bean >
11.
12. <!-- HttpInvoker 类型服务代理生成器 -->
13. < bean id = "httpinvoker_generator" class = "com.tonysoft.common.service.repository.generator.HttpInvokeServiceProxyGenerator" lazy-init = "true" >
14. bean >
15.
16. <!-- 自定义 类型服务代理生成器 -->
17. < bean id = "custom_generator" class = "com.tonysoft.common.service.repository.generator.CustomServiceProxyGenerator" lazy-init = "true" >
18. bean >
19.
20. <!-- 服务中心（资源库） -->
21. < bean id = "serviceRepository" class = "com.tonysoft.common.service.repository.DefaultServiceRepository" >
22. bean >
23.
24. <!-- 服务 ID 提供者 -->
25. < bean id = "serviceIdProvider" class = "com.tonysoft.common.service.repository.provider.DefaultServiceIdProvider" >
26. bean >
27. <!-- 所有远程服务的基础类 -->
28. < bean id = "abstractServiceProxyFactory" class = "com.tonysoft.common.service.repository.ServiceProxyFactory" abstract = "true" >
29. bean >

简单看一下 HttpInvoker 类型服务代理生成器的代码：
java 代码

1. public class HttpInvokeServiceProxyGenerator implements ServiceProxyGenerator {
2.
3.
4. private HttpInvokerProxyFactoryBean httpInvokerFactory = new HttpInvokerProxyFactoryBean();
5.
9. public Object getService(Class serviceClass, String serviceUrl, Properties props) {
10. // Todo initial httpInvokerFactory with props
11. httpInvokerFactory .setServiceInterface(serviceClass);
12.
13. httpInvokerFactory .setServiceUrl(serviceUrl);
14.
15. // must invoke this method
16. httpInvokerFactory .afterPropertiesSet();
17.
18. return httpInvokerFactory .getObject();
19.
20. }
21.
22. }
是的，正如你所看到的一样，我们这里把真正生成服务代理的任务交给了 Spring 的 HttpInvokerProxyFactoryBean 来完成。

提供在初始化时注册的静态服务功能，配制如下：
1. <!-- 初始化时注册的静态服务 -->
2. < bean id = "bootupServiceRegister" class = "com.tonysoft.common.service.repository.register.BootupServiceRegister" lazy-init = "false" >
3. < property name = "services" >
4. < list >
5. < bean class = "com.tonysoft.common.service.repository.ServiceModel" >
6. < property name = "serviceClass" >< value > com.tonysoft.common.service.repository.example.HelloHttpInvoker value > property >
7. < property name = "serviceId" >< value > default value > property >
8. < property name = "serviceType" >< value > httpinvoker value > property >
9. < property name = "serviceUrl" >< value >http://localhost:8080/serviceRepositoryApplication...voker/helloHttpInvoker.service value > property >
10. < property name = "props" >
11. < props > props >
12. property >
13. bean >
14. < bean class = "com.tonysoft.common.service.repository.ServiceModel" >
15. < property name = "serviceClass" >< value > com.tonysoft.common.service.repository.example.HelloXFire value > property >
16. < property name = "serviceId" >< value > default value > property >
17. < property name = "serviceType" >< value > xfire value > property >
18. < property name = "serviceUrl" >< value >http://localhost:8080/serviceRepositoryApplication.../xfire/helloXFire.service?WSDL value > property >
19. < property name = "props" >
20. < props > props >
21. property >
22. bean >
23. list >
24. property >
25. bean >