EJB 编程模型

EJB 编程模型
2009-2-26 作者： 编辑：齐瑞瑞 点击进入论坛
关键词：编程 模型

　　J2EE 规范定义了六种事务模式： Required 、 RequiresNew 、 Mandatory 、 Supports 、 NotSupported 和 Never 。表 1 概述了每种模式的行为 ― 在现有事务中被调用和不在事务内调用时的行为 ― 并描述了每种模式受哪些类型的 EJB 组件支持。(一些容器可能允许您在选择事务模式时有更多的灵活性，但这种使用要依赖特定于容器的功能，因此不适合跨容器的情况)。

　　表 1. 事务模式

　　事务模式Bean 类型在事务 T 内被调用时的行为在事务外被调用时的行为

　　Required会话、实体、消息驱动在 T 中征用新建事务

　　RequiresNew会话、实体新建事务新建事务

　　Supports会话、消息驱动在 T 中征用不带事务运行

　　Mandatory会话、实体在 T 中征用出错

　　NotSupported会话、消息驱动不带事务运行不带事务运行

　　Never会话、消息驱动出错不带事务运行

　　在只使用容器管理的事务的应用程序中，只有组件调用事务模式为 Required 或 RequiresNew 的 EJB 方法时才启动事务。如果容器创建一个事务作为调用事务性方法的结果，当该方法完成时将关闭该事务。如果方法正常返回，容器将提交事务(除非应用程序已经要求回滚事务)。如果方法通过抛出一个异常退出，容器将回滚事务并传播该异常。如果在现有事务 T 中调用了一个方法，并且事务模式指定应该不带事务运行该方法或者在新事务中运行该方法，那么事务 T 将被暂挂，一直到方法完成，然后先前的事务 T 被恢复。

　　选择一种事务模式

　　那么我们应该为自己的 bean 方法选择哪种模式呢?对于会话 bean 和消息驱动 bean，您通常想使用 Required 来确保每个调用都被作为事务的一部分执行，但仍将允许方法作为一个更大的事务的组件。请小心使用 RequiresNew ;只有在确定自己的方法的行为应该与调用您的方法的行为分开提交时，才应该使用这种模式。 RequiresNew 一般情况下只和与系统中其它对象关系很少或没什么关系的对象(比如日志对象)一起使用。(把 RequiresNew 与日志对象一起使用比较有意义，因为您可能希望在不管外围事务是否提交的情况下提交日志消息。)

　　RequiresNew 使用不当会导致与上面的描述相似的情况，其中，清单 1 中的代码在五个分开的事务而不是一个事务中执行，这样会使应用程序处于不一致状态。

　　对于 CMP(容器管理的持久性，container-managed persistence)实体 bean，通常是希望使用 Required 。 Mandatory 也是一个合理的选项，特别是在最初开发时;这将会警告您实体 bean 方法在事务外被调用这种情况，这时可能会指出一个部署错误。您几乎从不希望把 RequiresNew 和 CMP 实体 bean 一起使用。 NotSupported 和 Never 旨在用于非事务性资源，比如 Java 事务 API(Java Transaction API，JTA)事务中无法征用的外部非事务性系统或事务性系统的适配器。

　　如果 EJB 应用程序设计得当，应用上面的事务模式指导往往会自然地产生规则 4 建议的事务划分。原因是 J2EE 体系架构鼓励把应用程序分解为最小的方便处理的块，并且每个块都作为一个单独的请求被处理( 不管是以 HTTP 请求的形式还是作为在 JMS 队列中排队的消息的结果)。

　　重温隔离

　　在第 1 部分中，我们定义了 隔离(isolation)的意思是：一个事务的影响对与该事务并发执行的其它事务是不可见的;从事务的角度来看，好象事务是连续执行而非并行执行。尽管事务性资源管理器经常可以同时处理许多事务并提供隔离的假象，但有时隔离限制实际上要求把新事务延迟到现有事务完成后才开始。由于完成一个事务至少包括一个同步磁盘 I/O(写到事务日志)，这就会把每秒的事务数限制到接近每秒的写磁盘次数，这对可伸缩性不利。

