不难发现，人们对于 EJB 3.0 的新发展方向是多么地兴奋不已。实际上，整个 J2EE 组件套件的目标就是简化开发，我们可以期待着有一天开发、测试和部署企业应用程序将变得更简单。EJB 3.0 始终关注着如何简化开发，并已经调整了其模型，以提供 POJO（普通旧式 Java 对象）类型的持续性，TopLink 十多年来一直为此进行不懈的努力。

该规范领导者 Linda DeMichiel 选择从 TopLink 这样的产品中寻求建议和经验并非偶然。这可以使该规范沿着各种经过证实的流行技术开辟的道路发展，而这实际上已经成为行业中的公认实践。EJB 规范现在可以自豪的宣布，它正在逐步转变为一个实质性并且有用的持续性规范，原因是它符合大多数应用程序的功能。

该规范的制定工作正在逐渐加快，作为新 EJB 模型的强有力支持者，Oracle 正在积极参与该过程。我们不但是主要的技术制定者，而且当前正在准备提供 EJB 3.0 Container 技术的一个预览版。

当意识到预览版通常不适合于将应用程序部署到生产环境中，以及 EJB 3.0 的最终版本将很可能于明年的某个时间发布时，将出现这样一个疑问： 我对所看到的一切感到很高兴，但我现在能做些什么？答案是您可以预先为 EJB 3.0 准备应用程序。当该规范的最终草稿发布时，您希望应用程序处于这样一种状态：即可以轻松地移植到新的持续性标准。更理想的情况是，您希望应用程序已经使用该标准提供的某些特性。本文将介绍如何实现该目标，并提供一些有关特性使用方面的建议，以便您不但可以为 EJB 3.0 做好准备，还可以充分地利用该规范。

第一步是确保体系结构利用与持续性相关的标准和已接受的设计模式。这实际上可能需要对应用程序进行修改，但如果您期望应用程序能够顺利通过测试，那么这样的修改是值得的。尽管使用会话 facades、DAO（数据访问对象）层或服务层始终是好主意，但在这种情况下使用它们并不适合。如果已经使用远程实体构建了应用程序（尽管这并不是通常的做法），则您需要重新设计体系结构。在访问持续性对象之前，应准备好可远程访问的服务层。如果使用了实体，则它们只能为本地实体。

但由于实体还使部署人员可以采用声明方式描述实体的事务和安全要求，因此本地实体并非是最终的目标。EJB 3.0 不允许在实体级设置所有这些属性。相反，实体运行所在的上下文将由调用方确定，因此任何必需的事务或安全上下文应由其包含的 J2EE 组件安装或声明。这将持续性的大部分正交问题与分布式组件模型的剩余部分进行了分隔。

如果您已经是 CMP 用户，则可能要考虑三件事。首先，您迫不及待地要获得新特性并丢弃不必要的接口、bean 代码以及冗长的 XML 部署描述符（一些与以前的实体 bean 开发相关的某些麻烦事物）感到欣喜。已不必分别扩展 EJBObject 和 EJBLocalObject 的远程和本地接口，并且现在某些实体可能（如果它们选择）只实施普通的旧式 Java 接口 (POJI)。

其次，您可能想象着如何能够更轻松地在容器中部署 EJB，甚至根本不部署它们，而是在独立环境中的容器外部测试它们。由于实体是具体的普通旧式 Java 对象 (POJO)，因此您将能够象通常使用 new() 创建 Java 对象那样来创建实体。

最后，您可能想要知道移植某些现有的 2.1 样式 bean 以使用新的 3.0 编程样式到底有多困难。这正是 Oracle 关心的问题之一。实际上，我们坚信 EJB 产品提供的强大的转换策略将成为应用程序在选择其 EJB 3.0 实施时使用的主要标准之一。我们的目标是使该转换尽可能地简单，并且我们正在围绕该目标来规划和开发实施。

大部分新持久性 API 可以从 EntityManager（可以将其注入到会话 bean 中或在 JNDI 中查找）中访问。EntityManager 表示事务持续性上下文，该上下文非常紧密地映射到 TopLink UnitOfWork。在事务结束时脏的由 UnitOfWork 或 EntityManager 管理的对象将写出到数据库。

可以通过对包含 UnitOfWork/Session 产物的代码进行抽象化来避免对应用程序自身进行大范围的修改。这样一来，便可以通过可插拨的方式获取使用的实际会话。定义会话然后允许周围层从外部设置它将类似于 EJB 3.0 Container 采用的相关性注入范例。应用程序中使用的所有资源都应遵循该模式。在 EJB 3.0 标准中，将由应用程序声明资源并随后在运行时注入到 bean 中。

许多 EJB 3.0 特性将可以在 TopLink 长期存在的特性中得到识别。通过使用这些特性，即使 API 尚未完成，您仍将能够获得 EJB 3.0 的功能。

在查询中，您可以立即开始使用 EJB 3.0 特性。TopLink 能够定义和执行指定查询。可以通过静态或动态方式配置查询，以允许通过基于客户端的标准进行及时查询。

