EJB

 

EJB是sun的服务器端组件模型，最大的用处是部署分布式应用程序当然,还有许多方式可以实现分布式应用，类似微软的.net技术。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB (Enterprise JavaBean)是J2EE的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。 在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。

目录

EJB简介

1. 一.什么是 EJB?
2. 二.Sun 对 EJB 的期望
3. 三.为什么选择 EJB?
4. 四.EJB 架构
5. 五. 简化的编程模型

EJB3.0的介绍

1. 开始
2. 背景
3. 概览

EJB注释

1. 新的持久化模型
2. 无状态会话bean
3. 有状态会话bean
4. 消息驱动Bean
5. 实体Bean
6. 实体关联
7. O/R映射
8. 客户端程序模型
9. EJB QL
10. 支持where子句的嵌套子查询
11. 多样性
12. 查看复制到剪切板打印

EJB文件处理模式

与其他规范的关联

关于EJB3.1

结束语

EJB简介

1. 一.什么是 EJB?
2. 二.Sun 对 EJB 的期望
3. 三.为什么选择 EJB?
4. 四.EJB 架构
5. 五. 简化的编程模型

EJB3.0的介绍

1. 开始
2. 背景
3. 概览

EJB注释

1. 新的持久化模型
2. 无状态会话bean
3. 有状态会话bean
4. 消息驱动Bean
5. 实体Bean
6. 实体关联
7. O/R映射
8. 客户端程序模型
9. EJB QL
10. 支持where子句的嵌套子查询
11. 多样性
12. 查看复制到剪切板打印

EJB文件处理模式

与其他规范的关联

关于EJB3.1

结束语

展开

编辑本段EJB简介

　　1.Session Bean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当 客户端请求时， 容器就会选择一个Session

  

EJB

Bean来为客户端服务。Session Bean可以直接访问 数据库，但更多时候，它会通过Entity Bean实现数据访问。

　　2.Entity Bean是域模型 对象，用于实现O/R映射，负责将数据库中的表记录映射为内存中的Entity对象，事实上，创建一个Entity Bean对象相当于新建一条记录，删除一个Entity Bean会同时从数据库中删除对应记录，修改一个Entity Bean时，容器会自动将Entity Bean的状态和数据库同步。

　　3.MessageDriven Bean是EJB2.0中引入的新的企业Bean，它基于JMS 消息，只能接收客户端发送的 JMS消息然后处理。 MDB实际上是一个异步的无状态Session Bean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。

　　EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品.EJB是BEANS,BEANS是什么概念,那就是得有一个容纳她,让她可劲造腾的地方,就是得有容器.EJB必须生存在EJB容器中.这个容器可是功能强大之极!她首先要包装你BEAN,EJB的客户程序实际上从来就不和你编写的EJB直接打交道,他们之间是通过LOCAL/REMOTE接口来发生关系的.它负责你的BEAN的所有的吃喝拉撒睡,比如BEAN的持续化,安全性,事务管理...

一.什么是 EJB?

　　一个技术规范：EJB 从技术上而言不是一种"产品"

  

EJB

EJB 是一种标准描述了构建应用组件要解决的:

　　可扩展 (Scalable)

　　分布式 (Distributed)

　　事务处理 (Transactional)

　　数据存储 (Persistent)

　　安全性 (Secure)

二.Sun 对 EJB 的期望

　　提供一个标准的分布的、基于 OO 的组件架构

　　屏蔽复杂的系统级功能 需求

　　Write once, run anywhere

　　与非 Java 应用之间的互操作能力

　　兼容 CORBA 标准

三.为什么选择 EJB?

　　EJB 服务器完成"繁杂"的工作：应用开发人员关注于业务逻辑的实现而不是底层的实现机制(类似于 4GL 语言设计的目标)

　　支持事务处理

　　多个业务操作同时成功，或全部失败

　　可以通过在代码外的描述来定义事务处理级别

  

EJB

可扩展性

　　EJB 可以根据您应用的增长而扩展

　　EJB 服务器往往还提供了负载均衡和

　　安全性：由 EJB 服务器提供资源的访问权限控制

四.EJB 架构

　　为了满足架构的目标，规范中描述了

　　服务器 (Server)

　　容器 (Container)

　　类 (Class) 和实例 (Instance)

