EJB（Enterprise JavaBeans）可不算什么新概念了，但许多人在听到或者看到这个名词的时候还会眼晕。EJB组件在J2EE规范中自成一层，把应用程序的表示层和后端信息系统（比如数据库或者主框架计算机）捆绑了起来。EJB架构既用到了EJB对象的功能又利用了它们所运行的环境。

为什么出来个EJB

从概念上看，EJB对象封装了业务对象及其概念，让开发人员把精力集中于解决方案的细节之上。从设计的角度看，EJB应该轻便而相互影响地合并起来。这一举措可以令单一的EJB，不论其是否为商务应用程序就可能采用一个EJB代表自主开发还是第3方厂商开发却都能用于多种应用程序。比方说，CRM（客户关系管理）工具和电子一位用户。这些已经具有适应性对象的配置由于部署描述符、说明EJB的XML文件而变得非常简单。部署描述符允许不经重新编译就可修改EJB属性和行为。

EJB的处所

EJB对象驻留在EJB容器内，后者是向开发者提供各类服务的环境。容器根据具体的配置可能负责处理安全、事务和实例管理。由于程序员无须再亲自完成这些任务从而令开发时间大大节约。

J2EE服务器和EJB容器这两个概念之间存在显著差别， EJB容器可能属于J2EE服务器的一部分，但却并不一定是必需的组成部分。在作为J2EE服务器组成部分的情况下，EJB客户程序通常会采取Java servlet或者JSP的形式。不过，由于取消了对J2EE Web层的依附性，标准的EJB容器服务可以接受多种类型客户程序、用Java或其他各种语言编写的应用程序所发出的请求。同EJB容器的通讯才是客户操作的先决条件。

EJB的内容

EJB对象分为以下三种类别： 

会话Beans 
实体Beans 
消息驱动Beans 

根据所需要的bean行为，某些特性决定了所采用的Bean类型。

会话Beans

会话（Session）Beans的作用建立在会话的基础之上。客户在请求并收到bean功能之后，具有特定bean的会话就终止了而且没有留下会话发生的记录。会话Bean类型还可以进一步细分为无状态或者有状态方式。

无状态会话Beans并不知道客户或者涉及到请求的上下文，从而令其成为单一请求/回应应用的理想工具。比方说，一个用户搜索所有公开bug的bug跟踪系统就是如此。客户应用程序联系一个无状态会话Bean并给其传递搜索参数。接着，这个bean访问数据库，选择匹配检索条件的条目，并把记录传回客户程序。通讯完成之后，bean不保留交互信息。因此，多个客户程序可以同时访问无状态会话Bean却不会相互影响。

相反，有状态会话Beans会把请求同特定的客户联系起来，在客户和bean之间建立一种一对一的关系。购物车bean就是一例。用户实施标准的电子商务任务，给购物车里加入商品，输入地址信息然后下定单。购物车bean维持状态，因而它知道所有这些变量都关联某一特定客户。

实体Beans

实体（Entity）Beans表示会话终止之后持久存在的业务对象或者数据。它们通常作为数据库中的单一记录形式存在，当然，其存储形式也可能采用其他媒质，比如文件等。一个对象就表示一个用户，有名字、联系方式、语言选择等等，这些参数代表了实体Bean的用途。作为持久性最本质的内涵之一，实体Bean的唯一标识或者主键起到了识别和检索正确对象信息的作用。实体beans需要主键作为“辅助类”封装对象的唯一标识符。

消息Beans

以上的两种bean类型以同步方式为EJB客户提供服务。客户发出请求然后等待bean发回结果。消息驱动（Message Driven） Beans避免了这一可能的瓶颈问题。采用Java消息服务JMS（Java Messaging Service）。客户程序可以产生一个消息并把消息发布给消息队列。消息驱动Bean随之采用或者检索消息执行其内容。这种事件或者数据的通讯就成为异步形式；客户或者bean都无须依赖对方的直接响应了。

比如，伦敦的一位银行官员使用一种应用程序发布最新的汇率消息。这时，部署在波士顿的一个外部交易bean从消息队列中获取这一消息然后更新数据库中的有关记录。在理想的情况下，消息驱动Bean会把信息传递给处理数据库事务的实体Bean。这样，每一种bean把它不能处理的任务转发从而创建出一种真正的分布式组件结构。

EJB的原理

现在不考虑EJB的类别，以上三种类型组成了EJB对象：本地接口、远程接口和bean的实现。客户程序使用Java命名和目录接口JNDI（Java Naming and Directory Interface）定位bean的本地接口(JNDI)。本地接口随后返回远程接口的实例，同时暴露必要的bean实现方法。客户程序再调用适当的这些方法。程序清单A所示的代码说明了以上过程。

Listing A 

First comes the EJB client class—in this case, a very simple stand-alone user interface:

import javax.ejb.*; 

import javax.naming.*; 

import java.util.*; 

import org.shifter.ejb.*;

public class VerySimpleClient

