在J2EE 1.3中消除服务定位器实现中的缓存

　　引言

　　Service Locator 是 Java™ 2 EntERPrise Edition (J2EE) 应用程序中一个比较流行的应用程序设计模式。这个模式通过目录服务封装访问组件的代码，如 JNDI 客户端代码之类，因此客户端可以简单的以资源名通过验证并返回这个资源。服务定位器实现通常包括资源缓存，以此来避免对相同资源的重复查找。然而这只能在 J2EE 1.2 中正常工作，但在 J2EE 1.3 和以后的版本中，缓存可以在应用程序部署中引入微妙且难以诊断的错误。因此，在 J2EE 1.3 应用程序中，服务定位器的实现不应该包含资源缓存。

　　JNDI 目录服务

　　Java Naming and Directory Interface(JNDI)是 J2EE 平台的一部分，它使得 Java 程序可以通过唯一的名称来访问资源，而并不用考虑资源是在何处存储的、它是如何实现的、容器以及它的 JNDI 提供者是如何实际访问资源的;资源可以是任何程序需要全局访问的对象。

　　我们将主要回顾 JNDI 是如何工作的，首先要弄清楚影响 Service Locator 模式的部分。要了解更多，请参见 Sun 的 JNDI 指南(参见 参考资料)。

　　JNDI 上下文

　　JNDI 名是以层次树结构排列的，就像文件系统的目录结构或一系列 Java 类的包结构。在 J2EE 中有对资源的通用类型的 JNDI 资源环境引用子上下文名的约定。表 1 显示了典型的 JNDI 子上下文和类型。

　　表 1 子上下文 Java 接口 描述

　　EJBjavax.ejb.EJBHomejavax.ejb.EJBLocalHome An Enterprise JavaBean (EJB) home

　　JDBCjavax.sql.DataSource A Java Database Connectivity (JDBC) 数据源

　　jmsjavax.jms.ConnectionFactoryjavax.jms.Destination Java Messaging Service (JMS) 连接工厂或接收站

　　eisjavax.resource.cci.ConnectionFactory J2EE Connector 连接工厂

　　mailjavax.mail.Session JavaMail 会话

　　urljava.net.URL Web 服务连接工厂

　　每个子上下文名被用作 JNDI 表达式的一部分，以此来访问客户端本地上下文中的对象。例如， java:comp/env/ejb 提供对 EJB 本地接口的访问，而 java:comp/env/jdbc 提供对 JDBC 数据源的访问。

　　为何使用 JNDI?

　　正如大部分 J2EE 服务一样，JNDI 只提供了标准接口(在 javax.naming 包中定义)而没有具体实现。作为透明性 JNDI 提供的例子之一，设想一个 JMS 应用程序提供者(例如 WebSphere® MQ)，它是由一组受控对象来配置的(连接工厂和接收站)，而组件应用程序将使用这些对象处理消息。提供者将组织这些资源并将其安排在某个目录中(或有可能在许多目录中，例如每个受控对象类型对应一个目录)，这就使得应用程序通过它的名称访问组件。这个目录结构可能是厂商指定的，但因为提供者实现了 JMS 规范，所以提供者也必须确保能够通过 JNDI API 得到它的资源，而不用管实际的目录是如何实现的。JNDI 提供对资源的一致访问，而这些资源不一定是一致的。

　　而且，展示于应用程序面前的是一个单独的个体，连续的 JNDI 树可以(通常是“肯定”)将几个不同的提供者的资源集合在一起。JNDI 将这个细节从应用程序中隐藏了起来，因此代码只需知道资源的名称，而不用知道诸如提供者所包含资源的内容、如何对提供者进行访问、提供者为资源使用什么样的名称等等。

　　J2EE 应用程序服务器(例如 WebSphere Application Server)实现其自身的 JNDI 目录，服务器的应用程序正是使用它来访问所有资源。应用程序服务器需要构造 JDBC、JMS 和其他资源，使其适用于服务器的应用程序。因为提供者通过 JNDI 提供他们的资源，所以应用程序服务器的 JNDI 树可以轻易地包含资源节点。

　　图 1. 应用程序服务器 JNDI 树

　　EJB 组件甚至并不知道其中的一些资源是远程的并且是在 EJB 容器之外被管理的。它通过相同的 JNDI 树以相同的方式访问所有的资源。这是组件重用的很重要的部分：组件访问资源而不用确切的了解资源是如何被提供的能力。