　　Home 和 Remote 接口

　　客户端 (Client)

五. 简化的编程模型

　　关注于业务逻辑实现：EJB 负责生命周期 (lifecycle), 数据存储 (persistence), 事务处理语义 (transactional semantic), 安全(security), ...

　　通用的编程模型：各种服务的高层 API

　　Java 是其编程语言

　　EJB( 业务逻辑代码 ) 表示了与特定商业领域（例如银行、零售等行业）相适应的逻辑。它由

　　运行在业务逻辑层的 enterprise bean 处理。一个 enterprise bean 可以从客户端接受数据，对

　　它进行处理，并将其发送到 企业信息系统层以作存储；同时它也可以从存储器获取数据，

　　处理后将其发送到客户端 应用程序。

　　有三种类型的 enterprise beans：session beans、entity beans 和 message-driven beans。

　　Session bean 描述了与客户端的一个短暂的会话。当客户端的执行完成后，session bean 和

　　它的数据都将消失；与之相对应的是一个 entity bean 描述了存储在数据库表中的一行持久

　　稳固的数据，如果客户端终止或者服务结束，底层的服务会负责 entity bean 数据的存储。

　　Message-driven bean 结合了 session bean 和 Java 信息服务（JMS）信息监听者的功能，它允

　　许一个商业组件异步地接受 JMS 消息。

编辑本段EJB3.0的介绍

　　由于EJB2.0的复杂性，在Spring和Hibernate等 轻量级框架出现后，大量的用户转向了，在大家的呼声中，

  

EJB

期待已久的EJB3.0规范终于发布了。在本文中将对新的规范进行一个概要性的介绍，包括新增的元数据支持，EJBQL的修改，实体Bean模型访问 bean上下文的新方法和运行时环境等等。作者还讨论了EJB在未来要作出的调整以及EJB3.0与其他开发规范之间的关系。

开始

　　无论如何由于EJB的复杂性使之在J2EE架构中的表现一直不是很好。EJB大概是J2EE架构中唯一一个没有兑现其能够简单开发并提高生产力的组件。EJB3.0规范正尝试在这方面作出努力以减轻其开发的复杂性。EJB3.0减轻了开发人员进行底层开发的工作量，它取消或最小化了很多(以前这些是必须实现)回调方法的实现，并且降低了实体Bean及O/R映射模型的复杂性。

　　在本文中，我首先会介绍EJB3.0中几个主要的改变。它对进一步深入了解EJB3.0是非常重要的。随后，我会从更高的层面来描述已经被提交到EJB3.0规范中的细节，并一个个的讲解新的规范中的改变:实体Bean,O/R映射模型， 实体关系模型和EJB QL(EJB查询语言)等等。

背景

　　EJB3.0中两个重要的变更分别是:使用了Java5中的程序注释工具和基于Hibernate的O/R映射模型。

  

EJB

Java5中的元数据工具

　　Java5(以前叫J2SE1.5或Tiger) 中加入了一种新的程序注释工具。通过这个工具你可以自定义注释标记，通过这些自定义标记来注释字段、方法、类等等。这些注释并不会影响程序的语义，但是可以通过工具(编译时或运行时)来解释这些标记并产生附加的内容(比如部署描述文件)，或者强制某些必须的运行时行为(比如EJB组件的状态特性)。注释的解析可以通过源文件的解析(比如 编译器或这IDE工具)或者使用Java5中的APIs反射机制。注释只能被定义在源代码层。由于所有被提交到 EJB3.0草案中的注释标记都有一个运行时的RetentionPolicy，因此会增加类文件占用的存储空间，但这却给容器制造商和工具制造商带来了方便。

　　Hibernate

　　目前Hibernate非常受欢迎，它是开发源代码的Java O/R映射框架，目的是把开发人员从繁琐的 数据持久化编程中解脱出来。它也有一个标准的HQL(Hibernate 查询语言)语言，你可以在新的EJB QL中看到它的影子。Hibernate在处理如数据查询、更新、 连接池、事务处理、实体关系处理等方面非常简单。

概览

　　在已经提交的EJB3.0规范中主要涉及两个方面的改变:

　　1. 一套以注释为基础的EJB编程模型，再加上EJB2.1中定义的通过部署描述符和几个接口定义的应用程序行为。

