EJB的存取和實現

作為輕量級的容器，Spring常常被認為是EJB的替代品。我們也相信，對於很多 （不一定是絕大多數）應用和用例，相對於通過EJB容器來實現相同的功能而言， Sping作為容器，加上它在事務，ORM和JDBC存取這些領域中豐富的功能支持， Spring的確是更好的選擇。

不過，需要特別注意的是，使用了Spring並不是說我們就不能用EJB了， 實際上，Spring大大簡化了從中訪問和實現EJB組件或只實現（EJB組件）其功能的復雜性。 另外，如果通過Spring來訪問EJB組件服務，以後就可以在本地EJB組件，遠程EJB組件， 或者是POJO（簡單Java對象）這些變體之間透明地切換服務的實現，而不需要修改 客戶端的代碼。

本章，我們來看看Spring是如何幫助我們訪問和實現EJB組件的。尤其是在訪問 無狀態Session Bean（SLSBs）的時候，Spring特別有用，現在我們就由此開始討論。

訪問EJB

概念

要調用本地或遠程無狀態Session Bean上的方法，通常客戶端的代碼必須 進行JNDI查找，得到（本地或遠程的）EJB Home對象，然後調用該對象的"create" 方法，才能得到實際的（本地或遠程的）EJB對象。前後調用了不止一個EJB組件 上的方法。

為了避免重復的底層調用，很多EJB應用使用了服務定位器（Service Locator） 和業務委托（Bussiness Delegate）模式，這樣要比在客戶端代碼中到處進行JNDI 查找更好些，不過它們的常見的實現都有明顯的缺陷。例如：

通常，若是依賴於服務定位器或業務代理單件來使用EJB，則很難對代碼進 行測試。

在僅使用了服務定位器模式而不使用業務委托模式的情況下，應用程序 代碼仍然需要調用EJB Home組件的create方法，還是要處理由此引入的異常。 導致代碼仍然保留了與EJB API的耦合性以及EJB編程模型的復雜性。

實現業務委托模式通常會導致大量的冗余代碼，因為我們不得不編寫 很多方法，而它們所做的僅僅是調用EJB組件的同名方法。

Spring采用的方法是允許創建並使用代理對象，一般是在Spring的 ApplicationContext或BeanFactory裡面進行配置，這樣就和業務代理類似，只需要 少量的代碼。我們不再需要另外編寫額外的服務定位器或JNDI查找的代碼，或者是手寫 的業務委托對象裡面冗余的方法，除非它們可以帶來實質性的好處。

訪問本地的無狀態Session Bean（SLSB）

假設有一個web控制器需要使用本地EJB組件。我們遵循前人的實踐經驗， 於是使用了EJB的業務方法接口（Business Methods Interface）模式，這樣， 這個EJB組件的本地接口就擴展了非EJB特定的業務方法接口。讓我們假定這個 業務方法接口叫MyComponent。

public interface MyComponent {

...

}

（使用業務方法接口模式的一個主要原因就是為了保證本地接口和bean的實現類 之間方法簽名的同步是自動的。另外一個原因是它使得稍後我們改用基於POJO（簡單Java對象） 的服務實現更加容易，只要這樣的改變是有利的。當然，我們也需要實現 本地Home接口，並提供一個Bean實現類，使其實現接口SessionBean和業務方法接口 MyComponent。現在為了把我們Web層的控制器和EJB的實現鏈接起來，我們唯一要寫 的Java代碼就是在控制器上公布一個形參為MyComponent的setter方法。這樣就可以 把這個引用保存在控制器的一個實例變量中。

private MyComponent myComponent;
public void setMyComponent(MyComponent myComponent) {
this.myComponent = myComponent;
}

然後我們可以在控制器的任意業務方法裡面使用這個實例變量。假設我們現在 從Spring的ApplicationContext或BeanFactory獲得該控制器對象，我們就可以在 同一個上下文中配置一個LocalStatelessSessionProxyFactoryBean 的實例，它將作為EJB組件的代理對象。這個代理對象的配置和控制器的屬性 myComponent的設置是使用一個配置項完成的，如下所示：

<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框架，我們甚至不必知道這些概念，一樣可以享用它的結果。Bean myComponent 的定義中創建了一個該EJB組件的代理對象，它實現了業務方法接口。這個EJB組件的 本地Home對象在啟動的時候就被放到了緩存中，所以只需要執行一次JNDI查找即可。 每當EJB組件被調用的時候，這個代理對象就調用本地EJB組件的create方法，並調用 該EJB組件的相應的業務方法。

在Bean myController的定義中，控制器類的屬性 myController的值被設置為上面代理對象。

這樣的EJB組件訪問方式大大簡化了應用程序代碼：Web層（或其他EJB客戶端） 的代碼不再依賴於EJB組件的使用。如果我們想把這個EJB的引用替換為一個POJO， 或者是模擬用的對象或其他測試組件，我們只需要簡單地修改Bean myComponent 的定義中僅僅一行Java代碼，此外，我們也不再需要在應用程序中編寫任何JNDI查找 或其它EJB相關的代碼。

評測和實際應用中的經驗表明，這種方式的性能負荷極小，（盡管其中 使用了反射方式以調用目標EJB組件的方法），通常的使用中我們幾乎覺察不出。請記住 我們並不想頻繁地調用EJB組件的底層方法，雖然如此，有些性能代價是與應用服務器 中EJB的基礎框架相關的。

關於JNDI查找有一點需要注意。在Bean容器中，這個類通常最好用作單件 （沒理由使之成為原型）。不過，如果這個Bean容器會預先實例化單件（類似XML ApplicationContext的變體的行為），如果在EJB容器載入目標EJB前載入bean容器， 我們就可能會遇到問題。因為JNDI查找會在該類的init方法中被執行並且緩存結果， 這樣就導致該EJB不能被綁定到目標位置。解決方案就是不要預先實例化這個工廠對象， 而允許它在第一次用到的時候再創建，在XML容器中，這是通過屬性 lazy-init來控制的。

盡管大部分Spring的用戶不會對這些感興趣，但那些對EJB進行AOP的具體應用 的用戶則會想看看LocalSlsbInvokerInterceptor。

訪問遠程的無狀態Session Bean（SLSB）

基本上訪問遠程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。

使用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);
}

請參考相應的JavaDoc來獲取關於BeanFactoryLocator， ContextSingleton以及BeanFactoryLocator 的用法的詳細信息。