EJB3.0能否再现昔日辉煌1

【IT168 专稿】记得第一次接触EJB2.1的时候，做了一个小例子足足用了十多天的时间。的确，EJB2.1存在诸多的缺点，例如：规范复杂、开发难度高、效率低下等等。艾伯特.爱因斯坦曾经说过：“一切都应该尽可能地简单，但是不能更简单。”确实如此，简化一门理论的基本假设，使我们可以专注于真正关键的地方，这正是一直以来对科学真理的追求。企业软件开发同样如此。无论如何由于EJB的复杂性使之在J2EE架构中的表现一直不是很好。EJB大概是J2EE架构中唯一一个没有兑现其能够简单开发并提高生产力的组件。在人们的批评声中，EJB3.0出来了。EJB3.0很好的贯彻了这个原则，这个版本比2.1版本确实简化了好多，主要体现在两个方面。

    创造性的引入元数据注释
    首先说说EJB3.0在EJB2.1基础上推出的最具有创造性的改进——元数据注释吧。众所周知，注释用于生成程序文档技术已经非常成熟、普及了，Java、C＋＋都有相应的注释生成文档的规范，而注释用于标识元数据却十分罕见。Java5（以前叫J2SE1.5或Tiger）中加入了一种新的程序注释工具。通过这个工具你可以自定义注释标记，通过这些自定义标记来注释字段、方法、类等等。这些注释并不会影响程序的语义，但是可以通过工具（编译时或运行时）来解释这些标记并产生附加的内容（比如部署描述文件），或者强制某些必须的运行时行为（比如EJB组件的状态特性）。注释的解析可以通过源文件的解析（比如编译器或这IDE工具）或者使用Java5中的APIs反射机制。注释只能被定义在源代码层。由于所有被提交到EJB3.0草案中的注释标记都有一个运行时的Retention Policy（保持策略），因此会增加类文件占用的存储空间，但这却给容器制造商和工具制造商带来了方便。

    EJB规范组织一个重要的目标是减轻原始代码的数量，并且他们为此给出了一个完美而简介的办法。在EJB2.0时代，开发一个EJB至少需要写三个类文件和一个部署描述符文件，即Bean类文件、远程Home接口文件或者本地Home文件、远程业务接口文件或者本地业务接口文件、部署描述符文件。而在EJB3.0的里，任何类型的企业级Bean只是一个加了适当注释的简单Java对象(POJO)。注释可以用于定义Bean的业务接口、O/R映射信息、资源引用信息，效果与在EJB2.1中定义部署描述符和接口是一样的。在EJB3.0中部署描述符不再是必须的了；home接口也没有了，你也不必实现业务接口（容器可以为你完成这些事情）。
比如，你可以使用@Stateless注释标记类把Java类声明为一个无状态回话bean。对于有状态回话bean来说，@Remove注释可以用来标记一个特定的方法，通过这个注释来说明在调用这个方法之后bean的实例将被清除掉。

    为了减少描述组件的说明信息，规范组织还采纳了由异常进行配置（configuration-by-exception）的手段，意思是你可以为所有的注释提供一个明确的缺省值，这样多数常规信息就可以据此推断得出。通过元数据注释，不需要提供部署文件，减少了开发人员的工作。

    作为一个重量级技术，J2EE的数据持久化标准是实体Bean，而实际应用中受到诟病最多的也是它。实体Bean的性能不太尽人意，这成为它备受争议的一个焦点。再有就是，它功能虽然强大，可是对于易用性来说，实在不敢恭维，写一个最简单的实体Bean，也非得Home接口，远程接口，要再加上2.0以后加入的本地接口，这么林林总总一大堆，足以让Java初学者望而却步了。

  改进的数据持久化模型
    EJB 3.0 对实体Bean进行了全面的革新，以吸引开发人员的注意力。持久性框架（ 如 OracleAS TopLink ）、开放源码的 Hibernate ） 已成为开发 J2EE 应用程序持久性框架的宠儿，而实体Bean由于既复杂又沉重，已不再受欢迎。 EJB3.0采用了一个类似Top Link 和Hibernate 的轻量级持久性模型，以简化容器管理的持久性，而这对开发人员而言无疑很有诱惑力。实体Bean正在作为POJO而重获新生，实体Bean也将不再需要组件接口。现在实体Bean将被视为纯粹的对象，因为它也将支持继承性和多态性。

以下是一个简单的实体Bean的源代码 ：

@Entity public class Employee...{
private Long empNo;
private String empName;
@Id(generate=SEQUENCE) public Long getEmpNo() ...{
return empNo;
}
protected void setEmpNo(Long empNo) ...{
this.empNo = empNo;
}
public String getEmpName() ...{
return EmpName;
}
public void setEmpName(String EmpName)...{
this.EmpName = EmpName;
}
....
}

观察以上代码，可以发现此Bean类是当前 实体Bean的实体类，而不是抽象类。
    EJB QL 中对查询功能进行了若干改进 ，并在实体Bean中支持SQL 查询。提出类似于Hibernate的新Entity Manager API（ Top Link 'Session API 的一个简化版本）用于对实体Bean进行操作，即创建、删除和查找 实体Bean。

    新的实体bean也是一个加了注释的简单Java对象(POJO)。一旦它被Entity Manager访问它就成为了一个持久化对象，并且成为了持久化上下文（context）的一部分。一个持久化上下文与一个事务上下文是松耦合的；严格的讲，它隐含的与一个事务会话共存。实体关系也是通过注释来定义的，O/R映射也是，并提供几种不同的数据库规范操作，在EJB2.1中这些要通过开发人员自己的设计模式或者其它技术来完成的（比如，自增长主键策略）。

[size=small]    总结[/size]
    EJB技术正在像其它辉煌过的技术一样走到了一个关口。2000年以前这项技术充满了传奇色彩，被大批企业不假思索地接受。然而理想毕竟是理想，经过了几年的发展，技术人员对EJB的复杂性感到不厌其烦，对EJB的怀疑在蔓延和扩大。然而，最新发布的EJB3.0又给开发人员带来了信心，EJB3.0种废除了繁琐的部署描述和复杂的接口，努力减轻开发复杂性；提出了新的持久化模型，改善了EJB的效率。这些新的特点能不能帮助EJB技术重新赢得企业的认可，重现昔日的辉煌呢？我们拭目以待。