　　2. 新的实体Bean持久化模型，EJBQL也有许多重要的改变。

　　还有一些有关上述的提议，比如:一个新的客户端编程模型，业务接口的使用以及实体Bean的生命周期。请注意EJB2.1编程模型(包括部署描述符和home/remote接口)仍然是有效的。新的简化模型并没有完全取代EJB2.1模型。

编辑本段EJB注释

　　EJB规范组织一个重要的目标是减轻原始代码的数量，并且他们为此给出了一个完美而简洁的办法。在

  

EJB

EJB3.0的里，任何类型的企业级 Bean只是一个加了适当注释的简单Java对象(POJO)。注释可以用于定义bean的业务接口、O/R映射信息、资源引用信息，效果与在 EJB2.1中定义部署描述符和接口是一样的。在EJB3.0中部署描述符不再是必须的了;home接口也没有了，你也不必实现业务接口(容器可以为你完成这些事情)。

　　比如，你可以使用@Stateless注释标记类把Java类声明为一个无状态会话bean。对于有状态会话bean来说，@Remove注释可以用来标记一个特定的方法，通过这个注释来说明在调用这个方法之后bean的实例将被清除掉。

　　为了减少描述组件的说明信息，规范组织还采纳了由异常进行配置(configuration-by-exception)的手段，意思是你可以为所有的注释提供一个明确的缺省值，这样多数常规信息就可以据此推断得出。

新的持久化模型

　　新的实体bean也是一个加了注释的简单Java对象(POJO)。一旦它被EntityManager访问它就成为了一个持久化对象，并且成为了持久化上下文(context)的一部分。一个持久化上下文与一个事务上下文是松耦合的;严格的讲，它隐含的与一个事务会话共存。

　　实体关系也是通过注释来定义的，O/R映射也是，并提供几种不同的数据库规范操作，在EJB2.1中这些

  

EJB

要通过开发人员自己的 设计模式或者其它技术来完成的(比如，自增长主键策略)。

　　深入研究

　　现在是时候详细了解EJB3.0草案了。让我们开始探讨所有EJB中四种企业级bean，并看看他们在新的规范中是什么样子。

无状态会话bean

　　在EJB3.0规范中，写一个无状态会话bean(SLSB)只需要一个简单的Java文件并在类层加上@Stateless注释就可以了。这个bean可以扩展javax.ejb.SessionBean接口，但这些不是必须的。

　　一个SLSB不再需要home接口，没有哪类EJB再需要它了。Bean类可以实现业务接口也可以不实现它。如果没有实现任何业务接口，业务接口会由任意public的方法产生。如果只有几个业务方法会被暴露在业务接口中，这些方法可以使用@BusinessMethod注释。缺省情况下所有产 生的接口都是local(本地)接口，你也可以使用@Remote注释来声明这个接口为remote(远程)接口。

　　下面的几行代码就可以定义一个HelloWorldbean了。而在EJB2.1中同样的bean至少需要两个接口，一个实现类和几个空的实现方法，再加上部署描述符。

　　import javax.ejb.*;

　　/**

　　* A stateless session bean requesting that a remote business

　　* interface be generated for it.

　　*/

　　;@Stateless

　　;@Remote

　　public class HelloWorldBean {

　　public String sayHello() {

　　return "Hello World!!!";

　　}

　　}

有状态会话bean

　　除了几个SFSB的特别说明之外，有状态会话bean(SFSB)和SLSB一样精简:

　　

  

EJB

一个SFSB应该有一个方法来初始化自己(在EJB2.1中是通过ejbCreate()来实现的)。在EJB3.0的规范中建议这些初始化操作可以通过自定义方法完成，并把他们暴露在业务接口中。在使用这个bean之前由客户端来调用相应的初始化方法。目前规范组织就是否提供一个注释来标记某个方法用于初始化还存在争议。

　　Bean的提供者可以用@Remove注释来标记任何SFSB的方法，以说明这个方法被调用之后bean的实例将被移除。同样，规范组织仍然在讨论是否要有一种机制来处理这种特殊的情况，即当这个方法出现异常的情况下bean的实例是否被移除。

　　下面是对以上问题我个人的观点:

