正如你看到的那样，中心的基类AbstractEnterpriseBean暴露了beanFactoryLocator属性来允许子类访问正在使用的实例BeanFactoryLocator。在下一节中，将通过loadBeanFactory()和unloadBeanFactory()这两个方法的使用来更加详细的讨论BeanFactoryLocator接口。注意到AbstractStatelessSessionBean类已经实现了ejbCreate()，ejbActivate()和ejbPassivate()方法，而类AbstractStatefulSessionBean并没有实现这些方法。Spring对钝化bean有特别的要求，我们将在后面章节“编译有状态会话bean”中更加详细的讨论这种bean。

接口BeanFactoryLocator

Spring能够从ApplicationContext中装载所管理的资源，Spring中的EJB基类的主要特征就是能够访问ApplicationContext来装载资源。这种功能不是基类本身提供的，而是被委托给BeanFactoryLocator接口的实现，像显示在列表1中的情形一样。

列表1. BeanFactoryLocator接口

public interface BeanFactoryLocator {
   BeanFactoryReference useBeanFactory(String factoryKey) throws BeansException;
}

当Spring不能控制资源的创建，也不能自动配置资源的情况下，就需要使用BeanFactoryLocator接口。在这些情况下，BeanFactoryLocator接口允许用一种外部可配置的方式在BeanFactory中配置资源。当然，在这样的情况下，BeanFactory配置能够简单地托管资源，但是，那意味着，作为应用程序开发员的你，不能控制应用程序。使用BeanFactoryLocator，你就能够完全控制用于配置的BeanFactory或者ApplicationContext如何定位EJB组件。

注意到，BeanFactoryLocator并不直接返回BeanFactory实例;而是返回一个BeanFactoryReference。BeanFactoryReference是一个轻量级BeanFactory或ApplicationContext的包装器，这个包装器允许使用BeanFactory的资源平滑地释放对BeanFactory的引用。对于BeanFactoryLocator的实现和BeanFactory或者ApplicationContext接口来说，这个接口BeanFactoryReference的实际的实现是特别的。当我们在列表13中研究状态会话bean如何释放对BeanFactoryReference的引用挂起bean时，我们将再对这个引用功能进行研究。

缺省情况下，所有EJB基类使用了BeanFactoryLocator的ContextJndiBeanFactoryLocator实现。本质上来说，这个类在一个给定JNDI地点上查找一个逗号分隔的配置文件列表，并且使用这些配置文件来创建ClassPathXmlApplicationContext的实例。三个基本EJB类都通过AbstractEnterpriseBean类表现出属性beanFactoryLocator，通过设置这个属性，就能够提供你自己对于BeanFactoryLocator的不同实现。然而，如果你这样做了，那么，请注意，你的bean的每一个实例都有它自己的ContextJndiBeanFactoryLocator实例，同样，每个ContextJndiBeanFactoryLocator的实例都有它自己的ClassPathXmlApplicationContext实例。

虽然为你的EJB实例创建的所有ApplicationContext实例都用同样的方式配置的，但是，所配置的bean是不一样的。考虑一下定义了echoService bean的Spring配置，其中，EchoServiceEJB将使用echoService。如果你的应用程序服务器创建100EJB个实例，那么，也创建了100个ContextJndiBeanFactoryLocator的实例，以及100个ClassPathXmlApplicationContext和echoService bean的实例

如果应用程序不希望发生这种情况，那么Spring提供SingletonBeanFactoryLocator和ContextSingletonBeanFactoryLocator类来分别装载BeanFactory和ApplicationContext的单件实例。有关他们更多信息，参见这些类的Javadoc。

Spring对于EJB的解决方案

EJB一个最大的缺点就是要想脱离EJB容器而单独测试EJB组件非常困难，这使得EJB实现的业务逻辑的单元测试成为只有那些受虐狂者才愿意做的事。然而，这个问题的解决方法已经出现了一段时间了，它包括在POJO中实现与EJB bean类同样的业务逻辑，然后，就能将bean类委托给POJO。在Spring中，由于不必将如何定位和创建POJO的实现的任何逻辑嵌入到EJB中，这种实现就是非常简单，和灵活的。图2显示了在构建EchoService EJB的时候，如何使用这种方法的。

