【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初学者望而却步了。