假定MyPOJO是一个接口，实现类(和任何它要求的诸如原始属性和进一步的协作者之类的配置)隐藏在XML bean工厂的定义中。
我们通过一个在标准ejb-jar.xml部署描述符中的名为ejb/BeanFactoryPath的环境变量定义告诉Spring到什么地方去加载XML文档，就像这样：
<session> <ejb-name>myComponent</ejb-name> <local-home>com.test.ejb.myEjbBeanLocalHome</local-home> <local>com.mycom.MyComponentLocal</local> <ejb-class>com.mycom.MyComponentEJB</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>/myComponent-ejb-beans.xml</env-entry-value> </env-entry> </session>
myComponent-ejb-beans.xml文件会被从classpath中加载：在本例中，是在EJB Jar文件的根部。每个EJB能指定它自己的XML文件，所以这个机制能在每个EJB Jar文件中多次使用。
Spring超类实现了EJB的setSessionContext()和ejbCreate()一类的生命周期方法，让应用程序开发者只要选择性地实现Spring的onEjbCreate()方法就可以了。
当EJB 3.0蓝图公布后，我们会对使用Spring IoC容器在那个环境中提供更丰富的依赖注入语义提供支持。我们也同样会将JSR-220 实体/关系映射API作为一个被支持的数据访问API整合进来。
使用EJB
Spring除了让实现EJB更容易外，还让它的使用变得简单了。许多EJB应用程序使用服务定位器和业务代理模式。这比在客户代码中遍布JNDI查找好得多，但它们的一般实现存在明显的缺陷。例如：
- 依赖于服务定位器或业务代理单例的典型EJB调用代码很难测试。
- 在没有一个业务代理的服务定位器模式中，应用程序代码仍然要调用一个EJB home的create()方法，并处理可能的异常。因而它仍然绑定了EJB API和EJB编程模型的复杂性。
- 实现业务代理模式通常会导致明显的代码重复，我们不得不写很多方法来简单地调用同一个EJB方法。
为这些和其他一些原因，传统的EJB访问(就像Sun Adventure Builder 和OTN J2EE 虚拟大卖场里演示的)会降低生产力并带来显著的复杂度。
Spring通过引入少量代码业务代理在这方面先行一步。有了Spring你不再需要在手工编写的业务代理中写另外的服务定位器、JNDI查找或重复方法除非你加入了真正的价值。
举例来说，想象我们有一个使用本地EJB的web控制器。我们会遵循最佳实践并使用EJB业务方法接口模式，所以EJB本地接口要扩展一个非EJB特有的业务方法接口。(这样做的一个主要原因是确保本地接口和bean实现类的自动同步。)我们称这个业务方法接口为MyComponent。当然我们也需要实现本地home接口并提供一个实现了SessionBean和MyComponent 业务方法接口的bean实现类。
有了Spring EJB访问，我们为挂接我们的web 层控制器和EJB实现所需的唯一的Java编码就是暴露控制器上的一个MyComponent 的setter 方法。这会像一个实例变量那样保存引用：
private MyComponent myComponent;
public void setMyComponent(MyComponent myComponent) {
this.myComponent = myComponent;
}
延伸阅读
文章来源于领测软件测试网 https://www.ltesting.net/
