EJB3.0 学习教程（连载） 第一部分

 

第一部分   EJB3介绍:Overview

EJB作为企业级的数据访问/持久化标准在1999年作为J2EE规范的核心规范出现，极大的转变了java企业级开发的模式，为java软件开发提供了一个良好的架构。 EJB从1.0到2.1在J2EE架构中，都是作为一个服务器端的(Server side)的数据访问中间件。开发人员通过EJB标准的API接口来访问操作数据，避免直接用JDBC和Sql操作底层的数据库。

采用EJB架构的目标在于：

• 减轻直接操作底层数据库的工作量
• 为企业级开发引入了面向对象/面向服务的开发架构
• 数据对象生命周期的自动管理
• 分布式能力
• 集成/声明式的安全/事务管理

在旧的EJB模型中（2.1以前）,EJB实现了大部分的目标，但一个巨大的缺陷是原有的模型在试图减轻数据访问工作量的同时也引入了更多的复杂开发需求。例如EJB核心的的Entity Bean必须特定的Home,Remote,Business接口，发布前需要预编译，只能实现单表映射操作，静态的EJB-QL(EJB查询语言）都不能满足简化数据库操作的目标。 EJB 2.1的复杂度，开发成本和性能问题使得EJB在问世4年后仍然等不到广泛的应用。

到了2004年，随着POJO( Plain Old Java Object )模型的出现，动态代码操作，IOC模式等先进，简单实用技术的发展和它们在各种独立产品中的表现，都证明POJO,IOC的技术比原有的EJB 2.1模型更适合作为数据访问中间件，开发的难度和成本远远小于目前的EJB模型，确有更灵活和可扩展。 2004年9月J2EE平台规范集众家所长，推出了跨越式的Java EE 5.0规范，最核心的是全面引入新的基于POJO和IOC技术的EJB3模型。到此，J2EE 5规范( Java EE 5 )成为一个集大成者，纳百家之长，成为java企业开发统一的标准规范。

1.1   EJB 3和EJB 2.1的区别

从整个EJB规范的角度来说，EJB 3和EJB 2.1最大变更在Entity Bean持久化API上。在EJB3中，Entity Bean持久化已经单独作为一个Persistence API规范和其他的EJB部分分离开来。下面我们主要讨论EJB 3和EJB 2.1在持久化API上的区别。

EJB 2.1模型存在复杂度高的缺陷：

• EJB 2.0 模型要求创建多个组件接口并实现多个不必要的回调方法
• 组件接口要求实现 EJBObject 或 EJBLocalObject 以及处理许多不必要的异常
• 基于XML的EJB 2.0 部署描述符比较复杂并容易出错
• 基于 EJB 模型的容器管理持久性在开发和管理方面过于复杂，并且失去了几个基本特性--如使用数据库序列定义主键的标准方法
• EJBQL 语法非常有限，而且是静态的，无法做到运行期间的动态查询
• EJB 2.0 组件并非是真正面向对象的，因为它们在继承和多态性方面的有使用限制
• 开发人员无法在 EJB 容器外部测试 EJB 模块，而在容器内部调试 EJB非常复杂和耗时
• 查找和调用 EJB 2.0 是一项复杂的任务。即使是在应用程序中使用最基本的 EJB 也需要对 JNDI 有一个详细的了解
• 对容器的依赖使得EJB 2.0只能用于服务器组件的开发，无法实现一次编写，四处运行的面向构件的开发

所有这些复杂度和缺陷，都导致EJB 2.0的采用无法真正简化开发并提高生产力。

EJB 3.0 旨在解决以往EJB 2.0 模型的复杂性和提高灵活性，具体体现在：

• 消除了不必要的接口Remote, Home, EJB以及回调方法实现
• 实体Bean采用了POJO模型，一个简单的java bean就可以是一个Entity Bean。无需依赖容器运行和测试
• 全面采用O/R Mapping技术来实现数据库操作
• 实体Bean可以运用在所有需要持久化的应用，不管是客户端还是服务器端。从而真正实现面向构件的开发
• 实体 bean 现在支持继承和多态性
• 灵活丰富的EJB3查询语言
• SQL支持
• 使用元数据批注代替部署描述符，减少复杂配置和提高可维护性
• 将常规 Java 类用作 EJB 并将常规业务接口用于 EJB

1.2    EJB 3中的元数据批注:Annotation

EJB3 规范中引入了元数据批注(Annotation)。Annotation是从J2SE 1.5开始称为java语言的一部分。Annotation并不是一个新的事物，在J2SE 1.5以前，人们已经自行引入了象著名的XDoclet等外挂式的元数据批注方法。而在.NET中，元数据批注也早已经是C#语言的成分了。

在以往，我们都是采用xml作为配置批注，但采用文本的xml配置存在一些缺陷：

• 描述符多，不容易记忆和掌握
• 无法做自动的校验，需要人工排错
• 当系统变大时，大量的xml配置难以管理
• 读取和解析xml配置非常耗时，导致应用启动缓慢，不利于测试和维护
• 做O/R Mapping的时候需要在java文件和xml配置文件之间交替，增大了工作量
• 运行中保存xml配置需要消耗额外的内存

采用元数据可以很好的解决这些问题:

• 描述符大量减少。以往在xml配置中往往需要描述java属性的类型，关系等等。而元数据本身就是java语言，从而省略了大量的描述符
• 编译期校验。错误的批注在编译期间就会报错。
• 元数据批注在java代码中，避免了额外的文件维护工作
• 元数据被编译成java bytecode，消耗小的多内存，读取也非常迅速，往往比xml配置解析快几个数据量级，利于测试和维护