开发实体EJB增强的性能和开发-J2EEJ2ME教程
转载自：互联网 作者：cd3c.com
您正在看的J2EEJ2ME教程是:开发实体EJB增强的性能和开发。
Enterprise JavaBean (EJB) 是一些应用程序组件，它们实现了 EJB 体系结构规范，并且是 Java 2 Enterprise Edition (J2EE) 平台的一部分。EJB 是开发和部署分布式的、可伸缩的、事务型的、安全的、可移植的、基于组件的商业应用的理想选择。
Enterprise JavaBean (EJB)是一些应用程序组件，它们实现了EJB体系结构规范，并且是Java 2 Enterprise Edition (J2EE) 平台的一部分。EJB是开发和部署分布式的、可伸缩的、事务型的、安全的、可移植的、基于组件的商业应用的理想选择。
基于EJB的商业应用需要一个EJB容器，用于运行时的执行。所有遵从J2EE规范的应用服务器，包括WebLogic 8.1在内，都提供了EJB容器。
EJB体系结构背后的主要动机是关系的分离：它将与应用程序基础设施相关的部分（例如事务处理和安全性）与核心应用程序部分（例如业务逻辑）分离开来。简言之，EJB体系结构通过指定EJB容器与EJB开发者之间职责的区别，从而达到这种关系上的分离。例如，透明地实现事务处理是EJB容器的职责，而实现业务逻辑则应由EJB开发者负责。虽然EJB容器执行任务时可能需要某些线索（hint），但是，比起实际地实现这些与基础设施相关的活动来，提供这类线索（通过基于XML的部署描述符）的代价是非常少的。总之，这种关系分离的策略使得商业应用的开发比其他方式要高效得多。
EJB体系结构规范有4种版本：1.0、1.1、2.0和2.1。事实上，EJB version 1.0已经过时了，而最新版本，即2.1，由于刚刚才出现，所以还没有广泛提供。BEA WebLogic Server 8.1同时支持1.1和2.0这两种版本。我们强烈建议在WebLogic Server 8.1中进行开发时使用EJB version 2.0。
实体bean是一种EJB。除了EJB背后的一般动机外，使用实体bean的特定动机是为持久存储中的业务域（business-domain）实体提供一种驻留在内存中的、可共享的、面向对象的视图。通常，业务域对象就是关系数据库中一个表里面的一行。在本文中，我们讨论了关于在WebLogic Server 8.1环境下Entity EJB的设计、开发和部署的特定问题。至于关于EJB技术的综合教程，我们推荐http://java.sun.com/j2ee上的J2EE教程。
概述
实体bean是设计用来管理关系数据库中的数据的。在BEA WebLogic Server 8.1环境下，Entity EJB的开发包括EJB的设计、生成、打包和部署。
从设计的角度来看，实体bean可以由两条正交轴线来分类：持久性和访问。顺着持久性这条轴线，有两种类型的实体bean：Bean管理的持久性（Bean-managed persistence，BMP）和容器管理的持久性（Container-managed persistence，CMP）。如果是CMP，则EJB容器将管理实体bean的持久性。而对于BMP，则由实体bean的开发者通过指定的Java代码来管理实体bean的持久性。CMP和BMP之间的选择是互斥的。顺着访问这条轴线，又有两种类型的bean：远程的和本地的。远程实体bean提供了定位的透明性，并且可以从不同的Java虚拟机上访问。相反，本地实体bean只能在同一应用服务器内访问。本地和远程之间的选择不是互斥的，因此可以设计具有双重接口的bean。
在EJB体系结构规范中，每个实体EJB组件都是由一组指定的Java类和一组指定的XML部署描述符组成。EJB的打包过程包括将所有指定的EJB Java类文件和XML部署描述符文件打包到一个Java Archive (JAR)文件中。如果实体EJB还要依赖于一些Java助手类文件，那么也可以将这样的类文件包括到EJB JAR文件中，或者将它们单独打包到一个不同的JAR文件中。
EJB的部署可分为两种方式，要么是在BEA WebLogic Server 8.1内直接部署EJB JAR文件以及所依赖的任何JAR文件，要么是首先将EJB jar文件和所有依赖的JAR文件打包到一个企业应用归档（enterprise application archive，EAR）文件内，然后再在WebLogic Server 8.1内部署这个EAR文件。
设计EJB
在设计一个实体时，需要考虑的几个重要选择是：
是设计一个CMP实体bean还是一个BMP实体bean。
是设计一个本地实体bean，还是设计一个远程实体bean，抑或是设计一个双重接口的实体bean。
是设计一个粗粒度（coarse-grained）的实体bean，还是一个细粒度（fine-grained）的实体bean。
是使用数据传输对象，还是使用get和set方法来访问实体EJB中的数据。
下面将讨论在开发实体EJB时要面临的这些设计选择。
CMP与BMP
记住，虽然可能存在一些很合理的例外，但是一般情况下我们强烈推荐使用CMP这种设计。至于为什么要选择CMP，而不是BMP，这里有三大主要原因。
与BMP相比，CMP提供了跨多种不同数据库的可移植性，因为CMP实体bean不包含任何特定于数据库的持久性代码。CMP易于设计、实现和维护。
通常，CMP拥有好于BMP的性能，因为EJB容器将自动生成特定于数据库的代码，并且这些代码将为目标数据库而优化。
CMP通过使用本地接口，使得在相关EJB的网络中程序性地（programmatically）进行导航变得非常容易。
本地接口、远程接口和双重接口
因为CMP通过本地接口管理着实体EJB之间的关系，所以我们强烈建议总是提供一个本地接口。我们认为远程接口需要的时候很少，但是如果仔细评估一下就会证明远程接口也是需要的。所以，我们还是设计一个双重接口吧。
本地接口通过本地客户机提供了对EJB的优化的访问；远程方法调用（remote method invocation，RMI）的语义不要求通过本地客户机、使用本地接口来访问EJB。
远程客户机与EJB容器位于不同的虚拟机上，它需要RMI和远程接口来访问EJB。从理论上讲，单单设计一个本地实体存在着一个明显的缺点，那就是只有在相同应用服务器内的客户机才能访问该实体bean。然而，这只是一个理论上的缺点，因为实际上很少需要从应用服务器之外访问实体EJB。
粗粒度与细粒度
这是一个非常有争议的专题，所以还应根据您个人的经验小心地评价关于此专题的一些不同观点。我们的选择是，实体EJB最常用于表示应用程序业务域中各个实体，所以应该让实体EJB尽量地细粒度，不过也应将设计限定为仅提供一个本地接口。关于这个问题的争论始于EJB体系结构规范1.x版本，当时只能通过一个远程接口来访问实体EJB。建立在EJB 1.x版本基础上的任何反对使用细粒度实体EJB的观点，虽然当时也有合理之处，但是在EJB体系结构规范2.0 中却已不合时宜了，并且最终遭到反对。请谨记：有些专家可能不同意我们的观点，所以我们鼓励您通过实验进行考证，并在此专题上形成自己的观点。
数据传输对象与Get和Set方法
这又是一个有争议的专题。我们的观点如下所述：
在实体EJB的本地接口中暴露CMP持久字段的所有get访问器（accessor）方法。
为不属于实体EJB主键的一部分的每个CMP持久字段创建包装器（wrapper）set方法，并且在实体EJB的本地接口中暴露这些包装器方法。使用这些包装器方法背后的动机是，CMP要求所有持久字段都具有抽象方法setXXX，如果需要在这些setXXX方法内进行任何验证，那么就可以先在包装器方法内完成验证，然后再调用相应的setXXX方法。如果不需要这样的验证，那么省掉包装器方法而直接包括setXXX方法也无不可。
在某些少见的环境下，可能要求实体EJB有一个远程接口，这时可以为每个实体EJB定义一个数据传输对象，将该数据传输对象作为实体EJB的远程接口中的一个参数，暴露其get和set方法。
生成和打包EJB
在EJB体系结构规范中，每个实体EJB组件都由一组指定的Java类和一组指定的XML部署描述符组成：
一个必需的实现实体bean核心功能的bean类。
一个远程接口、本地接口或双重接口，该接口为实体bean提供了适当的客户机视图。
一个远程主接口（home interface
[1] [2] 下一篇
