Java EJB容器的存取和實現(xiàn)

2019-11-18 11:54:53

字體：大中小

供稿：網(wǎng)友

　　作為輕量級的容器，SPRing經(jīng)常被認為是EJB的替代品。我們也相信，對于很多（不一定是絕大多數(shù)）應(yīng)用和用例，相對于通過EJB容器來實現(xiàn)相同的功能而言， Sping作為容器，加上它在事務(wù)，ORM和JDBC存取這些領(lǐng)域中豐富的功能支持， Spring的確是更好的選擇。
　　
　　不過，需要非凡注重的是，使用了Spring并不是說我們就不能用EJB了，實際上，Spring大大簡化了從中訪問和實現(xiàn)EJB組件或只實現(xiàn)（EJB組件）其功能的復雜性。另外，假如通過Spring來訪問EJB組件服務(wù)，以后就可以在本地EJB組件，遠程EJB組件，或者是POJO（簡單java對象）這些變體之間透明地切換服務(wù)的實現(xiàn)，而不需要修改客戶端的代碼。
　　
　　本章，我們來看看Spring是如何幫助我們訪問和實現(xiàn)EJB組件的。尤其是在訪問無狀態(tài)session Bean（SLSBs）的時候，Spring非凡有用，現(xiàn)在我們就由此開始討論。
　　
　　訪問EJB 1.1. 概念要調(diào)用本地或遠程無狀態(tài)Session Bean上的方法，通常客戶端的代碼必須進行JNDI查找，得到（本地或遠程的）EJB Home對象，然后調(diào)用該對象的"create" 方法，才能得到實際的（本地或遠程的）EJB對象。前后調(diào)用了不止一個EJB組件上的方法。
　　
　　為了避免重復的底層調(diào)用，很多EJB應(yīng)用使用了服務(wù)定位器（Service Locator）和業(yè)務(wù)委托（Bussiness Delegate）模式，這樣要比在客戶端代碼中到處進行JNDI 查找更好些，不過它們的常見的實現(xiàn)都有明顯的缺陷。例如：
　　
　　通常，若是依靠于服務(wù)定位器或業(yè)務(wù)代理單件來使用EJB，則很難對代碼進行測試。
　　
　　在僅使用了服務(wù)定位器模式而不使用業(yè)務(wù)委托模式的情況下，應(yīng)用程序代碼仍然需要調(diào)用EJB Home組件的create方法，還是要處理由此引入的異常。導致代碼仍然保留了與EJB API的耦合性以及EJB編程模型的復雜性。
　　
　　實現(xiàn)業(yè)務(wù)委托模式通常會導致大量的冗余代碼，因為我們不得不編寫很多方法，而它們所做的僅僅是調(diào)用EJB組件的同名方法。
　　
　　Spring采用的方法是答應(yīng)創(chuàng)建并使用代理對象，一般是在Spring的 applicationContext或BeanFactory里面進行配置，這樣就和業(yè)務(wù)代理類似，只需要少量的代碼。我們不再需要另外編寫額外的服務(wù)定位器或JNDI查找的代碼，或者是手寫的業(yè)務(wù)委托對象里面冗余的方法，除非它們可以帶來實質(zhì)性的好處。
　　
　　1.2. 訪問本地的無狀態(tài)Session Bean（SLSB）
　　假設(shè)有一個web控制器需要使用本地EJB組件。我們遵循前人的實踐經(jīng)驗，于是使用了EJB的業(yè)務(wù)方法接口（Business Methods Interface）模式，這樣，這個EJB組件的本地接口就擴展了非EJB特定的業(yè)務(wù)方法接口。讓我們假定這個業(yè)務(wù)方法接口叫MyComponent.
　　
　　public interface MyComponent {……
　　}（使用業(yè)務(wù)方法接口模式的一個主要原因就是為了保證本地接口和bean的實現(xiàn)類之間方法簽名的同步是自動的。另外一個原因是它使得稍后我們改用基于POJO（簡單Java對象）的服務(wù)實現(xiàn)更加輕易，只要這樣的改變是有利的。當然，我們也需要實現(xiàn) 本地Home接口，并提供一個Bean實現(xiàn)類，使其實現(xiàn)接口SessionBean和業(yè)務(wù)方法接口 MyComponent.現(xiàn)在為了把我們Web層的控制器和EJB的實現(xiàn)鏈接起來，我們唯一要寫的Java代碼就是在控制器上公布一個形參為MyComponent的setter方法。這樣就可以把這個引用保存在控制器的一個實例變量中。
　　
　　private MyComponent myComponent;

