EJB3.0：是脱胎换骨，还是重蹈覆辙？

开发者在线 Builder.com.cn 更新时间:2008-05-06

今年EJB3.0规范已经正式发布了。Sun非常自信地向业界宣布，这个EJB版本将有效地减轻开发难度，通过使用EJB3.0，可以大大降低开发成本。但也有人批评说，Sun在EJB中加入了很多Java EE 5的新特性，如EJB3.0将使用注释(annotations)来进行配置。这将增加开发人员的学习成本，虽然从表面上是简单了，但实际上并没有明显降低开发难度。还有人批评Sun的EJB3.0的持久层架构抄袭了Hibernate。EJB3.0真的象他们所说的那样是Hibernate的翻版吗?EJB3.0是否能依靠它的新架构和Java EE 5的支持摆脱人们对EJB1.x和EJB2.x的恐惧呢?EJB3.0在未来是否能成为对象持久化的代名词呢?

 

　　EJB:刚刚诞生就被打入冷宫

　　在Java发展史上，曾有过很多重要的时刻。如在上世纪末，也就是在1998年，JSP和EJB的诞生就是一个不同寻常的时刻。JSP在诞生后，就立刻引起了很多开发人员的注意，并很快成为了Web开发的主流。而几乎和它同时诞生的EJB1.0却一直倍受冷落。在EJB1.0诞生后的几年，Sun又推出了EJB2.0规范，不过它的命运也可EJB1.0差不多，还是没有翻身。这其中最大的原因，我想是因为Sun没有兑现它承诺而造成的。

　　Sun在发布J2EE相关规范和产品时承诺，J2EE将会使开发变得更容易，从而会显著降低开发成本。但在J2EE发布时，满心欢喜的人们却发现，被认为是J2EE中最有价值的组成部分:EJB却是如此的复杂。在编写EJB时需要进行大量的配置，而且还需要实现一大堆的接口。这不但没有降低开发难度，反而成为很多开发人员的恶梦。

　　在EJB2.x刚出来的几年，国内有很多程序员盲目跟风，但当时，他们中的大多数都只是停留在EJB的“名词”阶段。而当他们开始熟悉并使用EJB时，却发现并不是象他们想得那样美妙。

　　不知道Sun的EJB设计人员是如何考虑的。本来通过很简单的方法就可以从数据库中得到数据，而EJB却要专门为其修一条一级的高输公路，将本来就不多的数据运了出来，这简直就是多此一举。

　　在取数据时经过这样的周折，它的效率也大受影响。也许Sun当初根本就没考虑过它的效率。

　　实体Bean在EJB2.0后就成为EJB最重要的一部分，但是它的概念重来就没清楚过。如Sun建议将业务逻辑代码放到会话Bean中，也就是说，前端应该直接访问会话Bean。而作为对数据直接封装的实体Bean却提供了远程接口，这也就意味着前端也可以直接访问实体Bean。这就与多程序应用结构不太符合。还有就是实体Bean既然是对数据的原始封装，那为什么要提供事务、安全这些业务逻辑层的功能。更不可思议的是实体Bean既然提供了本地接口，那又为什么不通过本地接口，而要通过JNDI查找呢?这些概念上的混淆使得EJB更加难以使用。

　　近几年非常流行的SOA(Service-Oriented Architecture)模式为企业级应用提供了更好的解决方案。然而SOA中的核心:服务，却和这个自称是企业级的Java Bean的EJB没有什么太大的关系。众所周知，SOA里的服务一般是指Web Services。而实现Web Services的方式很多，如果使用Java实现，一般是使用普通的Java Bean来包装成Web Services。最多也就是使用个无状态的Session Bean。而EJB的其它功能，尤其是强大的实体Bean，却很少使用。这不能不说，EJB已经越来越名不副实。

 

异军突起:欲取EJB而代之

　　虽然EJB过于复杂，使用它的开发人员比较少，这并不等于人们对企业级的服务的需求小。相反，随着企业信息化程度越来越高，对方便易用的企业级服务的需要与日俱增。

　　在EJB规范中，关于实体Bean的描述是最多的。看上去实体Bean的功能十分强大，但实际上并非如此。实体Bean的主要功能是对数据进行包装，从而使数据持久化。但这个EJB中最重要的功能也是最虚弱的。本来很简单的功能Sun却定义了一大堆接口，而且不能通过实体Bean进行SQL级的查询，并且实体Bean必须得依托EJB容器才能使用。这些限制大大降低了实体Bean的使用价值。