　　实际上，通常是充分放松隔离需求以允许更多的事务并发执行并使系统响应能够得到改善，使可伸缩性变得更强。几乎所有的数据库都支持标准隔离级别：读未提交的(Read Uncommitted)、读已提交的(Read Committed)、可重复的读(Repeatable Read) 和可串行化的(Serializable)。

　　不幸的是，为容器管理的事务管理隔离目前是在 J2EE 规范的范围之外。但是，许多 J2EE 容器，比如 IBM WebSphere 和 BEA WebLogic，将提供特定于容器的扩展，这些扩展允许您以每方法(per-method)为基础设置事务隔离级别，设置方法与在装配描述符中设置事务模式的方法相同。对于 bean 管理的事务，您可以通过 JDBC 或者其它资源管理器连接设置隔离级别。

　　为阐明隔离级别之间的差异，我们首先把几个并发危险分类 ― 这几种危险是当没有适当地隔离时一个事务可能会干涉另一个事务的情况。下列的所有这些危险都与这种情况( 第二个事务已经启动后第一个事务变得对第二个事务 可见)的结果有关：

　　脏读(Dirty Read)：当一个事务的中间(未提交的)结果对另一个事务可见时就会发生这种情况。

　　不可重复的读(Unrepeatable Read)：当一个事务读取一个数据项，然后重新读取这个数据项并看到不同的值时就是发生了这种情况。

　　虚读(Phantom Read)：当一个事务执行返回多个行的查询，稍后再次执行同一个查询并看到第一次执行该查询没出现的额外行时就是发生了这种情况。

　　四个标准隔离级别与这三个隔离危险相关，如表 2 所示。最低的隔离级别“读未提交的”并不能保护事务不被其它事务更改，但它的速度最快，因为它不需要争夺读锁。最高的隔离级别“可串行化的”与上面给出的隔离的定义相当;每个事务好象都与其它事务的影响完全隔离。

　　表 2. 事务隔离级别

　　隔离级别脏读不可重复的读虚读

　　读未提交的是是是

　　读已提交的否是是

　　可重复的读否否是

　　可串行化的否否否

　　对于大多数数据库，缺省的隔离级别为“读已提交的”，这是个很好的缺省选择，因为它阻止事务在事务中的任何给定的点看到应用程序数据的不一致视图。“读已提交的”是一个很不错的隔离级别，用于大多数典型的短事务，比如获取报表数据或获取要显示给用户的数据的时候(多半是作为 Web 请求的结果)，也用于将新数据插入到数据库的情况。

　　当您需要所有事务间有较高级别的一致性时，使用较高的隔离级别“可重复的读”和“可串行化的”比较合适，比如在清单 1 示例中，您希望从检查余额以确保有足够的资金到您实际取钱期间账户余额一直保持不变;这就要求至少要用“可重复的读”隔离级别。在数据一致性绝对重要的情况下，比如审核记帐数据库以确保一个帐户的所有借方金额和贷方金额的总数等于它目前的余额时，可能还需要防止创建新行。这种情况下就需要使用“可串行化的”隔离级别。

　　最低的隔离级别“读未提交的”很少使用。它适用于您只需要获得近似值，否则查询将导致您不希望的性能开销这种情况。当您想要估计一个变化很快的数量，如定单数或者今天所下定单的总金额(以美元为单位)时一般使用““读未提交的”。

　　因为隔离和可伸缩性之间实际是一种此消彼长的关系，所以您在为事务选择隔离级别时应该小心行事。选择太低的级别对数据比较危险。选择太高的级别可能对性能不利，尽管负载比较轻时可能不会这样。一般来说，数据一致性问题比性能问题更严重。如果拿不准，应该以小心为主，选择一个较高的隔离级别。这就引出了规则 5：

　　规则 5：使用保证数据安全 style="COLOR: #000000" href="http://safe.it168.com/" target=_blank>安全的最低隔离级别，但如果拿不准，请使用“可串行化的”。