　　是否应该有一个注释来标明一个方法进行初始化呢?我的观点是――应该有，这样容器就可以在调用其他方法之前至少调用一个方法来进行初始化。这不仅可以避免不必要的错误(由于没有调用初始化方法)而且可以使容器更明确的判断是否可以重用SFSB实例。我暂且把这个问题放一放，规范组织只考虑为一个方法提供一个注释来声明它是一个初始化方法。

　　对于第二个问题我的观点也是肯定的。这有利于Bean的提供者合客户端程序对其进行控制。只有一个遗留的问题:那就是一旦调用这个方法失败，是否能移除这个bean 的实例?答案是不能，但是它将会在会话结束的时候被移除。

消息驱动Bean

　　消息驱动Bean是唯一一种必须实现一个业务接口的Bean。这个接口指出bean支持的是哪一种消息系统。对于以JMS为基础的MDB来说，这个接口是javax.jms.MessageListener。注意MDB业务接口不是一个真正意义上的业务接口，它只是一个消息接口。

实体Bean

　　实体Bean使用@Entity注释来标记，所有实体bean中的属性/字段不必使用@Transient注释来标记。实体bean的持久化字段可以通过JavaBean-style机制或者声明为public/protected字段来实现。

　　实体bean可以使用助手类来描述其状态，但是这些类的实例并没有持久化唯一性(persistent identity)的特性(即，唯一标识这个bean的字段等)，实际上这些助手类与他们的实体bean实例是紧密结合的;并且这些对象还是以非共享方式来访问实体对象的。

实体关联

　　EJB3.0同时支持Bean之间双向的合单向的关联，它们可以是一对一、一对多、多对一或者是多对多的关联。然而双向关联的两端还要分为自身端 (owning side)和对方端(inverse side)不同的端。自身端负责向数据库通告关联的变更。对于多对多的关联自身端必须明确的声明。实际上对方端通过isInverse=true进行注释 (由此自身端就不必说明了而是由另一段推断出)。看来上面的描述，规范组织还能说让EJB变的简单了吗?

O/R映射

　　EJB3.0中的O/R映射模型也有了重要的改变，它从原来的abstract-persistence-schema-based变成了现

  

EJB

在的Hibernate-inspired 模式。尽管目前规范组织还在就此进行讨论但是一个明确的模型将会出现在下一个版本的草案中。

　　举例来说，O/R映射模型将通过bean类中的注释来声明。而且此方法还会指出对应的具体表和字段。O/R映射模型提供了一套自有的SQL; 而且除了提供一些基本的SQL外还支持某些高层开发的功能。比如，有一个通过@Column注释声明的字段columnDefinition，那么可以写这 样的SQL:columnDefinition="BLOB NOT NULL"

客户端程序模型

　　一个EJB客户端可以通过@Inject注释以一种“注入”的方式获得一个bean的业务接口引用。你也可以使用另一个注释 @javax.ejb.EJBContext.lookup()来完成上面的操作，但是规范中没有告诉我们一个普通的Java客户端怎样获得一个Bean 的实例，因为这个普通的Java客户端是运行在一个客户端容器中，它无法访问@javax.ejb.EJBContex对象。现在还有另外一种机制来完成上面的工作那就是使用一个超级上下文环境对象:@javax.ejb.Context()。但是规范中没有指出该如何在客户端中使用这个对象。

EJB QL

　　EJB QL可以通过@NamedQuery来注释。这个注释有两个成员属性分别是name和queryString.一旦定义了这些属性，就可以通过 EntityManager.createNamedQuery(name)来指向这个查询。你也可以创建一个标准的JDBC风格的查询并使用 EntityManager.createQuery(ejbqlString)或EntityManager.createNativeQuery (nativeSqlString)(这个方法用于执行一个本地查询)来执行查询。

　　EJB QL有两个地方可以定义其参数。javax.ejb.Query接口提供了定义参数、指向查询、更新数据等等方法。下面是一个EJBQL指向查询的例子:

　　查看复制到剪切板打印

　　. ..

　　;@NamedQuery(

　　name="findAllCustomersWithName",

　　queryString="SELECT c FROM Customer c WHERE c name LIKE :custName"

　　)

　　.. ..

　　;@Inject public EntityManager em;

　　customers = em.createNamedQuery("findAllCustomersWithName")

　　.setParameter("custName", "Smith")

　　.listResults();

　　下面列出了一些EJB QL的增强特性:

