首页 > 代码库 > Spring之Enterprise JavaBeans (EJB) integration

Spring之Enterprise JavaBeans (EJB) integration

原文地址:需要翻墙

https://translate.google.com/translate?hl=zh-CN&sl=zh-CN&tl=zh-CN&u=http%3A%2F%2Fdocs.spring.io%2Fspring-framework%2Fdocs%2Fcurrent%2Fspring-framework-reference%2Fhtml%2Fejb.html&sandbox=1


22.1 介绍

作为一个轻量级容器,Spring被认为是EJB的替代品。我们确实相信,如果没有太多的应用和使用情况下,Spring作为一个容器,结合其在事物,ORM和数据访问方面丰富的支持功能,这比使用EJB和EJB容器完成同等功能上是一个更好的选择。


然而,重要的一点是使用Spring就不是不使用EJB了。实际上,Spring使得访问EJBs和实现EJBs和内部功能上更加容易。另外,使用Spring访问由EJBs提供的业务允许那些业务的实现类之后轻松地在本地EJB,远程EJB,或者POJO变量之间转换,而不需要改变客户端的代码。


在这一章中,将看到Spring如何帮助你访问和实现EJBs。Spring提供了专门的value来访问无状态的会话beans(SLSBs)。


22.2 访问EJBs


22.2.1 概念


为调用本地或远程无状态会话bean的方法,客户端代码必须一般地执行一个JNDI查找来获取本地或远程的EJB的主项目,稍后在那个对象上调用create方法来获取真正的远程或本地的EJB对象。这里EJB会调用一个或更多的方法。


为避免重复的低级代码,许多EJB应用程序采用service Locator(服务定位器)和业务委托模式。这些都比通过客户端代码执行JNDI查询好得多,但是了它们一般的实现还有明显的缺陷。例如:

  • 一般地使用EJBs依赖服务定位或业务委托单例,使得很难测试。
  • 在使用服务定位而不使用业务委托的情况下,应用程序代码仍旧以调用EJB的create()方法结束并处理导致的异常。它仍旧保留了与EJB API耦合并且保留了复杂的EJB 编程模式
  • 实现业务委托模式一般地导致了明显的代码重复,这里我们得写许多方法,这些仅仅调用EJB相同的一个方法。

Spring的方式是允许代理对象的创建和使用,一般在Spring容器的内部配置,可以是无代码的业务委托。你不需要写另一个服务定位器,另一个JNDI查找,或者一个手编程序的业务委托的重复方法,除非你在这样的代码中确实需要添加实际的值。


22.2.2 访问本地SLSBs

假设我们有一个web控制器,其需要使用一个本地的EJB。我们将按照最好的实践并使用EJB业务方法接口模式,这样EJB的本地接口继承了一个非EJB-指定的业务方法接口。称这个业务方法接口为MyComponent。


<span style="font-size:14px;">public interface MyComponent {  
    ...  
} </span>

使用业务方法接口模式的主要原因之一是确保本地接口和bean实现类之间的异步是原子的。另一个原因是稍后使得我们转换成业务的一个POJO实现更加容器,如果应用程序对此很关注的话。当然了我们也需要实现本地home接口并且提供一个实现类实现SessionBean和MyComponent业务方法接口。现在我们需要做的Java编码工作(将web层控制器连接到EJB的实现类)是暴露控制器MyComponent类型的一个setter方法。这样将节省一个引用,其在控制器内作为一个实例变量。



<span style="font-size:14px;">    private MyComponent myComponent;  
      
    public void setMyComponent(MyComponent myComponent) {  
        this.myComponent = myComponent;  
    }  </span>

我们可以随后在这个控制器的任何业务方法中使用这个实例变量。现在假设我们从一个Spring容器的外部获取了我们的控制器对象,在同一上下文中,我们可以配置一个LocalStatelessSessionProxyFactoryBean实例,这是一个EJB代理对象。这个代理的配置,和这个控制器的myComponent属性的设置,在一个配置条目中处理。
<span style="font-size:14px;">    <bean id="myComponent"  
            class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">  
        <property name="jndiName" value=http://www.mamicode.com/"ejb/myBean"/>  >

借助Spring AOP框架,这个场景幕后有许多事情发生,虽然你可以不强制使用AOP概念来享受你要的结果。myComponent bean定义创建了EJB的代理,其实现了业务方法接口。EJB本地home在启动的时候缓存,所以仅有单一的JNDI查询。每次调用EJB时,代理调用本地EJB的classname方法并调用EJB对应的业务方法。


myController bean定义为EJB代理设置了控制器类myComponent属性。


另外,如果有很多这样代理定义的情况下,考虑在Spring的"jee"命名空间内使用 <jee:local-slsb>配置元素。

<span style="font-size:14px;">    <jee:local-slsb id="myComponent" jndi-name="ejb/myBean"  
            business-interface="com.mycom.MyComponent"/>  
      
    <bean id="myController" class="com.mycom.myController">  
        <property name="myComponent" ref="myComponent"/>  
    </bean>  </span>

EJB访问机制简化了应用程序代码:web层代码(其他EJB客户端)不依赖EJB的使用。如果我们想使用一个POJO,或者一个虚拟对象或者其他的测试存根代替这个EJB引用,我们只需要简单地改变myComponent bean定义,而不需要改变一行Java 代码。此外,我们不必去写一个单行的JNDI查询或者其他的EJB垂直代码,来作为我们应用程序的部分。



在真实应用程序中的基准测试程序和经验指明这种方式的执行开销(涉及到目标EJB的反射调用)是最低的,并在一般使用中是无法察觉的。记住,我们不想做任何对于EJBs的细粒度调用,因为在应用程序服务器关联EJB底层中会增加开销。


在JNDI查询中有一个警告,在一个bean容器中,这个类一般以单例使用(这里没有理由设置为prototype)。然而,如果那个bean预先实例化为单例(犹如做不同的XMLApplicationContext 变量),如果bean容器在EJB容器加载目标EJB之前,你可能会遇到问题。这是因为JNDI查询将在这个类的init()方法中执行并在之后缓存,但是了EJB还没有绑定到目标位置上。虽然这个解决方案没有预先实例化这个工厂对象,但是允许在第一次使用的时候创建。在这个XML容器中,通过lazy-init属性控制。


虽然这个不是Spring使用者最感兴趣的地方,但那些使用EJBs做程序化AOP编程可能想看看LocalSlsbInvokerInterceptor。


Spring之Enterprise JavaBeans (EJB) integration