强烈推荐使用 Hessian/Burlap 作为J2EE分布式系统内部 的 远程服务方案

    在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方案。

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.