　　支持批量更新和删除。

　　直接支持内连接和外连接。FETCH JOIN运行你指出关联的实体，Order可以指定只查询某个字段。

　　查询语句可以返回一个以上的结果值。实际上，你可以返回一个依赖的类比如下面这样:

　　SELECT new CustomerDetails(c id, c.status, o.count)

　　FROM Customer c JOIN c.orders o

　　WHERE o.count > 100　l 支持group by 和having。

支持where子句的嵌套子查询

　　在提交的EJB3.0草案中，EJB QL与标准SQL非常的接近。实际上规范中甚至直接支持本地的SQL(就像我们上面提到的那样)。这一点对某些程序员来说也许有些不是很清楚，我们将在下面进行更详细的讲解。

多样性

　　方法许可(Method permissions)可以通过@MethodPermissions和@Unchecked注释来声明;同样的，事务属性也可以通过 @TransactionAttribute注释来声明。规范中仍然保留资源引用和资源环境引用。这些一样可以通过注释来声明，但是有一些细微的差别。比如，上下文(context)环境要通过注入工具控制。容器根据bean对外部环境引用自动初始化一个适当的已经声明的实例变量。比如，你可以象下面这样获得一个数据源(DataSource):

　　;@Resource(name="myDataSource") //Type is inferred from variable

　　public DataSource customerDB;

　　在上面的例子中如果你不指定引用资源的名称(name)那么其中的customerDB会被认为是默认值。当所有的引用属性都可得到时候@Injec注释就可以这样写:

查看复制到剪切板打印

　　1. ;@Inject public DataSource customerDB;

　　;@Inject public DataSource customerDB;

　　容器负责在运行时初始化customerDB数据源实例。部署人员必须在此之前在容器中定义好这些资源属性。

　　更好的消息是:那些以前必须检测的异常将一去不复返。你可以声明任意的应用程序异常，而不必在再抛出或捕获其他类似 CreateException和FinderException这样的异常。容器会抛出封装在javax.ejb.EJBException中的系统级异常或者只在必要时候抛出IllegalArgumentException或IllegalStateException异常。

编辑本段EJB文件处理模式

　　在我们结束本节之前，让我的快速的浏览一下容器提供商在EJB处理模式方面可能的变更。规范中对此并没有明确的表态，但我可以想到至少两种模式。

　　一种办法是首先利用EJB文件生成类似于EJB2.1部署模式的文件(包括必要的接口和部署描述符)然后再用类似于EJB2.1的方式来部署这个EJB组件。当然，这样产生的部署描述符可能并不标准但是它可以解决同一个容器对EJB2.1和EJB3.0兼容的问题。下面这幅图描述了这一过程。

　　另一种方法是一种类似于JSP托放的部署模式。你可以把一个EJB文件放到一个预先定义的目录下，然后容器会识别这个EJB并处理它，然后部署并使之可以使用。这种方法可以建立于上面那种方法之上，在支持反复部署时有很大的帮助。考虑到部署的简单性也是EJB3.0规范的目的之一，我真诚的希望在下一个草案出来时能够确定一个模式(至少能有一个非正式的)。

　　你有什么想法?

　　EJB3.0规范的制定正在有序的进行，为了使EJB的开发变得更加容易，EJB规范组织作出的努力是有目共睹的。就像他们说的那样，一切对会变得简单，但做到这一点并不容易。目前已经定义了50个注释标记(还有几个将在下一个草案中发布)，每一个都有自己的 缺省规则和其他的操作。当然，我真的不希望EJB3.0变成EJB2.1的一个翻版"EJB 3.0 = EJB 2.1 for dummies"(希望这个等式不要成立)。最后，我还是忍不住要提一些我自己的观点:

　　首先，规范确实使反复部署变得容易了，并且有一个简单的模式来访问运行时环境。我还是觉得home接口应该放弃。

　　在早期的EJB规范中，实体bean用于映射一个持久化存储。理论上(也许只是理论上)可能需要把实体bean映射到一个遗留的EIS (enterprise information system)系统中。出于将来扩展的考虑这样作是有好处的，并且可以使更多的业务数据模型采用实体bean。也因此其伴随的复杂性使得实体bean不被看好。在本次提交的草案中，一个实体bean只是一个数据库的映射。并且是基于非抽象持久化模式和简单的数据访问模式的更加简单开发。