{ 

public static void main( String[] args ) { 

try { 

Context ctx = getInitialContex(); VerySimpleHome home = ( VerySimpleHome )ctx.lookup( “simpleton“ ); 

VerySimple ejb = home.create(); 

ejb.setName( “Fredrick“ ); 

System.out.println( “My name is “ + ejb.getName() ); 

ejb.remove();

} catch (Exception e) {

e.printStackTrace();

} }

public static Context getInitialContext() throws NamingException {

// Retrieve the Context via JNDI lookup

} }

Now, we define the Home and Remote interfaces. The client interacts directly with these classes:

package org.shifter.ejb; 

// The home interface import javax.ejb.*; import java.rmi.RemoteException;

public interface VerySimpleHome extends EJBHome {

public VerySimple create() throws CreateException, RemoteException; } 

package org.shifter.ejb; 

// The remote interface import javax.ejb.*; 

import java.rmi.RemoteException;

public interface VerySimple extends EJBObject { 

public String getName() throws RemoteException; 

public void setName( String n ) throws RemoteException; }

Finally, we have the implementation of the EJB, where all functionality occurs:

package org.shifter.ejb;

import javax.ejb.*;

public class testertwoEJB implements javax.ejb.SessionBean{

// Member variables private String name; private SessionContext ctx;

// Default constructor 

public testertwoEJB() { }

// Called by the create() method of the home interface.

public void ejbCreate() { }

// Called by the remove() method of the home interface.

public void ejbRemove() { }

// Called when the EJB container makes this bean active.

public void ejbActivate() { 

// Resource allocation might go here. 

} 

// Called when the EJB container makes this bean inactive. public void ejbPassivate() { 

// Resource clean up might go here. }

// Set the runtime context 

public void setSessionContext(SessionContext ctx) { this.ctx = ctx; } 

// ***** 

// The following methods are the only ones visible 

// to EJB clients through this bean’s remote interface. 

// ***** 

public String getName() { 

return name; } 

public void setName( String n ){ 

name = ( n != null ) ? n : “Igor“; } }

你可能需要根据bean的类型实现其他方法。比方说，假如客户需要定位实体Bean，那么你的本地接口就要包括findByPrimaryKey()方法，由它把主键类作为其参数以返回适当的对象。

早先提到过，每一个EJB对象所包装的部署描述符会告诉EJB容器对象的行为如何。描述符之一，也就是所谓的ejb-jar.xml就是完成以上功能的，它是具有容器管理事务所有方法的无状态会话Bean，如程序清单B所示。

Listing B 

〈ejb-jar〉

〈enterprise-beans〉

〈session〉

〈ejb-name〉VerySimple〈/ejb-name〉 〈home〉org.shifter.ejb.VerySimpleHome〈/home〉 〈remote〉org.shifter.ejb.VerySimple〈/remote〉 

〈ejb-class〉org.shifter.ejb.VerySimpleEJB〈/ejb-class〉 〈session-type〉Stateless〈/session-type〉 

〈transaction-type〉Container〈/transaction-type〉 

〈/session〉 

〈/enterprise-beans〉 

〈assembly-descriptor〉 

〈container-transaction〉 

〈method〉 

〈ejb-name〉VerySimple〈/ejb-name〉 

〈method-name〉*〈/method-name〉 

〈/method〉 

〈trans-attribute〉Required〈/trans-attribute〉 

〈/container-transaction〉 

〈/assembly-descriptor〉 

〈/ejb-jar〉

根据EJB容器的类型，另一种部署描述符会告诉容器如何识别和定位采用JNDI的bean。以WebLogic服务器为例，起这一作用的就是weblogic-ejb-jar.xml，情形如程序清单C所示。

Listing C 

〈weblogic-ejb-jar〉 

〈weblogic-enterprise-bean〉 

〈ejb-name〉VerySimple〈/ejb-name〉 

〈jndi-name〉simpleton〈/jndi-name〉 

〈/weblogic-enterprise-bean〉 

〈/weblogic-ejb-jar〉

喜忧掺半

EJB的使用会涉及到某些内在的危险和可能的问题。程序员在给EJB对象编码的时候必须遵守大量的语法和行为规则。它们还必须确定到底是采用bean自身还是EJB容器的持久性管理；选择错误就可能都是数据。容器甚至可能崩溃从而破坏活动的会话Beans。容器还可能在尝试回滚事务的时候失败而丧失信息。部署EJB对象是一个单调反复的过程，在没有容器源代码的情况下进行调试工作几乎是不可能的。

不过，EJB的组件天性却令其代码的重用性优势凸显，从而节约了开发过程中的大量时间和金钱。开发人员可以把关注点集中于业务逻辑本身，而把安全和事务回滚等任务交付给EJB 容器。可靠的对象实例管理和方便的配置更是EJB的突出优点。学习和掌握EJB的设计规则确实是一件很费时间和精力的工作，但其结构本身在应用程序的开发过程中会产生非常有益的好处。