public void setMyComponent(MyComponent myComponent) {
    this.myComponent = myComponent;
}
　　然后我們可以在控制器的任意業(yè)務(wù)方法里面使用這個實例變量。假設(shè)我們現(xiàn)在從Spring的ApplicationContext或BeanFactory獲得該控制器對象，我們就可以在同一個上下文中配置一個LocalStatelessSessionProxyFactoryBean 的實例，它將作為EJB組件的代理對象。這個代理對象的配置和控制器的屬性 myComponent的設(shè)置是使用一個配置項完成的，如下所示：

<bean id="myComponent"
      class="org.springframework.ejb.access.LocalStatelessSessionProxyFactoryBean">
    <property name="jndiName"><value>myComponent</value></property>
    <property name="businessInterface"><value>com.mycom.MyComponent</value></property>
</bean>

<bean id="myController" class = "com.mycom.myController">
    <property name="myComponent"><ref bean="myComponent"/></property>
</bean>
　　這些看似簡單的代碼背后隱藏了很多復雜的處理，比如默默工作的Spring AOP框架，我們甚至不必知道這些概念，一樣可以享用它的結(jié)果。Bean myComponent 的定義中創(chuàng)建了一個該EJB組件的代理對象，它實現(xiàn)了業(yè)務(wù)方法接口。這個EJB組件的本地Home對象在啟動的時候就被放到了緩存中，所以只需要執(zhí)行一次JNDI查找即可。每當EJB組件被調(diào)用的時候，這個代理對象就調(diào)用本地EJB組件的create方法，并調(diào)用該EJB組件的相應(yīng)的業(yè)務(wù)方法。
　　
　　在Bean myController的定義中，控制器類的屬性 myController的值被設(shè)置為上面代理對象。
　　
　　這樣的EJB組件訪問方式大大簡化了應(yīng)用程序代碼：Web層（或其他EJB客戶端）的代碼不再依靠于EJB組件的使用。假如我們想把這個EJB的引用替換為一個POJO，或者是模擬用的對象或其他測試組件，我們只需要簡單地修改Bean myComponent 的定義中僅僅一行Java代碼，此外，我們也不再需要在應(yīng)用程序中編寫任何JNDI查找或其它EJB相關(guān)的代碼。
　　
　　評測和實際應(yīng)用中的經(jīng)驗表明，這種方式的性能負荷極小，（盡管其中使用了反射方式以調(diào)用目標EJB組件的方法），通常的使用中我們幾乎覺察不出。請記住我們并不想頻繁地調(diào)用EJB組件的底層方法，雖然如此，有些性能代價是與應(yīng)用服務(wù)器中EJB的基礎(chǔ)框架相關(guān)的。
　　
　　關(guān)于JNDI查找有一點需要注重。在Bean容器中，這個類通常最好用作單件（沒理由使之成為原型）。不過，假如這個Bean容器會預先實例化單件（類似xml ApplicationContext的變體的行為），假如在EJB容器載入目標EJB前載入bean容器，我們就可能會碰到問題。因為JNDI查找會在該類的init方法中被執(zhí)行并且緩存結(jié)果，這樣就導致該EJB不能被綁定到目標位置。解決方案就是不要預先實例化這個工廠對象，而答應(yīng)它在第一次用到的時候再創(chuàng)建，在XML容器中，這是通過屬性 lazy-init來控制的。
　　
　　盡管大部分Spring的用戶不會對這些感愛好，但那些對EJB進行AOP的具體應(yīng)用的用戶則會想看看LocalSlsbInvokerInterceptor.
　　
　　1.3. 訪問遠程的無狀態(tài)Session Bean（SLSB）
　　基本上訪問遠程EJB與訪問本地EJB差別不大，除了前者使用的是 SimpleRemoteStatelessSessionProxyFactoryBean.當然，無論是否使用Spring，遠程調(diào)用的語義都相同，不過，對于使用的場景和錯誤處理來說，調(diào)用另外一臺計算機上不同虛擬機中的對象的方法其處理有所不同。
　　
　　與不使用Spring方式的EJB客戶端相比，Spring的EJB客戶端有一個額外的好處。通常假如客戶端代碼隨意在本地EJB和遠程EJB的調(diào)用之間往返切換，就有一個問題。這是因為遠程接口的方法需要聲明其會拋出RemoteException ，然后客戶端代碼必須處理這種異常，但是本地接口的方法卻不需要這樣。假如要把針對本地EJB的代碼改為訪問遠程EJB，就需要修改客戶端代碼，增加對RemoteException的處理，反之就需要去掉這樣的異常處理。使用Spring 的遠程EJB代理，我們就不再需要在業(yè)務(wù)方法接口和EJB的代碼實現(xiàn)中聲明會拋出RemoteException，而是定義一個相似的遠程接口，唯一不同就是它拋出的是RemoteAccessException，然后交給代理對象去動態(tài)的協(xié)調(diào)這兩個接口。也就是說，客戶端代碼不再需要與 RemoteException這個顯式（checked）異常打交道，實際運行中所有拋出的異常RemoteException都會被捕捉并轉(zhuǎn)換成一個隱式（non-checked）的RemoteAccessException，它是 RuntimeException的一個子類。這樣目標服務(wù)端就可以在本地EJB或遠程EJB（甚至POJO）之間隨意地切換，客戶端不再需要關(guān)心甚至根本不會覺察到這種切換。當然，這些都是可選的，我們并不阻止在業(yè)務(wù)接口中聲明異常RemoteExceptions.
　　
　　2. 使用Spring提供的輔助類實現(xiàn)EJB組件Spring也提供了一些輔助類來為EJB組件的實現(xiàn)提供便利。它們是為了倡導一些好的實踐經(jīng)驗，比如把業(yè)務(wù)邏輯放在在EJB層之后的POJO中實現(xiàn)，只把事務(wù)隔離和遠程調(diào)用這些職責留給EJB.
　　
　　要實現(xiàn)一個無狀態(tài)或有狀態(tài)的Session Bean，或消息驅(qū)動Bean，我們的實現(xiàn) 可以繼續(xù)分別繼續(xù)AbstractStatelessSessionBean， AbstractStatefulSessionBean，和 AbstractMessageDrivenBean/AbstractJmsMessageDrivenBean
　　
　　考慮這個例子：我們把無狀態(tài)Session Bean的實現(xiàn)委托給普通的Java服務(wù)對象。業(yè)務(wù)接口的定義如下：
　　
public interface MyComponent {
    public void myMethod(...);
    ...
}
　　這是簡單Java對象實現(xiàn)方式的類：