　　我对模型变更持保留态度，我认为在EJB中包含SQL脚本片断并不是个好注意。一些开发人员完全反对包含某些“SQL片段 (SQLness)”(比如@Table 和 @Column注释)。我的观点是这些SQLness是好的，据此我们可以清楚的知道我们到底要数据库作些什么。但是某些SQL段我看来并不是很好，比如 columnDefinition="BLOB NOT NULL"，这使得EJB代码和SQL之间的耦合太过紧密了。

　　尽管对于本地SQL的支持看似很诱人，其实在EJB代码中嵌入SQL是一个非常糟糕的主意。当然，有些办法可以避免在EJB中硬编码SQL，但是这应该在规范中说明，而不能是某些开发人员自己定义的模式。

　　假设@Table注释只用于类。在运行时通过@Table注释的name属性定义的表名称将必须对应一个实际的数据库表。规范对此应该给予清楚的说明和一致的模式。

　　规范还需要更清楚的说明客户端编程模型，尤其是普通java客户端。规范中所有的参考都假设或者隐含的使用EJB客户端。而且规范中对客户端的向后兼容方面也没有给出明确的说法。

　　Transient注释应该重新命名以避免和已有的transient关键字发生冲突。事实上，在这一点上我们更乐于稍微的背离一下 configuration-by-exception原则并且定义一个@Persistent注释来明确的定义持久化字段 @Persistent注释 可以仅仅是一个标记注释或者它可以有几个属性来关联O/R映射注释。

编辑本段与其他规范的关联

　　目前可能影响到EJB3.0的JSR有JSR175(java语言元数据工具)和JSR181(Java Web服务元数据)

　　JSR175已经初步完成并且不会和EJB3.0有太大的冲突;但是JSR181与EJB3.0有两个关联的地方:

　　Web service接口:EJB规范将采用一种机制适应JSR181以便可以把一个bean实现为一个Web service并告诉Web service如何被客户端调用。

　　JSR 181计划采用不同的机制来处理安全问题。在早期的规范中EJB建议使用一个一致的机制(MethodPermissions)，但是JSR 181计划使用一个稍微不同的方式(SecurityRoles和SecurityIdentity注释)。同样的RunAs注释的定义也存在这些许差别。这一问题还在解决中最终会在J2EE层的规范中维持其一致性。

　　在J2EE 1.5中的一些开发规范可能与EJB3.0有关联。除了上面说到的几个关联之外现在没有其他的开发规范与EJB3.0有冲突。

编辑本段关于EJB3.1

　　对于EJB，优先考虑的就是全部重建。“我们只有先清空杯子里的水，才能接纳新的东西”。现在杯子已经清空了，这对我们来说是非常有利的，而且还可以没有包袱的大胆前进。

　　EJB3.1 又一次引入了一系列新的特性，倾向于挖掘技术的潜力。依我来看，EJB3.1绝对是一个重要的发布版本，它将那些长期让人渴望的特性带到开发者面前，更加能够满足最新的企业 应用程序开发，同时对EJB再次被人们采纳将做出巨大的贡献。

　　目前，EJB 3.1 最终发行版已经发布了。

　　EJB3.1 架构模式相对于旧的架构模式有如下的一些扩展和针对API的一些简化：

　　· 简化的本地模式让去除了本地的商务接口一样可达到session bean

　　· 直接用war 文件打包一个ejb组件不需要一个ejb-jar

　　· 在Java SE环境中嵌入API执行EJB

　　· 引入了可以提供简单的共享应用数据和支持一致性访问的Singleton session bean组件

　　· 自动创建EJB 定时器

　　· 基于EJB定时表达式的日程表

　　· 异步session bean调用

　　· 对于一个EJB轻量子集的定义，这个子集可以提供一些Java EE文档 (EJB lite)

　　· 一个用来查询ejb组件的Global JNDInames( 统一的 全局 JNDI 命名 ) 规则

编辑本段结束语

　　在使EJB的开发变得简单高效之前，我们还有很长一段路要走。规范组织在降低EJB的开发难度方面起了个好头。O/R映射模型的提议还处在早期阶段，规范组织正在完善它。我希望它不要太复杂也不要与SQL过分的耦合。