JNDI 起源
转自：http://www.ibm.com/developerworks/cn/java/j-jndi/JNDI 在 J2EE 中的角色
把您从麻烦中解脱
打印本页
<noscript></noscript><script type="text/javascript"></script>
将此页作为电子邮件发送
<noscript></noscript><!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- this content will be automatically generated across all content areas --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->级别： 初级
Kirk Pepperdine (kirk@javaperformancetuning.com), 首席技术官, JavaPerformanceTuning.com
Joseph Ottinger (joeo@enigmastation.com), 咨询顾问
2005 年 1 月 13 日
掌握 J2EE 是件令人生畏的事，因为它包含的技术和缩略语在不断地增长。Java 命名和目录接口（Java Naming and Directory Interface，JNDI）从一开始就一直是 Java 2 平台企业版（JEE）的核心，但是 J2EE 开发新手经常用不好它。本文将消除 JNDI 在 J2EE 应用程序中所扮演角色的神秘性，并展示它如何帮助应用程序从部署细节中解脱出来。<!--START RESERVED FOR FUTURE USE INCLUDE FILES--><!-- include java script once we verify teams wants to use this and it will work on dbcs and cyrillic characters --><!--END RESERVED FOR FUTURE USE INCLUDE FILES-->
虽然 J2EE 平台提高了普通企业开发人员的生活水平，但是这种提高是以不得不学习许多规范和技术为代价的，这些规范和技术则是 J2EE 为了成为无所不包的分布式计算平台而整合进来的。Dolly Developer 是众多开发人员中的一员，她已经发现了一个特性，该特性有助于缓解随企业级应用程序部署而带来的负担，这个特性就是 JNDI，即 Java 命名与目录接口（Java Naming and Directory Interface）。让我们来看看 Dolly 在没有 JNDI 的时候是怎么做的，以及她是如何正确地应用 JNDI 来改善其状况的。
回页首
回页首
回页首
超越数据源
当然，J2EE 中的资源并不局限于 JDBC 数据源。引用的类型有很多，其中包括资源引用（已经讨论过）、环境实体和 EJB 引用。特别是 EJB 引用，它暴露了 JNDI 在 J2EE 中的另外一项关键角色：查找其他应用程序组件。
试想一下这种情况：当一家公司从 Order Ontology Processing Services（OOPS）购买了一个可部署的 EJB 组件来处理客户订单时，会发生什么。为了便于举例说明，我们把它叫做 ProcessOrders V1.0。ProcessOrders 1.0 有两部分：一组接口和支持类（home 和 remote 接口，以及支持的传输类）；实际 EJB 组件自身。选择 OOPS 是因为它在这个领域的专业性。
该公司遵照 J2EE 规范，编写使用 EJB 引用的 Web 应用程序。公司的部署人员把 ProcessOrders 1.0 绑定到 JNDI 树中，将它用作 ejb/ProcessOrders/1.0，并解析 Web 应用程序的资源名称，以指向这个全局 JNDI 名称。目前为止，这些都是 EJB 组件非常普通的用法。但是，当我们考虑公司的开发周期与公司供应商之间的交互时，事情就变得复杂起来。在这里，JNDI 也能帮助我们。
我们假设 OOPS 发布了一个新版本，即 ProcessOrders V1.1。这个新版本有一些新功能，公司内部的一个新应用程序需要这些新功能，而且很自然地扩展了 EJB 组件的业务接口。
在这里，公司有以下几个选择：可以更新所有应用程序来使用新版本，也可以编写自己的版本，或者使用 JNDI 的引用解析，允许每个应用程序在不影响其他应用程序的情况下使用自己的 EJB 组件版本。立刻更新所有应用程序对维护来说是一场噩梦，它要求对所有组件都进行完整的回归测试，这通常是一项艰巨的任务，而且如果发生任何功能测试失败的话，那么还要进行另一轮调试。
编写内部（in-house）组件常常是没有必要的重复工作。如果组件是由在这个业务领域内具有专业知识的公司编写的，那么给定的 IT 商店不可能像专业的组件供应商那样精通业务功能。
正如您可能已经猜到的那样，最好的解决方案是用 JNDI 解析。EJB 的 JNDI 引用非常类似于 JDBC 资源的引用。对于每个引用，部署人员都需要把新组件按特定的名称（比如说 ejb/ProcessOrders/1.1）绑定到全局树中，对于需要 EJB 组件的其他每个组件，还要为组件在部署描述符中解析 EJB 引用。依赖于 V1.0 以前的应用程序不需要进行任何修改，也不需要重新测试，这缩短了实现的时间、降低了成本并减少了复杂性。在服务趋于转换的环境中，这是一种很有效的方法。可以对应用程序架构中所得到的所有组件进行这类配置管理，从 EJB 组件到 JMS 队列和主题，再到简单配置字符串或其他对象，这可以降低随时间的推移服务变更所产生的维护成本，同时还可以简化部署，减少集成工作。
