【IT168 专稿】今年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已经越来越名不副实了。