这里，正如所期望的那样，你看到了bean类EchoServiceEJB实现了接口EchoService，并且注意到EchoServiceEJB依赖于接口EchoService，有一个EchoService类型的私有成员。

构建一个无状态会话bean

无状态会话bean是用Spring最容易构建的EJB;这是因为无论在何种情况下，它都不需要特殊的处理，并且类AbstractStatelessSessionBean实现了所有ejbXXX()方法。

正如列表2所示，我们创建了服务接口。

列表2. EchoService接口

package com.apress.prospring.ch13.ejb;
public interface EchoService {
   public String echo(String message);
}

注意到，服务接口不是与EJB相关的，甚至，在实现EJB的时候并不要求这个服务接口。EJB开发中传统办法是在EJB相关的本地和远程接口中定义业务逻辑方法。在这种办法中，在标准Java接口中定义业务方法，然后本地和远程bean接口扩展这个标准接口。这种服务接口不仅给本地和远程接口提供了扩展的标准接口，而且也提供了EJB bean类和POJO实现类能够实现的通用的接口。虽然我们并不推荐EJB bean类不要实现本地或者远程接口，但是实现了这个服务接口的EJB bean也不会有什么问题。通过使所有EJB的组成组件共享通用的接口，就能够很容易的确保本地接口定义你想要调用的方法，这样，你的bean类实现了本地接口需要的方法，而POJO实现EJB bean类需要的方法。

下一步是创建bean接口。在这个例子中，我们并不在远程容器中使用EJB，因此，我们一直使用本地接口，正如列表3所示。

列表3. EchoService EJB的本地接口

package com.apress.prospring.ch13.ejb;
import javax.ejb.EJBLocalObject;
public interface EchoServiceLocal extends EchoService, EJBLocalObject {
}

注意到，像前面讨论的那样，这个接口并没有定义业务逻辑的方法。相反，EchoServiceLocal接口扩展了服务接口EchoService。

接下来，需要创建EJB Home接口。在这个例子中，我们并不会远程调用EJB，因此，我们一直使用在列表4中展现的本地home接口。

列表4. EchoService EJB的本地home接口

package com.apress.prospring.ch13.ejb;
import javax.ejb.CreateException;
import javax.ejb.EJBLocalHome;
public interface EchoServiceHome extends EJBLocalHome {
   public EchoServiceLocal create() throws CreateException;
}

仔细的看看大多数EJB规范要求的样板代码。

当你使用传统的架构来构建EJB的时候，下一步就是创建bean类。然而，我们将要把EchoService的实现构建成一个POJO，然后，将EJB bean类的实现委托给POJO实现。列表5展现了EchoService接口的POJO实现。

列表5. EchoService的POJO实现

package com.apress.prospring.ch13.ejb;
public class EchoServiceImpl implements EchoService {
   public String echo(String message) {
      return message;
   }
}

现在所有EchoService的实现都包含在一个POJO中了，你能够在EJB容器外部容易地测试这个POJO。(注意，这个实现需要很多测试!)

实现EchoService EJB的最后一步是创建bean类自身。这是开始使用Spring的地方。通过在EchoServiceImpl中对EchoService接口的真正实现，就能够简单地选择创建EchoServiceEJB的一个实例。

然而，如果想要改变这个实现，会出现什么事情呢?需要重新译和部署EJB。使用Spring，我们能够从ApplicationContext中装载实现类和任何依赖类。这就意味着，你能够完全的利用实际实现类的Spring的特征，包括DI，AOP和扩展配置支持。列表6展现了EchoService bean类的实现。

列表6. EchoServiceEJB类

