Question

回顾一下在15.2.2小节中，在使用RmiProxyFactoryBean访问Spitter服务的客户端代码中，完全不知道这个服务是一个RMI服务。事实上，也根本没有任何迹象表明这个服务是一个远程服务。它只是与SpitterService接口打交道——RMI的所有细节完全包含在Spring配置中这个bean的配置中。好处是客户端不需要了解服务的实现，因此从RMI客户端转到Hessian客户端会变得极其简单，不需要改变任何客户端的Java代码。

坏处是，如果你真的喜欢编写Java代码的话，那么这一节或许让你大失所望。这是因为在客户端代码中，基于RMI的服务与基于Hessian的服务之间唯一的差别在于要使用Spring的HessianProxyFactoryBean来代替RmiProxyFactoryBean。客户端调用基于Hessian的Spitter服务可以用如下的配置声明：

就像基于RMI服务那样，serviceInterface属性指定了这个服务实现的接口。并且，像RmiProxyFactoryBean一样，serviceUrl标识了这个服务的URL。既然Hessian是基于HTTP的，当然我们在这里要设置一个HTTP URL（URL是由我们先前定义的URL映射所决定的）。图15.7展示了客户端以及由HessianProxyFactoryBean所生成的代理之间是如何交互的。

图15.7　HessianProxyFactoryBean和BurlapProxyFactoryBean生成的代理对象负责通过HTTP（Hessian为二进制、Burlap为XML）与远程对象通信

事实证明，把Burlap服务装配进客户端同样也没有太多新意。二者唯一的区别在于，我们要使用BurlapProxyFactoryBean来代替HessianProxyFactoryBean：

尽管我们觉得在RMI、Hessian和Burlap服务之间稍微不同的配置是很无趣的，但是这样的单调恰恰是有好处的。它意味着我们可以很容易在各种Spring所支持的远程调用技术之间进行切换，而不需要重新学习一个全新的模型。一旦我们配置了对RMI服务的引用，把它重新配置为Hessian或Burlap服务也是很轻松的工作。

因为Hessian和Burlap都是基于HTTP的，它们都解决了RMI所头疼的防火墙渗透问题。但是当传递过来的RPC消息中包含序列化对象时，RMI就完胜Hessian和Burlap了。因为Hessian和Burlap都采用了私有的序列化机制，而RMI使用的是Java本身的序列化机制。如果我们的数据模型非常复杂，Hessian/Burlap的序列化模型就可能　　　无法胜任了。

我们还有一个两全其美的解决方案。让我们看一下Spring的HTTP invoker，它基于HTTP提供了RPC（像Hessian/Burlap一样），同时又使用了Java的对象序列化机制（像RMI一样）。