爱华网EJB是sun的JavaEE服务器端组件模型，设计目标与核心应用是部署分布式应用程序。简单来说就是把已经编写好的程序（即：类）打包放在服务器上执行。凭借java跨平台的优势，用EJB技术部署的分布式系统可以不限于特定的平台。EJB (Enterprise JavaBean)是J2EE(javaEE)的一部分，定义了一个用于开发基于组件的企业多重应用程序的标准。其特点包括网络服务支持和核心开发工具(SDK)。 在J2EE里，Enterprise Java Beans(EJB)称为Java 企业Bean，是Java的核心代码，分别是会话Bean（Session Bean），实体Bean（Entity Bean）和消息驱动Bean（MessageDriven Bean）。
EJB_EJB -简介
1.SessionBean用于实现业务逻辑，它可以是有状态的，也可以是无状态的。每当客户端请求时，容器就会选择一个Session
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实际上是一个异步的无状态SessionBean，客户端调用MDB后无需等待，立刻返回，MDB将异步处理客户请求。这适合于需要异步处理请求的场合，比如订单处理，这样就能避免客户端长时间的等待一个方法调用直到返回结果。
EJB实际上是SUN的J2EE中的一套规范,并且规定了一系列的API用来实现把EJB概念转换成EJB产品。
EJB
EJB
一个技术规范：EJB 从技术上而言不是一种"产品"
,EJB 是一种描述了构建应用组件要解决的标准：
可扩展 (Scalable)
分布式 (Distributed)
事务处理(Transactional)
数据存储(Persistent)
安全性 (Secure)
期望
提供一个标准的分布的、基于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 处理。一个 enterprisebean 可以从客户端接受数据，对
它进行处理，并将其发送到企业信息系统层以作存储；同时它也可以从存储器获取数据，
处理后将其发送到客户端应用程序。
有三种类型的 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消息。
EJB_EJB -EJB3.0
EJB
由于EJB2.0的复杂性，在Spring和Hibernate
等轻量级框架出现后，大量的用户转向了，在大家的呼声中，
期待已久的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查询语言)等等。
背景
EJB
EJB3.0中两个重要的变更分别是：使用了Java5中的程序注释工具和基于Hibernate的O/R映射模型。
Java5中的元数据工具
Java5(以前叫J2SE1.5或Tiger) 中加入了一种新的程序注解工具。通过这个工具你可以自定义注解标记，通过这些自定义标记来注解字段、方法、类等等。这些注解并不会影响程序的语义，但是可以通过工具(编译时或运行时)来解释这些标记并产生附加的内容(比如部署描述文件)，或者强制某些必须的运行时行为(比如EJB组件的状态特性)。注解的解析可以通过源文件的解析(比如编译器或这IDE工具)或者使用Java5中的APIs反射机制。注解只能被定义在源代码层。由于所有被提交到 EJB3.0草案中的注解标记都有一个运行时的RetentionPolicy，因此会增加类文件占用的存储空间，但这却给容器制造商和工具制造商带来了方便。
Hibernate
框架，目的是把开发人员从繁琐的数据持久化编程中解脱出来。它也有一个标准的HQL(Hibernate 查询语言)语言，你可以在新的EJB QL中看到它的影子。Hibernate在处理如数据查询、更新、连接池、事务处理、实体关系处理等方面非常简单。
概览
在已经提交的EJB3.0规范中主要涉及两个方面的改变：
1. 一套以注释为基础的EJB编程模型，再加上EJB2.1中定义的通过部署描述符和几个接口定义的应用程序行为。
2. 新的实体Bean持久化模型，EJBQL也有许多重要的改变。
还有一些有关上述的提议，比如:一个新的客户端编程模型，业务接口的使用以及实体Bean的生命周期。请注意EJB2.1编程模型(包括部署描述符和home/remote接口)仍然是有效的。新的简化模型并没有完全取代EJB2.1模型。
EJB_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)的一部分。一个持久化上下文与一个事务上下文是松耦合的;严格的讲，它隐含的与一个事务会话共存。
EJB
实体关系也是通过注释来定义的，O/R映射也是，并提供几种不同的数据库规范操作，在EJB2.1中这些
要通过开发人员自己的设计模式或者其它技术来完成的(比如，自增长主键策略)。
深入研究
是时候详细了解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
;@Remove
public class HelloWorldBean {
public String sayHello() {
return "Hello World!!!";
}
}
有状态会话
除了几个SFSB的特别说明之外，有状态会话bean(SFSB)和SLSB一样精简：
EJB
一个SFSB应该有一个方法来初始化自己(在EJB2.1中是通过ejbCreate()来实现的)。在EJB3.0的规范中建议这些初始化操作可以通过自定义方法完成，并把他们暴露在业务接口中。在使用这个bean之前由客户端来调用相应的初始化方法。规范组织就是否提供一个注释来标记某个方法用于初始化还存在争议。
Bean的提供者可以用@Remove注释来标记任何SFSB的方法，以说明这个方法被调用之后bean的实例将被移除。同样，规范组织仍然在讨论是否要有一种机制来处理这种特殊的情况，即当这个方法出现异常的情况下bean的实例是否被移除。
下面是对以上问题我个人的观点:
是否应该有一个注释来标明一个方法进行初始化呢?我的观点是