　　即使您打算刚开始时以小心为主并希望结果性能可以接受 ―(被称为“拒绝和祈祷(denial and prayer)”的性能管理技术 ― 很可能是最常用的性能策略，尽管大多数开发者都不承认这一点)，在开发组件时考虑隔离需求也是有利的。您应该努力编写能够容忍级别较低但实用的隔离级别的事务，这样，当稍后性能成为问题时，自己就不会陷入困境。因为您需要知道方法正在做什么以及这个方法中隐藏了什么一致性假设来正确设置隔离级别，那么在开发期间仔细说明并发需求和假设，以便在装配应用程序时帮助作出正确的决定也不失为一个好主意。

　　结束语

　　本文中提供的许多指导可能看起来有点互相矛盾，因为象事务划分和隔离这种问题本来就是此消彼长的。我们正在努力平衡安全性(如果我们不关心安全性，那就压根不必用事务了)和我们用来提供安全限度的工具的性能开销。正确的平衡要依赖许多因素，包括与系统故障或当机时间相关的代价或损害以及组织的风险承受能力。创建 Enterprise JavaBean 组件所需的 Java 接口和类的作用。除了对 bean 类本身进行编码外，EJB 开发人员还必须为 bean 定义一个本地接口和一个远程接口。这些接口的实现类通常由容器生成，因此部署 EJB 组件是开发人员和 EJB 容器的合作行为。第二部分还区分了 enterprise bean 的两种主要类型，即会话 bean 和实体 bean，并说明了 EJB 容器和 EJB 服务器之间的关系。

　　enterprise bean 的编程模型的三个关键特征是：面向对象、对象的分布式和使用代理对象。由于此编程模型使用 Java 技术，因此它在本质上就是面向对象的。此模型也是分布式的，这是指 bean 在理论上是位置透明的。根据 Enterprise JavaBeans (EJB) 规范，“一般说来，EJB 类和 EJB 容器的实际位置对客户机是透明的。”在客户机想要访问 EJB 组件时使用代理对象。bean 本身对于客户机是不可访问的，对 bean 方法的访问则由 helper 类提供。

　　接口、委托和代理

　　当 Java 程序员编写一个 Enterprise JavaBeans 组件时，他们所创建的类必须实现一个 EJB 接口，并且它必须包含一个名为 ejbCreate() 的方法。一个 EJB 接口 -- 例如 SessionBean 接口 -- 指定了一些方法，它们包括以下各项：

　　ejbActivate()

　　ejbPassivate()

　　ejbRemove()

　　setSessionContext()

　　ejbActivate() 和 ejbPassivate() 方法通知一个 bean，管理该 bean 的容器组件正在主动和被动之间切换 bean 的状态(这通常是指在内存中还是交换到磁盘)。 ejbRemove() 方法使 bean 知道它已被从容器中删除。 setSessionContext() 方法使 bean 与一个上下文对象相关联，此上下文对象是为了便于 bean 与其容器进行通信。

　　ejbCreate() 方法并不是从零做起创建 enterprise bean 的。当客户机想要创建新的 enterprise bean 时，bean 的容器将调用这个 bean 的类的 newInstance() 方法，来实例化新的 bean 对象。然后容器调用 setSessionContext() 方法来建立上下文对象，用于与 bean 进行通信。最后，容器调用新 bean 中的 ejbCreate() 方法。像 ejbCreate() 、 ejbActivate() 和 ejbPassivate() 这样的方法有时称为 对象生存周期方法，以区别于 业务逻辑方法。

　　当开发人员设计一个新的 EJB 组件时，编写组成 enterprise bean 类的代码本身是不够的。EJB 程序员还必须编写两个将由 helper 类使用的 Java 接口。这些强制性接口必须扩展标准的 EJBObject 和 EJBHome 接口，而这两个接口则都是 java.rmi.Remote marker 接口的扩展。扩展标准 EJBObject 接口的接口被称为 enterprise bean 的 远程接口，它指定在 bean 自身中定义的业务方法。当应用程序调用 enterprise bean 中的业务方法时，应用程序并不访问 bean 本身。实际上，方法调用被传递给实现 EJBObject 接口扩展的那个对象。这种做法称为 委托，它是 EJB 体系结构中的一个设计要点：

　　“客户机从来不直接访问 enterprise bean类的实例。客户机总是使用 enterprise bean 的远程接口来访问enterprise bean 的实例。实现 enterprise bean的远程接口的类由容器提供。此类所实现的分布式对象称为 EJB对象。”( Enterprise JavaBeans Specification1.0)