package com.apress.prospring.ch13.ejb;
import javax.ejb.CreateException;
import org.springframework.ejb.support.AbstractStatelessSessionBean;
public class EchoServiceEJB extends AbstractStatelessSessionBean implements EchoService {
   private static final String BEAN_NAME = "echoService";
   private EchoService service;
   public String echo(String message) {
      return service.echo(message);
   }
   protected void onEjbCreate() throws CreateException {
      service = (EchoService) getBeanFactory().getBean(BEAN_NAME);
   }
}

在这个代码中，有一些值得注意的让人感兴趣的地方。首先，你应该注意到EchoServiceEJB继承了Spring基类AbstractStatelessSessionBean并且实现了EchoService接口。其次，所有EchoService接口上方法都被委托给EchoService类包装实现。第三，这个bean没有ejbXXX()等方法，这些方法是实现在AbstractStatelessSessionBean中。最后，注意onEjbCreate()方法。这是一个AbstractStatelessSessionBean提供的钩子方法，并且在ejbCreate()中调用。这个方法能够获得EJB bean需要的任何Spring管理的资源，特别地，能够获得服务接口真正的实现。正如你所看到的那样，我们从Spring中获得echoService bean并且把它保存在service成员中。这个bean是EchoService实现，并且EchoServiceEJB将功能委托给这个bean。

还记得在图1中，getBeanFactory()方法定义在AbstractEnterpriseBean类之上，而AbstractEnterpriseBean类构成了所有SpringEJB实现支持类的基础。缺省情况下，在ContextJndiBeanFactoryLocator实例中查找AbstractEnterpriseBean类，并且从getBeanFactory()方法返回ApplicationContext来装载它。ContextJndiBeanFactoryLocator通过查找一个特定的文件名列表JNDI位置来查找AbstractEnterpriseBean类，并且从这个文件列表中装载ApplicationContext配置。我们能够在部署描述符中指定这个EJB，如列表7显示那样。

列表7.在部署描述符中配置ContextJndiBeanFactoryLocator

<session>
   <description>Echo Service Bean</description>
   <ejb-name>EchoServiceEJB</ejb-name>
   <local-home>com.apress.prospring.ch13.ejb.EchoServiceHome</local-home>
   <local>com.apress.prospring.ch13.ejb.EchoServiceLocal</local>
   <ejb-class>com.apress.prospring.ch13.ejb.EchoServiceEJB</ejb-class>
   <session-type>Stateless</session-type>
   <transaction-type>Container</transaction-type>
   <env-entry>
      <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>applicationContext.xml</env-entry-value>
   </env-entry>
</session>

在这个部署描述符中的重要部分是 标签，它设置了ejb/BeanFactoryPath JNDI位置为applicationContext.xml。JNDI路径ejb/BeanFactoryPath是ContextJndiBeanFactoryLocator查找配置文件路径缺省位置。在列表7中的配置实质上是告诉与EchoServiceEJB相关联的实例ContextJndiBeanFactoryLocator创建一个ApplicationContext，这个ApplicationContext是使用文件applicationContext.xml中的详细细节来配置的。

一个需要注意的重要地方是这个配置文件是和EJB相关的，并且与任何主应用程序可能有的applicationContext.xml文件相分离的。当打包应用程序时，要把与EJB相关的applicationContext.xml文件放到EJB的jar文件中，然后将web应用程序的applicationContext.xml文件放到war文件中。要完成EchoServiceEJB的部署，我们需要和Jboss相关的bean部署描述符。显示在列表8中。

列表8. JBoss部署描述符

<jboss>
   <enterprise-beans>
      <session>
         <ejb-name>EchoServiceEJB</ejb-name>
         <local-jndi-name>ejb/echoService</local-jndi-name>
      </session>
   </enterprise-beans>
</jboss>

这个部署描述符中的重要部分是 标签，它告知Jboss绑定EJB home的JNDI名字。在这种情况下，我们便能够在ejb/echoService下找到EchoServiceHome。

