基本上访问远程EJB与访问本地EJB差别不大，除了前者使用的是 SimpleRemoteStatelessSessionProxyFactoryBean.当然， 无论是否使用Spring，远程调用的语义都相同，不过，对于使用的场景和错误处理 来说，调用另外一台计算机上不同虚拟机中的对象的方法其处理有所不同。

　　与不使用Spring方式的EJB客户端相比，Spring的EJB客户端有一个额外的 好处。通常如果客户端代码随意在本地EJB和远程EJB的调用之间来回切换，就有 一个问题。这是因为远程接口的方法需要声明其会抛出RemoteException ，然后客户端代码必须处理这种异常，但是本地接口的方法却不需要这样。 如果要把针对本地EJB的代码改为访问远程EJB，就需要修改客户端代码，增加 对RemoteException的处理，反之就需要去掉这样的 异常处理。使用Spring 的远程EJB代理，我们就不再需要在业务方法接口和EJB的 代码实现中声明会抛出RemoteException，而是定义一个 相似的远程接口，唯一不同就是它抛出的是RemoteAccessException， 然后交给代理对象去动态的协调这两个接口。也就是说，客户端代码不再需要与 RemoteException这个显式（checked）异常打交道，实际运行中 所有抛出的异常RemoteException都会被捕获并转换成一个 隐式（non-checked）的RemoteAccessException，它是 RuntimeException的一个子类。这样目标服务端就可以 在本地EJB或远程EJB（甚至POJO）之间随意地切换，客户端不再需要关心甚至 根本不会觉察到这种切换。当然，这些都是可选的，我们并不阻止在业务接口中声明 异常RemoteExceptions.

　　2. 使用Spring提供的辅助类实现EJB组件Spring也提供了一些辅助类来为EJB组件的实现提供便利。它们是为了倡导一些 好的实践经验，比如把业务逻辑放在在EJB层之后的POJO中实现，只把事务隔离和 远程调用这些职责留给EJB.

　　要实现一个无状态或有状态的Session Bean，或消息驱动Bean，我们的实现 可以继承分别继承AbstractStatelessSessionBean， AbstractStatefulSessionBean，和 AbstractMessageDrivenBean/AbstractJmsMessageDrivenBean

　　考虑这个例子：我们把无状态Session Bean的实现委托给普通的Java服务对象。 业务接口的定义如下：

public interface MyComponent {
public void myMethod(...);
...
}
这是简单Java对象实现方式的类：

public class MyComponentImpl implements MyComponent {
public String myMethod(...) {
...
　　}
　　...
}
　　最后是无状态Session Bean自身：

public class MyComponentEJB implements extends AbstractStatelessSessionBean
implements MyComponent {

MyComponent _myComp;

/**
* Obtain our POJO service object from the BeanFactory/ApplicationContext
* @see org.springframework.ejb.support.AbstractStatelessSessionBean#onEjbCreate()
*/
　　protected void onEjbCreate() throws CreateException {
_myComp = (MyComponent) getBeanFactory().getBean(
ServicesConstants.CONTEXT_MYCOMP_ID);
　　}

// for business method, delegate to POJO service impl.
public String myMethod(...) {
return _myComp.myMethod(...);
　　}
　　...
}

　　 Spring为支持EJB而提供的这些基类默认情况下会创建并载入一个BeanFactory （这个例子里，它是ApplicationContext的子类），作为其生命周期的一部分， 供EJB使用（比如像上面的代码那样用来获取POJO服务对象）。载入的工作是通过 一个策略对象完成的，它是BeanFactoryLocator的子类。 默认情况下，实际使用的BeanFactoryLocator的实现类是 ContextJndiBeanFactoryLocator，它根据一个JNDI环境变量 来创建一个ApplicationContext对象（这里是EJB类，路径是 java：comp/env/ejb/BeanFactoryPath）。如果需要改变 BeanFactory或ApplicationContext的载入策略，我们可以在子类中重定义了的 setSessionContext（）方法或具体EJB子类的构造函数中调用 setBeanFactoryLocator（）方法来改变默认使用的 BeanFactoryLocator实现类。具体细节请参考JavaDoc.

　　如JavaDoc中所述，有状态Session Bean在其生命周期中可能会被钝化并重新激活， 如果是不可序列化的BeanFactory或ApplicationContext，由于它们不会被EJB容器保存， 所以还需要手动在ejbPassivate和ejbActivate 这两个方法中分别调用unloadBeanFactory（）和loadBeanFactory， 才能在钝化或激活的时候卸载或载入。

　　有些情况下，要载入ApplicationContext以使用EJB组件， ContextJndiBeanFactoryLocator的默认实现基本上足够了， 不过，当ApplicationContext需要载入多个bean，或这些bean初始化所需的时间或内存 很多的时候（例如Hibernate的SessionFactory的初始化），就有可能出问题，因为 每个EJB组件都有自己的副本。这种情况下，用户会想重载 ContextJndiBeanFactoryLocator的默认实现，并使用其它 BeanFactoryLocator的变体，例如ContextSingleton 或者BeanFactoryLocator，他们可以载入并共享一个 BeanFactory或ApplicationContext来为多个EJB组件或其它客户端所公用。这样做 相当简单，只需要给EJB添加类似于如下的代码：

　　/**
　　* Override default BeanFactoryLocator implementation
　　*
　　* @see javax.ejb.SessionBean#setSessionContext(javax.ejb.SessionContext)
　　*/
　　public void setSessionContext(SessionContext sessionContext) {
　　super.setSessionContext(sessionContext);
　　setBeanFactoryLocator(ContextSingletonBeanFactoryLocator.getInstance());
　　setBeanFactoryLocatorKey(ServicesConstants.PRIMARY_CONTEXT_ID);
　　}

[1] [2]