　　虽然实体Bean的难以使用让人望而却步，但对数据持久化的需求没有一天停止过。自从在进入二十一世纪以来，有许多类EJB类似但更容易使用的数据持久化组件开始成为开发人员的新宠。这其中比较流行的有Hibernate、JDO和TopLink。

　　在这里Hibernate当仁不让地成为了最耀眼的明星。Hibernate不能不说是一个奇迹，它在不到3年的时间里，从一个不起眼的开源软件成为了今天业界瞩目的主流O/R映射框架，它的创始人Gavin King也一夜成名。而EJB在它诞生后的几年时间里，却骂声不断，它们之间形成了强烈的反差。当然，从技术角度来说，Hibernate的技术并不是最先进的，而Gavin King也不是什么绝顶高手。Hibernate之所以能发展得如此快，主要是因为Hibernate的开发难度比较EJB小，而且Hibernate的使用并不依赖于具体的容器，可以将Hibernate使用在B/S或C/S的任何Java环境上。

　　而今年夏天投票通过的JDO2.0标准从某种程度而言，并不逊色于Hibernate当前的版本，有些功能甚至比Hibernate还要好，例如 JDO支持对类属性的惰性装载，而Hibernate要到3才支持，当前Hibernate仅仅支持类的惰性装载。

　　TopLink是比较古老的O/R映射框架，自从它被Oracle收购后，对Oracle数据库有了更好的支持。但这种框架并不是开源的，而且售价不菲。

　　这几种O/R映射框架大有取代EJB之势，而Sun由于已经有了EJB，也不可能再做一个和这些框架类似的东本和它们竞争。因此，Sun要想扭转EJB的颓势，必须要从EJB下手。而EJB1.x和EJB2.x都以失败而告终，那么EJB的下一个版本EJB3.0又会如何呢，Hibernate的创始人Gavin King的加入会使EJB3.0成为继Hibernate的下一个新宠吗?

 

Sun最后的反击:EJB3.0

　　EJB经过了长达8年的卧薪尝胆，被Sun称为最简单的EJB3.0框架终于在今天正式推出了。也许是Sun意识到了自己的失误，在自定EJB规范时将以前繁琐的部分基本都已经去掉了。EJB3.0看起来就好象新的框架一样(这一点从它的规范就可以看出，EJB3.0的规范文件比EJB2.0规范文件的尺寸小得多)。

　　EJB3.0和Java EE 5几乎是同时发布的，因此，EJB3.0中使用了很多Java EE 5的新特性。如EJB3.0在定义Bean时(包括会话Bean和实体Bean)，不再使用各种各样的接口，而是使用Java EE 5提供的注释(annotations)进行定义，无论什么样的企业级Bean只是一个加了相应注释的简单的Java对象(POJO)。不仅如此，EJB3.0中已经全面使用注释取代了接口。如定义

　　Bean的业务接口、O/R映射信息、资源引用信息等都使用注释进行描述。

　　由于Hibernate的创始人Gavin King加入了EJB小组，负责制定EJB的O/R映射规范。因此，EJB3.0的O/R映射也十分类似Hibernate。这使得熟悉Hibernate的开发人员学习EJB3.0非常容易。这说明EJB3.0正在和Hibernate走向溶合。

　　同时Hibernate也提供了两套API，一套是Hibernate本身的API，另外一套是和EJB3.0兼容的API。也就是说，只要使用Hibernate第二套API，就很容易将其使用Hibernate的程序移植到EJB3.0上。

　　虽然EJB3.0刚刚发布，但已经有很多EJB服务器支持EJB3.0了，这其中跟得最紧的是JBoss，其次WebLogic、WebSphere等也随之跟进。因此，各大厂商还是对EJB3.0非常看好的。

　　自从那些如Struts、Hibernate、Spring等轻量级的框架开始在市面上出现并流行时，很多开发人员开始跟随着这些开源大师的指挥棒的方向前进。EJB已经逐渐从人们的视线中淡出。但随着EJB3.0的问世，又将人们的视线拉了回来。毕竟，EJB出自Sun。如果它也能向Hibernate、JDO一样容易使用，那它是非常有前途的，至少我是这么认为的。现在EJB3.0已经和Hibernate在O/R映射上非常相似了，在未来，EJB3.0也许将成为轻量级框架的一员，让我们拭目以待吧!