这些都是对与无状态会话bean的开发过程。正如你所看到的那样，与传统的EJB实现的方法相比，实现步骤并没有太多的不同。然而，使用这儿的解决办法，不需要依赖EJB容器，就能够容易地测试你的业务逻辑。通过使用Spring，我们使基于POJO的实现方法具有了更多的灵活性，并且，能够容易地避免将EJB bean与特定的POJO实现结合在一起。

构建有状态会话bean

构建有状态会话bean比构建无状态会话bean更加复杂，因为在构建有状态会话bean时，必须考虑在bean处于挂起状态时，ApplicationContext将会出现什么情况。回顾图1，AbstractStatefulSessionBean并没有实现ejbCreate()，ejbActivate()和ejbPassivate()。这是因为Spring提供的BeanFactory和ApplicationContext的缺省实现是不可串行化的，因而，有状态会话bean就不能够被(passivated)钝化处理。

为了解决这种情况，有两种选项。最简单的选项是实现ejbActivate()和ejbPassivate()来在适当的时候装载和卸载ApplicationContext，这就允许不需要存储ApplicationContext就能够实现bean的(passivated)钝化，并且能够在bean被重新激活的时候重构ApplicationContext。第二个选项是提供你自己的BeanFactoryLocator实现，它创建了一个可串行化的BeanFactory或者ApplicationContext。当使用第一种方法时，注意到当使用ContextJndiBeanFactoryLocator的时候，bean的激活就导致ApplicationContext被随机地载入。如果对于你的应用程序来说，这是不可接受的开销，那么，你可以像前面讨论的那样，使用ContextSingletonBeanFactoryLocator来代替ContextJndiBeanFactoryLocator。

就像前面那样，要开始构建bean，我们将从服务接口开始讨论，如列表9显示的那样。

列表9. CounterService接口

package com.apress.prospring.ch13.ejb;
public interface CounterService {
   public int increment();
   public int decrement();
}

我们创建一个基本的服务接口，这个接口是被本地接口，bean接口，和实现类所实现。下一步是创建本地接口，显示在列表10中。

列表10. CounterService的本地接口

package com.apress.prospring.ch13.ejb;
import javax.ejb.EJBLocalObject;
public interface CounterServiceLocal extends CounterService, EJBLocalObject {
} 

本地接口自己不包含方法定义，所有的业务方法都是从CounterService接口继承的。下一步，我们需要创建home接口，如列表11所示。

列表11. CounterService的本地home接口

package com.apress.prospring.ch13.ejb;
import javax.ejb.CreateException;
import javax.ejb.EJBLocalHome;
public interface CounterServiceHome extends EJBLocalHome {
   public CounterServiceLocal create() throws CreateException;
}

这个实现没有什么特别的地方，它只是标准EJB的解决办法。

CounterService EJB需要的第四个组件是POJO实现。这个实现是有状态的，并且被标记成，因此，它能够和CounterServiceEJB一起被钝化(passivated)。列表12显示了CounterServiceImpl类。

列表12.基本的CounterService实现

package com.apress.prospring.ch13.ejb;
import java.io.Serializable;
public class CounterServiceImpl implements CounterService, Serializable {
   private int count = 0;
   public int increment() {
      return ++count;
   }
public int decrement() {
      return --count;
   }
}

在现在为止，我们所看到的有状态会话bean的实现类似于无状态会话bean的实现。然而，当实现bean类的时候，就存在显著的区别。列表13显示了CounterServiceEJB的bean类。

列表13. CounterServiceEJB类

package com.apress.prospring.ch13.ejb;
import java.rmi.RemoteException;
import javax.ejb.CreateException;
import javax.ejb.EJBException;
import org.springframework.ejb.support.AbstractStatefulSessionBean;
public class CounterServiceEJB extends AbstractStatefulSessionBean implements CounterService {
   private CounterService service;
   public int increment() {
      return service.increment();
   }
   public int decrement() {
      return service.decrement();
   }
   public void ejbCreate() throws CreateException {
      load();
      service = (CounterService) getBeanFactory().getBean("counterService");
   }
   public void ejbActivate() throws EJBException, RemoteException {
      load();
      service = (CounterService) getBeanFactory().getBean("counterService");
   }
   public void ejbPassivate() throws EJBException, RemoteException {
      unload();
}
   private void load() {
      loadBeanFactory();
   }
   private void unload() {
      unloadBeanFactory();
      setBeanFactoryLocator(null);
   }
} 

