如本系列前面部分所述，EJB 3.0版规范的主要缺点是缺少可移植的全局JNDI名称。 这意味着没有可移植的方式将EJB引用链接到应用程序外部的Bean。

EJB v。3.1规范用自己的话填补了这一定义：

“一个标准化的全局JNDI名称空间和一系列相关的名称空间，它们映射到Java EE应用程序的各个范围。”

此博客文章将为您提供EJB v.3.1规范定义的Global JNDI Access的概述。

命名空间和范围

EJB v。3.1规范使用其自己的范围定义了三个不同的名称空间：

• 全球。
• 应用。
• 模块。

该规范要求兼容的容器使用所需的JNDI名称注册所有会话Bean。 这样的标准化名称是可移植的，您的应用程序组件将能够使用跨应用程序服务器可移植的名称来建立对EJB的引用。

全球

全局名称空间中的名称将可以在任何应用程序中被代码访问，并符合以下语法：

java：global [/ <app-name>] / <module-name> / <bean-name> [！<interface-fqn>]

<app-name>是在其标准部署描述符（ application.xml ）中指定的Java EE应用程序的名称，或者默认情况下是已部署EAR归档文件的基本名称。 仅当会话EJB部署在Java EE应用程序EAR文件中时，才使用此路径片段。

如果会话EJB部署在EAR文件中，则其<module-name>是Java EE模块的路径名，该Java EE模块包含EAR文件中的bean（无扩展名）。 如果将会话bean部署为JAR文件中的独立Java EE组件或WAR文件中的Java EE Web模块的一部分（Java EE 6规范现在允许），则<module-name>是档案名称（不带扩展名）。 可以通过组件的标准部署描述符（ ejb-jar.xml或web.xml ）的<module-name>元素覆盖<module-name>值。

<bean-name>是EJB名称，由本博文前面部分中描述的机制指定。

<interface-fqn>部分是EJB业务接口的标准名称。

容器必须为EJB及其无接口视图实现的每个本地和远程业务接口注册一个JNDI全局条目。

具有一个业务接口或无接口视图的会话EJB

如果EJB仅实现一个业务接口或仅具有无接口视图，则还需要容器使用以下JNDI名称注册这种视图：

java：global [/ <应用程序名称>] / <模块名称> / <bean名称>

应用

应用程序名称空间中的名称只能由同一应用程序中的代码访问，并且符合以下语法：

java：app / <模块名称> / <bean-名称> [！<interface-fqn>]

每个路径片段保留与上一节中为全局名称空间JNDI名称语法描述的相同含义。

上一部分中描述的兼容容器的发布规则相同。

模组

模块名称空间中的名称只能由同一模块中的代码访问，并且符合以下语法：

java：module / <bean-name> l [！<interface-fqn>]

同样，每个路径片段都保留了针对全局名称空间JNDI名称描述的相同含义。
全局命名空间部分中描述的兼容容器的发布规则相同。

本地客户

这可能是重要的发现，虽然本地接口（和无界面视图）公布的全球JNDI名称，这并不意味着这样的接口将是在另一个JVM中运行的组件访问。

结论

EJB v。3.1规范以及Java EE 6平台中的其他规范带来了简单性，并为开发人员的工具箱添加了许多新功能和工具。 “全局JNDI名称”是一个杰出的功能，尽管很简单，因为它最终填补了该规范以前的版本以及整个Java EE平台长期存在的可移植性限制。

EJB 3.0和EJB 3.1提供了功能强大，可移植但简单的组件模型来构建企业应用程序。 “ EJB糟透了 ”的日子已经过去了，但是只有时间才能证明这项技术是否会重新获得我们（开发人员）的信任。

就我自己而言，我对Java EE 6，EJB，CDI bean，NetBeans或JDeveloper之类的IDE（尽管后者尚不支持EJB 3.1）提供的良好支持以及所有的规范感到非常满意。建立这个古老的平台

参考： The Gray Blog上来自我们的JCG合作伙伴 Gray的 EJB 3.1全局JNDI访问 。

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