　　bean 对 EJBObject 接口的扩展称为其 远程接口，而实现远程接口的对象则称为 EJB 对象。

　　enterprise bean 还必须具有本地接口。此接口是标准 EJBHome 接口的扩展。实现 bean 的本地接口的对象称为 本地对象。本地对象包含一个 create() 方法，此方法由应用程序调用，而应用程序则必须创建一个 bean 实例。本地对象中的 create() 方法创建一个新的 EJB 对象。它并不直接创建新的 enterprise bean 实例，因为不允许直接访问 bean。

　　EJB 对象和本地对象充当 bean 对象的代理，因为它们代表 bean 接收方法调用。EJB 对象主要为 bean 业务方法充当代理;本地对象主要为 bean 生存周期方法充当代理。

　　为 EJB 组件使用 create() 方法并不一定要实例化新的 bean。容器确定如何最好地满足创建请求，对于某些类型的 bean，它可以重用现有的实例：

　　“客户机使用会话 bean 本地接口上的 create和 remove 方法。虽然客户机以为它正在控制着 EJB实例的生存周期，但是，是容器在处理 create和 remove调用，而不一定要创建和删除 EJB实例。在客户机和...实例之间不存在固定的映射。容器只是将客户机的工作委托给任何一个方法已经就绪的可用实例而已。”( Enterprise JavaBeans Specification 1.0)

　　创建新的 bean 实例受容器的控制，并可以与客户机发布 create() 方法异步。

　　当创建一个 EJB 组件时，开发人员负责定义 EJBObject 接口和 EJBHome 接口，但是无需编写实现这些接口的类的代码。EJB 容器软件组件自动创建这些类。

　　下面的代码段说明客户机应用程序可能怎样使用称为 CartBean 的 enterprise bean 来进行在线购物：

　　1 CartHome cartHome = javax.rmi.PortableRemoteObject.narrow(

　　2 initialContext.lookup("applications/shopping_cart"), CartHome.class);

　　3 Cart cart = cartHome.create();

　　4 cart.addItem(item29);

　　5 cart.addItem(item67);

　　6 cart.addItem(item91);

　　7 cart.purchase();

　　8 cart.remove();

　　9

　　CartHome 是实现本地接口的类(EJBHome 接口的扩展)。 Cart 是实现远程接口的类(EJBObject 接口的扩展)。当客户机调用应用程序方法(如 addItem() 和 purchase() )时，它们是在 cart 对象上调用的，此对象接着将这些方法的执行委托给 bean 自身。enterprise bean 的功能是通过其代理 EJB 对象(即 cart)来获得的。如果多台客户机同时访问 cart bean，将会发生什么事情呢?Enterprise bean 开发人员无需编写代码来支持并发访问。并发性由 EJB 容器支持。

　　下图说明各 EJB 对象之间的关系：

　　服务器和容器

　　EJB 体系结构包括 EJB 服务器和 EJB 容器两个概念。EJB 服务器充当一种组件执行系统，正如 EJB 白皮书中所述：

　　“Enterprise JavaBeans 规范为每个支持完全可移植性的Java应用程序服务器定义了一个标准模型。任何厂商都可以使用此模型来实现对Enterprise JavaBeans 组件的支持。多种系统(如 TP 监视器、CORBA运行时系统、COM 运行时系统、数据库系统、Web服务器系统或其它基于服务器的运行时系统)都可以调整到能够支持可移植的Enterprise JavaBeans 组件。”(Thomas, Enterprise JavaBeans Technology: Server Component Model for the JavaPlatform)

　　EJB 服务器为使用 EJB 组件的应用程序提供操作环境，并供应所有必需的服务，来支持 EJB 体系结构。打包 EJB 服务器软件并没有预先规定的方式。一种方法是将它作为一项功能增强包括到应用程序服务器中，这就是在 IBM WebSphere Application Server, Advanced Edition, Version 2.0 中采用的方法。

　　EJB 组件并不在 EJB 服务器的顶部直接执行。一个称为 EJB 容器的中间软件组件在 EJB 服务器环境中运行，从而又为这些 bean 自身提供操作环境。EJB 容器对 EJB 应用程序是完全透明的，但是在支持 bean 操作方面起着关键性的作用。