Bean类实现的第一部分类似于前面创建的EchoServiceEJB的实现。然而，显著的区别在于方法ejbCreate()，ejbActivate()和ejbPassivate()中。在ejbCreate()中，我们调用方法load()，相应地它调用了在AbtstractEnterpriseBean上的loadBeanFactory()方法。这就使得BeanFactoryLocator的实现载入BeanFactory，并且能够调用方法getBeanFactory()。最后，方法ejbCreate()使用BeanFactory来访问counterService bean，并把这个bean存储在成员service中。

现在，bean已经被配置了，并且将会一直运行，直到容器将它挂起。当容器要挂起bean的时候，就调用方法ejbPassivate()，然后是方法unload()。方法unload()所进行的第一步操作是调用unloadBeanFactory()，它清除了被ContextJndiBeanFactoryLocator载入的ApplicationContext，然后将引用设置为null。正如前面所提到的那样，因为ClassPathXmlApplicationContext(ContextJndiBeanFactoryLocator所使用的ApplicationContext实现)是不可串行化的，所以，它不能和bean一起被钝化(passivated)。最后，unload()删除所有关于BeanFactoryLocator实现的引用，因为与ClassPathXmlApplicationContext一样，ContextJndiBeanFactoryLocator是不可串行化的。

当容器在钝化(passivation)一个bean之后重新激活它的时候，它就调用在bean上的方法ejbActivate()，以使得bean能够重新构建任何没有被钝化(passivated)的状态。在这个例子中，我们简单地重新调用load()来重载ApplicationContext。注意到，如果你正在使用一个定制的BeanFactoryLocator实现。那么你也需要在ejbActivate()中重新实例化它。一旦ApplicationContext被重新载入，我们就从ApplicationContext中重新装载了counterService bean。

你可以仔细的思考为什么要在ejbCreate()中重新载入ApplicationContext。由于类是可串行化的，它将要和bean一起被钝化(passivated)，所以，一旦得到了counterService bean，所要做的就是关闭BeanFactory。然而，需要记住的就是你能够在ApplicationContext中配置任何CounterService的实现，包括不可以串行化的CounterService实现。如果你能够保证所有实现都是可串行化的，那么你就能够采用这种方法，或者在ejbCreate()中进行检查以确保实现是真正可串行化的。如果不能保证实现是可串行化的，就必须假定它是不可串行化的，因此，必须在钝化(passivation)的时候卸载BeanFactory，在激活的时候载入它。

与无状态会话bean一样，我们需要在EJB部署描述符中定义ApplicationContext的配置位置，如列表14显示的那样。

列表14.有状态会话bean的部署描述符

<session>
   <description>Counter Service Bena</description>
   <ejb-name>CounterServiceEJB</ejb-name>
   <local-home>
      com.apress.prospring.ch13.ejb.CounterServiceHome</local-home>
   <local>com.apress.prospring.ch13.ejb.CounterServiceLocal</local>
   <ejb-class>com.apress.prospring.ch13.ejb.CounterServiceEJB</ejb-class>
   <session-type>Stateful</session-type>
   <transaction-type>Container</transaction-type>
   <env-entry>
      <env-entry-name>ejb/BeanFactoryPath</env-entry-name>
      <env-entry-type>java.lang.String</env-entry-type>
      <env-entry-value>applicationContext.xml</env-entry-value>
   </env-entry>
</session>

与这个部署描述符相关的是在JBoss部署描述符中的相应条目，如列表15所示。

列表15. CounterServiceEJB的JBoss 部署描述符

<session>
   <ejb-name>CounterServiceEJB</ejb-name>
   <local-jndi-name>ejb/counterService</local-jndi-name>
</session>