我正在从EJB in Action这本书中学习EJB 3，这本书的第5章讨论了环境命名上下文(ENC)。它是这样写的:
如果您知道JNDI引用在EJB 2中是如何工作的，那么您就很熟悉环境命名上下文(ENC)。ENC允许的可移植性应用程序，而不必依赖全局JNDI名称。全局JNDI应用服务器实现之间的资源名称不同，ENC允许您使用以。开头的JNDI位置java:comp/env/而不是硬编码实际的全局JNDI名称。EJB3基本上假设代码中使用的所有JNDI名称都是本地的引用并自动在名称前加上java:comp/env/前缀。
我没有得到全局JNDI名称是什么意思?为什么不同的应用服务器会有不同?
我将问题标记为EJB2和EJB 3，因为引用引用了这两个版本。如果你不这么认为，请随意编辑
全局JNDI名称使用默认JNDI上下文中的名称。例如，在WebSphere Application Server上，远程ejb默认绑定到ejb/<app>/<module>/<bean>#<interface>。如果在应用程序中硬编码此查找字符串，则应用程序将无法移植到其他应用程序服务器(可能对默认名称使用不同的方案)，如果目标应用程序或模块名称发生更改，甚至无法移植到相同的WebSphere应用程序服务器。
EE中的解决方案是让应用程序声明EJB引用，该引用将在java:comp/env上下文中使用您选择的名称。当部署人员在服务器上安装应用程序时，他们可以将java:comp/env名称绑定到适合该环境的全局JNDI名称。实际上，所有EE资源(数据源、String/int/boolean配置值等)都使用相同的模式，如果使用得当，它是EE平台的优势之一。
如果没有更多的上下文，我不能告诉你上面的摘录是想说什么。也许它指的是EJBContext.lookup方法，它是相对于java:comp/env进行查找的有效快捷方式。
作为最后的题外话，我要注意EJB 3.1为EJB绑定定义了java:global/<app>/<module>/<bean>!<interface>的标准位置。无论如何，在跨应用程序(甚至是跨模块，如果您不能完全控制将包含EJB客户机的应用程序)进行查找时，使用EJB引用仍然是最佳实践。