　　为了使 enterprise bean 能充当可重用的软件组件，它们对特定的服务器或平台功能不能有内建的相关性。服务器端功能的几种常见类型已经被从 bean 设计中“分离出去”，而将此功能的责任转移给了容器组件。例如，容器将被用来接管安全性、并发性、事务处理、交换到辅助存储器和其它服务的责任，从而使 bean 免受服务器相关性的制约，并将按业务逻辑来优化，而不是按服务逻辑来优化。

　　EJB 白皮书这样描述容器的作用：

　　“EJB 容器管理部署于其中的 enterprise bean。客户机应用程序并不直接与 enterprise bean进行交互。相反，客户机应用程序通过由容器生成的两个封装接口( EJB Home 接口和 EJB Object 接口)与 enterprise bean进行交互。当客户机使用封装接口调用各种操作时，容器截获每个方法调用，并插入管理服务。”(Thomas, Enterprise JavaBeans Technology: Server Component Model for the Java Platform)

　　可以期望 EJB 容器软件一般都会随 EJB 服务器软件一起提供，尽管规范允许分离这些组件。除了提供对运行时服务(如事务处理和安全性)的访问以外，还期望 EJB 容器包括各种必要工具，来支持 enterprise bean 的安装、操作和管理。例如，需要有工具解释 EJB jar 文件的内容，有工具生成数据库访问，来获得容器提供的持久性，有工具监视正在运行的 bean 的行为，以及实现安全性等。

　　Bean 风格

　　EJB 组件分为两种主要类别 -- 会话 bean和 实体 bean。根据 bean 处理状态、事务和持久性的方式这些类别还可以进一步细分。会话 bean 通常具有以下属性：

　　代表单个客户机执行

　　可以是事务性的

　　可以更新共享数据库中的数据

　　生存期相对较短

　　其生存期通常就是客户机的生存期

　　任何持久性数据都由 bean 管理

　　可以依容器的判断予以删除

　　会在 EJB 服务器失败时被删除

　　实体 bean 通常具有以下属性：

　　代表数据库中的数据

　　是事务性的

　　允许多个用户共同访问

　　可以长期存在

　　持久性数据可以由容器管理

　　在 EJB 服务器失败后能继续生存

　　EJB 规范对会话 bean 和实体 bean 的说明如下：

　　“对于客户机，会话 enterprise bean是一种非持久性的对象，它实现某些在服务器上运行的业务逻辑。想像一个会话对象的一种方式是：会话对象是运行在服务器上的客户机程序的逻辑扩展。会话对象不在多台客户机之间共享。

　　“对于客户机，实体 enterprise bean是一种持久性对象，它代表一个存储在持久性存储器(例如，一个数据库)中的实体的对象视图，或者是一个由现有企业应用程序实现的实体。”( Enterprise JavaBeans Specification 1.0)

　　用一种粗略的说法， 会话 bean 代表这样的操作，它检索或存储数据以满足用户请求;而实体 bean 则代表一种数据集，可以访问这些数据集来满足用户请求。

　　会话 bean

　　最简单的一种 Enterprise JavaBeans 组件就是 无状态的会话 bean。因为这些 bean 没有可以区分它们的状态，所有的实例都是完全相同的。容器管理无状态会话 bean 的生存周期，其方式是通过创建足够数目的此种 bean 来适应客户机工作负荷，并在不需要它们时将其删除。 钝化，即将闲置的 bean 写到磁盘上，不用于无状态的会话。要调用 bean，客户机程序调用本地接口中的 standard create() 方法，尽管此操作不一定导致实例化新的 bean 实例。容器可以选择将客户机请求发送给现有的对象。反之，容器则可以按它的选择创建新的实例，且独立于由客户机发布的 create() 方法。

　　在 EJB 本地对象上发布的 create() 调用返回一个对 EJB 对象的引用，这个 EJB 对象代表 enterprise bean。一旦客户机有了 EJB 对象引用，它就可以将业务方法发布到 EJB 对象上，容器随之会将这些方法委托给 bean 自身。 负责管理会话 bean 的容器组件无需推断会话 bean 是否是无状态的。会话 bean 是无状态的还是有状态的在安装时声明。

