dev2dev 首页 > 资源中心 > 专家Blog > 专家Blog文章
从EJB 3到AJAX
如果您不是去年一整年都在不丹休假，那么您应该早就知道有关AJAX——新的与Web页面进行交互的人机工程技术——的一切。JavaOne 2006大会上的众多展位表明了人们是如此狂热地迷恋AJAX。 我的日常工作是有关Java/J2EE应用程序持久性服务方面的，这似乎与多彩生动的Web页面世界相隔甚远。我只想要演示附带Java Persistence API的 EJB 3.0编程模型的基本使用，以及新的EJB 3.0持久化域模型如何简化J2EE应用程序开发。
与我的项目经理谈过之后，很明显我们还需要一个Web界面来展示EJB 3.0的新特性。在2006年，如果有人想编写Web页面，他就应当考虑AJAX。但是我很快获悉AJAX页面是用JavaScript编写的。所以我的第三个目标是： 基于Java的EJB 3.0服务如何呈现在一个基于JavaScript的Web页面上？
在本次讨论中，我会用一个具体的例子来回答这些问题。该示例基于： ——新的EJB 3.0编程模式 ——实现了Java Persistence API的Kodo Persistence Provider Runtime（4.0版本） ——Direct Web Remoting (DWR)——一种连接Java和JavaScript的服务。
构建该示例的代码库和各种资源可在JavaOne大会期间发布的Weblogic 9.2 Tech Preview中获得。
下图展示了该示例由哪些部分组成以及如何连接。 
我将从持久化域模型开始，详细讲解示例的细节。因为，一个设计良好的域模型是任何应用程序、J2EE或其他应用的基础。
该对象模型表示一个Reviewer（审阅者）评审Item（项目）的场景。 典型的Item可以是Book（书）、Music（音乐）或Movie（电影）。 Reviewer创建零个或更多Review（评审）。 每个Review引用其Reviewer以及被评审的Item。 Item也会引用Artist（艺术家）。 Artist和Reviewer都是Person（人）。 该模型最重要的一点是，其中的所有类都被声明为POJO——pure old Java object。无需像3.0之前的EJB规范那样继承或实现任何合法框架类/接口。事实上，EJB 3.0处理事务对象持久化服务的方法与它的前一版本非常不一样（而且很可能是进行了纠正），您可以为前一版本重新命名（比如说JDO，开个玩笑：）。但在此不讨论这些问题。 首先要对域模型进行什么检查呢？自包含。一个设计良好的模型应该是自包含的，即集合内的域对象应该相互关联，但不与集合外的其他类关联。换句话说，如果我们将这些对象放入一个包中，该包就必须能够不依赖其他任何包而进行编译（当然，可以导入java.util.*或其他核心Java类）。 下一步检查什么？连通性。应该可以从其他任何后续引用直接或间接访问任何模型对象。例如，一个Item不直接引用评审它的Reviewer。但是通过Review可以从Item访问Reviewer。 设计此模型的另一个目的是演示Java Persistence Architecture规范所支持的O-R映射特性，以及Kodo的一些扩展功能。例如，对于许多典型的O-R映射关注点，该模型中都有一个对应于它的特定方面： 如何映射枚举的字段？ ——参见Reviewer中的字段类型Gender。 继承支持哪些不同方法？ ——参见如何在SINGLE_TABLE策略中映射Item－Book－Music－Movie继承层次结构。而Person－Reviewer－Artist是使用另一种TABLE_PER_CLASS策略进行映射的。 如何映射单向的多对一关系？ ——参见Item和Artist。许多Item可以引用同一Artist。Artist（故意）不保存对它所创建的Item的引用。 ——如何保存没有天然持久化功能的java.awt.Image？ ——参见Movie类中的image字段。它使用Kodo（JPA规范的扩展）的外化(externalization)特性。 POJO用@Entity注释来向Persistence Provider运行时表示其支持持久化。也可以用其他O-R映射细节注释POJO字段和关系在数据库中的表示。 @Table(name="ITEM") public class Item extends Serializable 有些人可能会不喜欢带有O-R映射注释的Java类。Java纯化论者可能会说：TABLE名称在我的纯Java类中做什么呢？ 但是如果承认数据比Java应用程序更基本且更持久，那么基于Java的持久化域模型就会成为一个可更新视图，通过该视图可以操纵底层数据库模型。并且因为该试图天生就了解其模型，所以Java类就有了表的注释。 但是，对此存在一些疑问：有一些配置在部署描述符中而不是在Java类中指定表（以及其他任何O-R映射）规范。实际上，一个常见规则是部署描述符总是覆盖注释。 O-R映射规范实际上属于Java Persistence API。这是对顶尖的O-R映射专家集体智慧的全面的标准化概括，这些专家包括Kodo设计者（Patrick Linskey、Abe White）、Toplink设计者(Michael Keith)、Hibernate设计者(Gavin King)以及其他许多人。它使用XML Schema表示，可从 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd获得。
随着讨论的深入，我们将有机会看到更多的O-R映射细节。不过现在我们要使用新的EJB 3.0来描述编程模式。示例的开发顺序是：
- 编写持久化域模型类。
- 使用JPA编写一个作用于模型对象的服务类ReviewService.java（例如，对Item创建新的Review，获得John Lenon演唱的所有duration大于5分钟的Music）。我们将在此上下文中讨论如何使用JPA。
- 使用JPA再编写一个用示例记录填充数据库的服务类SeedDatabase.java。
- 用示例记录填充数据库。
- 在ReviewService.java上编写JUnit测试。
- 针对示例记录进行测试。
- 编写在ReviewService.java上直接调用方法的JSP页面。
- 将各单元都封装到Enterprise Application Archieve (EAR)文件中。
- 将EAR文件部署到Weblogic应用服务器。
- 打开浏览器。转到JSP页面，并再次测试该页面。
这些步骤看起来与以前的几乎相同。重要区别在于，我可以在将应用程序部署到Weblogic服务器之前使用JUnit测试来测试整个应用程序。这一点为什么重要呢？因为它节省了时间。典型的“编写－测试－调试－修改－测试”周期（有或者没有应用容器）为我节省了大量时间。部署好应用程序之后，还能验证其正确性。 我不是说在应用服务器中部署应用程序之后就不涉及测试了。当然还有测试。但是在编译阶段，当验证了模型及其操作的语义正确性之后，基于POJO的新EJB 3.0模型显著缩短了开发周期。部署后测试涉及一组不同的关注点——性能可伸缩性、分布式、安全访问——它们都是基础性的。在目标部署环境中对应用程序行为所进行的测试，不是测试其语义正确性，更多的是检查是否为应用服务器指定了正确的部署描述符。 EJB 3.0编程模型让开发人员关注应用程序的语义，而不是关注应用服务器基础架构。好消息是基于POJO和JPA的EJB 3.0编程模型中所实现的这些关注点的真正分离将使开发周期缩短，并且开发工作也会更为轻松。
但是AJAX呢？在以上的描述中，我很少将JSP页面称为Web页面。或者标题中的AJAX纯粹是一种宣传策略？当然不是。我的下一篇文章将介绍我如何在多彩的AJAX新世界里蹒跚学步，给出此EJB 3.0示例应用程序在Web领域的等效版本。 评论
- 你好，Pinaki，写得很不错。我看了您所提供的代码，尤其是persistence.xml部分，我想知道是否可以在无状态会话bean中使用Entity Manager注入，以及是否可以在容器中使用基于EntityManager的JTA事务？
发表人：rahulbiswas，2006年5月23日，06:34 PM
- 可以注入一个EntityManager。实际上，如果看看运行在Weblogic Tech Preview 9.2中的版本，就会发现其中有3个示例用3种不同方法使用了相同的应用语义：1. 使用运行在RESOURCE_LOCAL事务中的直接JPA； 2. 使用运行在JTA事务中的会话Bean，EM是注入的； 3. 使用由JavaScript应用程序（AJAX样式）调用的直接JPA——没有Xml部分。第一种和第三种都介绍过了，以后我会介绍一下第二种。
发表人：pinaki.poddar，2006年5月23日，08:39 PM
原文出处:http://dev2dev.bea.com/blog/pinaki.poddar/archive/2006/05/from_ejb_30_to.html
作者其它文章
|