public class MyComponentImpl implements MyComponent {
    public String myMethod(...) {
        ...
    }
    ...
}
　　最后是無狀態(tài)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而提供的這些基類默認情況下會創(chuàng)建并載入一個BeanFactory （這個例子里，它是ApplicationContext的子類），作為其生命周期的一部分，供EJB使用（比如像上面的代碼那樣用來獲取POJO服務(wù)對象）。載入的工作是通過一個策略對象完成的，它是BeanFactoryLocator的子類。默認情況下，實際使用的BeanFactoryLocator的實現(xiàn)類是 ContextJndiBeanFactoryLocator，它根據(jù)一個JNDI環(huán)境變量來創(chuàng)建一個ApplicationContext對象（這里是EJB類，路徑是 java：comp/env/ejb/BeanFactoryPath）。假如需要改變 BeanFactory或ApplicationContext的載入策略，我們可以在子類中重定義了的 setSessionContext（）方法或具體EJB子類的構(gòu)造函數(shù)中調(diào)用 setBeanFactoryLocator（）方法來改變默認使用的 BeanFactoryLocator實現(xiàn)類。具體細節(jié)請參考JavaDoc.
　　
　　如JavaDoc中所述，有狀態(tài)Session Bean在其生命周期中可能會被鈍化并重新激活，假如是不可序列化的BeanFactory或ApplicationContext，由于它們不會被EJB容器保存，所以還需要手動在ejbPassivate和ejbActivate 這兩個方法中分別調(diào)用unloadBeanFactory（）和loadBeanFactory，才能在鈍化或激活的時候卸載或載入。
　　
　　有些情況下，要載入ApplicationContext以使用EJB組件， ContextJndiBeanFactoryLocator的默認實現(xiàn)基本上足夠了，不過，當ApplicationContext需要載入多個bean，或這些bean初始化所需的時間或內(nèi)存很多的時候（例如Hibernate的SessionFactory的初始化），就有可能出問題，因為每個EJB組件都有自己的副本。這種情況下，用戶會想重載 ContextJndiBeanFactoryLocator的默認實現(xiàn)，并使用其它 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);
   }

上一篇：核心API最佳實踐——JDK日志分級

下一篇：利用JAVA語言深度控制Word