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

今年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的下一个新宠吗?