　　如果会话 bean 在方法调用之间保留状态信息，则它是 有状态的。通过调用 ejbPassivate() 方法，容器可以依其判断将有状态会话 bean 钝化，或写到辅助存储器中。EJB 规范并不要求容器在钝化 bean 时使用 Java 串行化协议，但是它们必须提供等价的功能。当容器决定将一个非活动的会话 bean 交换回到内存中时，它会取消被动 bean 的串行化，并调用 ejbActivate() 方法。有状态会话 bean 的开发人员负责确保状态数据是可串行化的。在集群的应用程序服务器环境中实现有状态会话 bean 时务必要小心，因为并不是所有的服务器都支持集群的有状态会话 bean 的同步化。

　　有状态会话 bean 可以是事务性的。通过使用 javax.transaction.UserTransaction 接口中的方法，如 begin() 、 commit() 和 rollback() ，bean 可以控制事务;通过实现 javax.ejb.SessionSynchronization 接口，bean 可以接收有关事务状态的通知。EJB 容器无需推断哪些 bean 需要事务支持; UserTransaction 接口仅可用于那些在安装时被标记为事务性的 bean。

　　实体 bean

　　实体 bean 在体系结构上与会话 bean 类似，但它们提供对企业数据的访问，而不是支持用户会话。一个实体 bean 可以支持多个并发用户，而容器则使访问和事务同步化。实体 bean 还具有支持本地对象中的 finder 方法的主键。知道实体 bean 的主键的客户机可以通过调用本地对象上的 findBy PrimaryKey() 方法获得对象引用。与会话 bean 不同，实体 bean 的本地对象除了具有 create 方法外还具有 finder 方法。

　　持久性是实体 bean 的一个基本属性。EJB 规范允许两种形式的实体持久性：bean 管理的持久性和容器管理的持久性。对于代表关系数据库中的数据的实体 bean，bean 对持久性的管理意味着，对数据库访问的调用是直接编写在企业 bean 的方法中的(使用 JDBC 或 SQLJ)。这种方法是直截了当的，但它降低了可移植性。容器对持久性的管理意味着 bean 不受数据库调用的影响。在安装时告知容器有关 bean 数据所需的持久性，而容器负责生成实现持久性的代码。这种方法允许 bean 的可移植性更高，甚至达到持久性可使用不同数据源的程度。然而，此方法要求容器中要有复杂功能。

　　当实体 bean 对象与 EJB 对象相关联时，前者处于 就绪状态;否则将认为它们处于 共享状态。当客户机调用 EJB 对象中的方法时，容器查找关联的实体 bean 的实例(如果存在的话)，或者从共享状态中传送出一个实例。处于就绪状态的实体 bean 可以接收到通过委托从客户机传播给它们的业务方法调用。它们还可以在容器请求时执行 ejbLoad() 和 ejbStore() 方法。load 方法和 store 方法旨在维持实体 bean 和基础数据存储之间数据的一致性。

　　实体 bean 支持多个用户并发地访问数据。EJB 规范声明，维持数据完整性是容器的责任：

　　“enterprise bean开发人员在编写业务方法时无需担心来自多个事务的并发访问。enterprise bean 开发人员在编写方法时可以假定，对于被多个事务同时访问的各个实体bean，将能确保适当的同步化。”( Enterprise JavaBeans Specification 1.0)

　　容器完成这一任务通常是通过锁定数据库中的数据，并使访问串行化，或通过创建实体 bean 的多个实例，并允许在基础数据存储中使用并发控制，这样来管理访问。
相关文章

* EJB 编程模型[图]
* 技术巨人支持新的SOA编程模型
* SIP服务逻辑编程模型
* 模型驱动开发，传统编程方式的终结？[4]
* 模型驱动开发，传统编程方式的终结？[3]
* 模型驱动开发，传统编程方式的终结？[2]
* 模型驱动开发，传统编程方式的终结？[1]
* Windows Vista之受管代码编程模型
* 浅谈AIX环境下的Java性能调优
* Java和.NET互操作：该放弃Web Service吗？
* Seam与JSF的加减法
* 开发自定义JSF组件