<resource-ref>
  <description>Dollys DataSource</description>
  <res-ref-name>jdbc/mydatasource</res-ref-name>
  <res-ref-type>javax.sql.DataSource</res-ref-type>
  <res-auth>Container</res-auth>
</resource-ref>

入口告诉 servlet 容器，部署人员要在组件命名上下文（component naming context） 中设置一个叫做 jdbc/mydatasource 的资源。组件命名上下文由前缀 java:comp/env/ 表示，所以完全限定的本地资源名称是：java:comp/env/jdbc/mydatasource.

这只定义了到外部资源的本地引用，还没有创建引用指向的实际资源。（在 Java 语言中，类似的情况可能是： 声明了一个引用，比如 Object foo，但是没有把 foo 设置成实际引用任何 Object。）

部署人员的工作就是创建 DataSource（或者是创建一个 Object 对象，让 foo 指向它，在我们的 Java 语言示例中就是这样）。每个容器都有自己设置数据源的机制。例如，在 JBoss 中，是利用服务来定义数据源（请参阅 $JBOSS/server/default/deploy/hsqldb-ds.xml，把它作为示例），它指定自己是 DataSource 的全局 JNDI 名称（默认情况下是 DefaultDS）。在创建资源之后，第三步仍然很关键：把资源连接或者绑定到应用程序组件使用的本地名称。在使用 Web 应用程序的情况下，是使用特定于供应商的部署描述符扩展来指定这个绑定，清单 4 中显示了一个这样的例子。（JBoss 用称为 jboss-Web.xml 的文件作为特定于供应商的 Web 应用程序部署描述符。）

清单 4. 用特定于供应商的部署描述符将资源绑定到 JDI 名称:

<resource-ref>
   <res-ref-name>jdbc/mydatasource</res-ref-name>
   <jndi-name>java:DefaultDS</jndi-name>
</resource-ref>

这表明应该将本地资源引用名称（jdbc/mydatasource）映射到名为 java:DefaultDS 的全局资源。如果全局资源名称出于某种原因发生了变化，而应用程序的代码无需变化，那么只需修改这个映射即可。在这里，有两个级别的间接寻址：一个定义并命名资源（java:DefaultDS），另一个把特定于本地组件的名称（jdbc/mydatasource）绑定到命名的资源。（实际上，当您在 EAR 级别上映射资源时，可能还存在第三级别的间接寻址。）

超越数据源

当然，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 队列和主题，再到简单配置字符串或其他对象，这可以降低随时间的推移服务变更所产生的维护成本，同时还可以简化部署，减少集成工作。

结束语

有一个古老的计算机科学笑话：每个编程问题都可以仅仅用一个抽象层（或间接的）来解决。在 J2EE 中，JNDI 是把 J2EE 应用程序合在一起的粘合剂，但还没有紧到无法让人很容易地把它们分开并重新装配。JNDI 提供的间接寻址允许跨企业交付可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺，而且经过一些计划和预先考虑，这个承诺是完全可以实现的。实际上，它要比许多人想像的容易得多。

<<上一页 1 2 3