開發框架－－關于Java 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
1.1. 概念
要調用本地或遠程無狀態Session Bean上的方法，通?？蛻舳说拇a必須 進行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查找的代碼，或者是手寫 的業務委托對象里面冗余的方法，除非它們可以帶來實質性的好處。

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

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

private MyComponent myComponent;

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

原文轉自：http://www.anti-gravitydesign.com