Spring - Java/J2EE Application Framework 应用框架 第 15 章 EJB的存取和实现
第?15?章?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特別有用,現在我們就由此開始討論。
15.1.?訪問EJB
15.1.1.?概念
要調用本地或遠程無狀態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查找的代碼,或者是手寫 的業務委托對象里面冗余的方法,除非它們可以帶來實質性的好處。
15.1.2.?訪問本地的無狀態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。
15.1.3.?訪問遠程的無狀態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。
15.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 AbstractStatelessSessionBeanimplements 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?的用法的詳細信息。
from:?http://docs.huihoo.com/spring/zh-cn/ejb.html
總結
以上是生活随笔為你收集整理的Spring - Java/J2EE Application Framework 应用框架 第 15 章 EJB的存取和实现的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Spring - Java/J2EE A
- 下一篇: Spring - Java/J2EE A