在J2EE分布式系统中，我们需要选取某种远程服务协议，在分布的进程之间进行交互。可供选择的协议 EJB、 基于SOAP的Web Service 这些重量级的，也有像RMI、Socket这种比较原始的。但最近了解到了Caucho公司的 Hessian/Burlap方案，我觉得这种方案才是最合适的，
因为它没有上文所述其他几种方案的缺点，而且，如果把Hessian/Burlap与Spring结合使用，设计者将感到无比的方便。
下面就逐个说说这些“不好的”方案，再介绍Hessian/Burlap方案。
a.
EJB。 这就不用说了，EJB极其笨重，配置会累死人，性能也糟糕。
b.
基于SOAP的Web Service。 有着和EJB类似的缺点。声明一个服务很麻烦，而且用SOAP协议传输数据会浪费大量的带宽，因为SOAP基于XML，而XML中大部分的数据并不一定是业务数据，而仅仅是元数据。
c.
RMI。如果与Spring结合使用，配置不算麻烦。但是其服务接口受到制约（必须继承java.rmi.Remote接口），而且RMI服务只能使用1109端口。
d.
Socket。 这应该是最让程序员放心的协议了，因为程序员想怎么搞就怎么搞。但有两个代价：
i.要做很多底层的、基础性的事情。比如说，程序员不得不手写烦人的Socket客户端和服务端代码，要直接与 Socket、InputStream、OutputStream 等底层类打交道；要手工实现安全性、并发、转码、日志等功能；Socket服务器也要通过一个独立的MAIN程序来启动，而不能放到J2EE服务器产品运营，也就是说利用不了J2EE服务器的监控功能。
ii.使用SOCKET方式交互，需要设计交互的报文规范。这是一件非常累人的工作。报文既要使用统一的方式来组报和解报、又要保证报文不会引起歧义。当远程服务的接口变更时，报文可能要做极大的变更。举个例子，在原来的报文中插入一个字段，其后面的字段位置都要后移，这样的话，组报、解报代码可能都要大改。
e.
Hessian/Burlap。它的优点就是解决了以上几种方案的缺点。
i.
易用性。非常方便，服务不需要继承奇怪的接口，也没有多少配置，只需包装成一个Servet即可。与Spring的注入机制结合使用的话，客户端和服务端都会很舒服。
ii.
性能好。Burlap也是用XML传输数据，但比SOAP简约的多；而Hessian是二进制协议，更加节省带宽。
iii. 它也是
基于Http的，它可以穿透防火墙，其实它也是Web Service的一种协议，
iv.为程序员
免去了底层性、基础性的工作。因为它是一个Servlet，底层性的工作，比如 输入输出流、并发、日志等事情 都可以交给Tomcat之类的、现成的服务器; 有了应用服务器，还可以获得其他的一些功能，比如监控、集群什么的；它还可以配置用户名和密码，安全性的工作也包干了
v.
不用设计报文了。因为服务端的服务是以 JAVA方法 的方式 暴露给客户端的。JAVA方法 很容易作到无歧义，而且改变签名也是件很简单的事情（比如Eclipse就有这种重构功能），这比Socket报文好侍侯多了。
综上所述，真的没有理由不选取 Hessian/Burlap方案。