EJB 3.0注入和查找簡介

介紹

Enterprise JavaBeans Specification v。3.0引入了簡化的，基于注釋的API，用于EJB注入和查找。 EJB 3.0現在是POJO，可以使用簡單的注釋將其注入其他組件（例如EJB和Servlet）。 EJB 3.0是Java EE 6的許多其他基于POJO的規范之一，例如JSR-229“ Java EE平臺的上下文和依賴注入” （以前稱為“ Web Bean”）。 Java EE從未如此簡單！

盡管如此，盡管EJB 3.0注釋使程序員擺脫了組裝Java EE應用程序和連接其所有組件的復雜性，但是您應該注意一些細微之處。其中一些（例如“全局JNDI名稱”）由Enterprise JavaBeans Specification v。3.1解決。同時，在廣泛部署Java EE 6應用程序服務器之前，您可能會面臨編寫依賴于非便攜式應用程序服務器特定行為的代碼的風險。

更糟的是，使用EJB 本地接口時，您可能會遇到一些問題，該接口應該是您自己的bean的應用程序范圍接口。由于本地業務接口實際上暗含本地方法調用（它們使用傳遞引用的語義，并且僅限于同一JVM實例），因此在訪問應用程序中組件的業務接口時，此類接口是首選。通常，此用例將構成Java EE應用程序中的大多數EJB調用。

聲明一個EJB

根據EJB v。3.0簡化的API規范，在聲明會話Bean時，可以根據會話Bean類型使用兩個注釋：

@無狀態
@狀態

這兩個注釋共享兩個公共的注釋元素： name和mappingName 。

名稱

注釋元素名稱定義了bean的“名稱”，并且默認為bean類的非限定名稱。 Bean名稱在包含EJB的模塊范圍內必須唯一。

被映射的名字

EJB 3.0規范將mappingName定義為“會話Bean應該映射到的特定于產品的名稱”。通常，應用程序服務器使用maptedName將會話Bean映射到全局 JNDI名稱。 EJB 3.1規范不贊成使用mappingName元素，而是引入了“便攜式全局JNDI名稱”的概念。

我們將很快看到如何以及何時使用此類元數據。

EJB參考

要建立對EJB的引用，可以使用@EJB批注或標準部署描述符（通過<ejb-ref />和<ejb-local-ref />）。 @EJB注釋定義如下：

@Target({TYPE, METHOD, FIELD}) @Retention(RUNTIME)
public @interface EJB {String name() default "";Class beanInterface() default Object.class;String beanName() default "";String mappedName() default "";String description() default "";
}

名稱

name元素在“應用程序環境”中定義注入的EJB 名稱。因此，EJB 名稱是注入的對象在私有名稱空間java：comp / env中的位置 。它的默認值是帶注釋的類字段或屬性的全限定名稱。在類級別使用@EJB注釋時，名稱元素是必需的。

name元素與部署描述符中的<ejb-ref-name />元素等效：

<ejb-ref><ejb-ref-name>bean name</ejb-ref-name>[...]
</ejb-ref>

bean接口

beanInterface是注入的組件的業務接口類型。默認情況下，它是帶注釋的字段或屬性的類型。在類級別使用@EJB批注時， beanInterface元素是必需的。

beanInterface元素等效于部署描述符中的<remote />或<local />元素：

<ejb-ref><ejb-ref-name>bean name</ejb-ref-name><remote>bean interface</remote>[...]
</ejb-ref>

bean名稱

beanName元素指定通過name元素在@Stateful和@Stateless批注中聲明的bean，或通過<ejb-name />元素在部署描述符中聲明的bean“ name”。當一個以上的EJB在應用程序中實現相同的業務接口時， beanName元素最有用：beanName使開發人員可以在特定模塊中引用特定EJB。在這種情況下使用的語法是：

<ejb module>#<ejb name>

如果在應用程序中只有一個EJB實現所請求的業務接口，那么將自動解析Bean名稱。

beanName元素等效于部署描述符中的<ejb-link />元素：

<ejb-ref><ejb-ref-name>bean name</ejb-ref-name><remote>bean interface</remote><ejb-link>linked ejb</ejb-link>[...]
</ejb-ref>

被映射的名字

