假定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;
}
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