EJB 3.0 查询将从 EntityManager 中获取，并可以在其中执行。偶尔需要直接转到 SQL 并从查询中获取对象，这时可以创建一个本地 SQL 查询。TopLink 具有可以完全执行该操作的自定义查询，并且它们将结果集数据映射为对象。

查询语言通常是移植难题的根源，这是因为在不编写实质性或全面转换分析器工具的情况下很难进行自动转换。EJB QL 是一个合理而充分的关系查询语言抽象，并将得益于几个添加到其中的新特性。可以应用现有的 EJB QL，并且更多的 EJB QL 结构和函数将进一步增强查询语言。查询语言不会大范围更改（除非采用其他方式），因此即使查询 API 可能尚未发布，但使用 EJB QL 编写查询将仍具有重要意义。TopLink 支持将 EJB QL 与 POJO 一起使用，从而有助于使应用程序可以将查询移植到其他数据库、其他框架或其他持续性 API。

EJB 2.1 中从未指定真正、自然的继承（而是构建 Java 对象来支持和参与继承）。实际上，仅当供应商未设置障碍时才能实现继承，但定义和管理继承仍很困难。EJB 3.0 中将不存在这种情况。由于具体的 Java 对象能够相互继承，并且不必定义限制继承程度的方法，因此您将能够创建任何范围的实体继承。

当前可以从 TopLink 映射工作台或 JDeveloper、用于映射 Java 对象的 GUI 工具以及在基于 Java 的 API（用于映射对象）中实现同样的灵活性。现在可以生成域模型以遵守适合应用程序的继承策略，而不必等待规范发布。

EJB 3.0 模型中将采用 TopLink 强烈支持的乐观锁定。这对应用程序而言是件好事，这是因为它不但会在正常的 90/10 读/写访问比率下极大提高性能，而且还将实现现代系统所需的各种可伸缩体系结构。这是一个重要的锁定范例，行业中的大量应用程序已经使用它来实现 Web 应用程序所要求的可伸缩性。

用于锁定值以及如何确定、计算和存储它们的 TopLink 选项的灵活性取代了 EJB 3.0 规范中包含的选项。但基本原理比较明显，并可以利用一个简单直接的方法（即对每个乐观锁定对象使用数据库列和对象版本字段）轻松地实现可移植性。

此类锁定还有一个额外的好处，即能够在断开连接的模式下使用对象。在脱机状态下修改数据和关系可以通过以下方法实现：即将数据合并回事务中，并通过乐观锁定值验证已修改的对象是否是过期副本。这与 TopLink 用户在将其对象合并到某个工作单元时所执行的操作正好吻合。

EJB 生命周期回调模型以两种有用的方式得到适应。第一种方式是回调与对象关系映射运行时执行模型的相关性更高，且细粒度事件（如插入到数据库中）将支持采取某些操作来执行审计和其他簿记等任务。第二种方式是非 bean 事件监听器可以注册以处理事件回调。这意味着当您使用已经使用的 TopLink 事件监听器时，将使用 EJB 3.0 实体现在已经包含的模型。

在过去的几年里，TopLink 提供的最明显的支持就是能够将对象数据及其关系映射为关系表。这一直是一个困扰着要编写面向对象的 Java 程序但将其数据存储在关系数据库中的应用程序的一个关键问题。

将对象关系映射的标准化元数据和语意添加到 EJB 3.0 中这一决策是一个重要举措，将使应用程序能够灵活地使用它们的应用程序并在不同的数据库上运行它，甚至可以使用不同的持久性框架执行此操作。对象关系映射标准的第一关将包含用户现在用于映射其域模型的最常用映射，如基本的数据转换、一对一和多对多关系等。后续草稿将添加更多 TopLink 已经提供的“高级”映射，因此随着该规范的不断成熟，它将作为一个可移植的应用程序解决方案更靠近 TopLink（即使它们具有额外的要求）。

在过去的 10 里，TopLink 不断合并其大型客户群的要求并不断改进应用程序持久保存其对象的方法。由于 EJB 3.0 不断对其持久性方法进行现代化以便与大多数应用程序的功能保持一致，因此多年来一直进行基于 POJO 的持久性的 TopLink 客户可以确信标准符合他们的方向。由于 TopLink 模型被当作是用户对其持久性框架满意度的示例，因此可以将各种特性用作接近 EJB 3.0 标准的步骤。换言之，现在要开始实施 EJB 3.0 的应用程序可以使用稳定和经过验证的产品来实现此目的，即使规范可能仍处于初级阶段。

TopLink 完全致力于 EJB 3.0 并帮助客户实现目标。我们不但向现有的 TopLink 客户提供移植帮助，而且还制定计划来帮助基于其他技术的应用程序。请密切关注更多有关如何通过在应用程序中采用 EJB 3.0 而获得好处的文章、研讨会和讲座。

Mike Keith 是 Oracle 的 TopLink 产品设计师以及 EJB 3.0 专家组中的 Oracle 代表。