與@Stateless和@Stateful批注的maptedName元素一樣， mappedName是特定于產品的元數據，其使用不可移植。

mappingName元素與部署描述符中的<mapped-name />元素等效：

<ejb-ref><ejb-ref-name>bean name</ejb-ref-name><remote>bean interface</remote><ejb-link>linked ejb</ejb-link><mapped-name>mapped name</mapped-name>[...]
</ejb-ref>

那么其他應用程序中的Bean呢？

如果回顧到目前為止描述的機制，您應該注意到，沒有（便攜式）方法可以聲明對應用程序外部bean的依賴關系（EJB引用）。 EJB規范3.1版解決了這個問題，并定義了可移植的全局JNDI名稱 。無需為在兼容的EJB v。3.1容器中為兼容的EJB v。3.0分配可移植的全局JNDI名稱進行更改。

同時，要在應用程序外部連接對EJB的引用，您應該依賴于應用程序服務器提供的機制。

不要依靠不可移植的全局JNDI名稱來查找EJB

如前幾節所述，在EJB v。3.1之前，尚沒有可移植的方式來查找具有全局JNDI名稱的EJB，并且部署者必須依賴于應用程序服務器特定的工具和元數據來在EJB引用和EJB之間建立鏈接。全球JNDI名稱。此外，當在應用程序外部建立對Bean的引用時，這樣的鏈接是必需的。

即使避免使用@EJB注釋元素（或其對應的部署描述符元素）并使用全局JNDI名稱很吸引人，您也應始終依賴EJB引用并在java：comp / env私有名稱空間中進行查找。您的私有名稱空間和映射機制為您提供了將代碼與配置更改隔離開的間接級別。

這也意味著，如果僅限于EJB v。3.0，則應始終使用beanName（<ejb-link />）機制并在私有java：comp / env命名空間中執行查找。很多時候，我聽說過一些開發人員檢查應用程序服務器的全局JNDI樹以推斷出EJB的應用程序服務器全局JNDI命名方案，然后到處都遇到NamingException的故事。出于這個原因，避免使用@EJB mappedName元素，依靠名稱和beanName代替。

例如，某些應用程序服務器使用全局JNDI名稱發布遠程和本地EJB業務接口。其他人根本沒有。 Oracle WebLogic是后者之一。在EJB 3.0版規范，事實上，并不需要一個本地業務接口在全局JNDI樹可用。

查找遠程和本地業務接口

就呼叫者而言，獲取對遠程和本地業務接口的引用的過程應相同。不幸的是，如果您不僅僅依賴于可移植的機制，情況并非總是如此。

始終可以使用beanName機制來解析對EJB本地接口的引用。引用遠程接口并非總是如此，因為此類EJB可能位于應用程序外部。那么，這就是不依賴代碼中全局JNDI名稱的另一個原因：不僅這樣的代碼不能移植，而且還需要您使用不同的策略來查找遠程和本地業務接口（取決于應用程序服務器）。）業務接口類型將不是透明的，并且業務接口類型的更改可能會破壞您的代碼。

建立EJB引用的簡單模式

盡管它們在某些情況下可能是必需的，但應避免EJB查找，并依賴@EJB引用“自動裝配 ”。尊重一些簡單的模式可以確保以完全自動的方式聲明和滿足您的EJB引用：

嘗試減少共享業務接口的EJB的數量 ：如果只有一個EJB在應用程序中實現特定的業務接口，則可以自動聲明EJB引用并使用默認的@EJB注釋進行綁定。
如果共享業務接口改善了您的應用程序設計，請為應用程序的bean定義明確的命名策略并避免重復 ：如果只有一個具有特定名稱的bean，則可以自動聲明EJB引用并使用@EJB（beanName =” [name]”）注釋。如果有多個同名bean，則在聲明引用時將被迫使用@EJB（beanName =” [ejb-module-path]＃[ejb-name]”）語法。
如果需要以編程方式查找EJB引用，請使用@EJB name元素（或<ejb-ref-name />元素）為本地名稱空間中的EJB聲明一個位置，然后使用@EJB beanName將其鏈接到目標EJB。元素（或<ejb-link />元素。）

參考： The Gray Blog上的JCG合作伙伴 Gray 介紹了EJB 3.0注入和查找簡介。

相關文章：