ejb 2.0 3.0_EJB 3.0注入和查找简介

ejb 2.0 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注释定义如下：

@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元素与部署描述符中的元素等效：

  bean name
  [...]

bean接口

beanInterface是注入的组件的业务接口类型。 默认情况下，它是带注释的字段或属性的类型。 在类级别使用@EJB批注时， beanInterface元素是必需的。

beanInterface元素等同于部署描述符中的或元素：

  bean name
  bean interface
  [...]

bean名称

beanName元素指定通过name元素在@Stateful和@Stateless批注中声明的bean，或通过元素在部署描述符中声明的bean。 当一个以上的EJB在应用程序中实现相同的业务接口时， beanName元素最有用：beanName使开发人员可以在特定模块中引用特定EJB。 在这种情况下使用的语法是：

#

如果只有一个EJB在应用程序中实现请求的业务接口，那么将自动解析Bean名称。

beanName元素等效于部署描述符中的元素：

  bean name
  bean interface
  linked ejb
  [...]

被映射的名字

与@Stateless和@Stateful批注的maptedName元素一样， mappedName是特定于产品的元数据，其使用不可移植。

mappingName元素与部署描述符中的元素等效：

  bean name
  bean interface
  linked ejb
  mapped name
  [...]

那么其他应用程序中的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（）机制并在私有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的位置，然后使用@EJB beanName将其链接到目标EJB。元素（或元素。）

参考： The Gray Blog上的JCG合作伙伴 Gray 介绍了EJB 3.0注入和查找简介 。

相关文章 ：

• 基本的EJB参考，注入和查找
• EJB程序化查找
• 使用Oracle WebLogic对应用程序外部的EJB的引用
• EJB 3.1全局JNDI访问
• GWT EJB3 Maven JBoss 5.1集成教程
• Java泛型快速教程
• JVM如何处理锁

翻译自: https://www.javacodegeeks.com/2011/08/introduction-to-ejb-30-injection-and.html

ejb 2.0 3.0