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

在J2EE 1.3中消除服务定位器实现中的缓存2011-04-02 IBM Bobby Woolf引言

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 接口	描述
ejb	javax.ejb.EJBHomejavax.ejb.EJBLocalHome	An Enterprise JavaBean （EJB） home
jdbc	javax.sql.DataSource	A Java Database Connectivity （JDBC）数据源
jms	javax.jms.ConnectionFactoryjavax.jms.Destination	Java Messaging Service （JMS）连接工厂或接收站
eis	javax.resource.cci.ConnectionFactory	J2EE Connector 连接工厂
mail	javax.mail.Session	JavaMail 会话
url	java.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 树以相同的方式访问所有的资源。这是组件重用的很重要的部分：组件访问资源而不用确切的了解资源是如何被提供的能力。