J2EE应用系统是打了“分布式”的标签的，所以客户端需要定位业务层的组件和服务，常见的比如有：EJB Home接口、EJB LocalHome接口、JMS消息列队或主题、JMS消息列队工厂等等，当然还有再普通不过的JAVA对象了，那么对这些分布在不同位置的组件和服务，客户端是如何进行寻址的呢？这就是JNDI的任务了...

JNDI(The Java Naming and Directory Interface，Java命名和目录接口)是一组在Java应用中访问命名和目录服务的API。如同其它很多Java技术一样(例如 JDBC)，JDNI是provider-based的技术，暴露了一个API和一个服务供应接口(SPI)。这意味着任何基于名字的技术都能通过 JNDI而提供服务，只要JNDI支持这项技术。JNDI目前所支持的技术包括LDAP、CORBA Common Object Service(COS)名字服务、RMI、NDS、DNS、Windows注册表等等。JDNI通过绑定的概念将对象和名称联系起来。就像在一个文件系统中，文件名被绑定给文件;在DNS中，一个IP地址绑定一个URL;在目录服务中，一个对象名被绑定给一个对象实体。

在J2EE应用中，业务层组件(比如EJB组件)和集成层组件(比如JDBC数据源和JMS组件)通常都要在一个中央注册表中注册。客户端使用JNDI API来与这个注册表交互，获得一个初始化上下文(InitialContext)对象，该对象中装载着组件的名称/对象绑定信息。客户端通过它就可以 lookup我们需要的组件和服务了，但是这样可能会相当的复杂，因为这可能要包括重复使用初始化上下文(InitialContext)对象、寻址操作、强制类型转换操作以及对底层异常和超时的处理操作。

想一想，我们是不是在这样不停地重复我们自己呢?当我们粘贴复制到手都发麻的时候，有没有考虑如果现在要对其进行一点改动，我们又该怎么作？我猜想你一定会责怪自己为什么才发现呢， 还要在从头粘贴复制，噢，天呢！

应用系统客户端需要从这种复杂性中隔离出来。不然，在多种不同的客户端中就会有重复的JNDI代码，因为所有访问一个由JNDI管理的服务/组件的客户端都要执行同样的寻址。创建一个JNDI InitialContext对象，执行服务组件的寻址可能是一种代价很高的操作，如果反复执行这样的操作，可能会引起系统性能的恶化。另外一个问题是，JDNI是provider-based的技术，InitialContext和JNDI注册表中注册的其他context工厂都是厂商提供实现的。如果应用系统客户端直接访问以上的对象的这些特殊实现，那么会给应用引入厂商依赖性，使代码难以移植。

所以我们需要一种统一的、透明的方式定位业务组件和业务服务。J2EE核心模式里面的ServiceLocator模式就是这个问题的最优解，使用服务定位器实现、封装对服务/组件的寻址。应用系统客户端可以通过服务定位器实现重用，降低代码的复杂性，提供唯一的控制点，并且提供缓存机制(Cache)，能够改善系统的性能。

下面通过一个定位EJB服务的例子来看一下怎么来实现ServiceLocator，对于其他服务和组件的定位就是大同小异的了。

import java.util.*;    
import javax.naming.*;    
import java.rmi.RemoteException;    
import javax.ejb.*;    
import javax.rmi.PortableRemoteObject;    
import java.io.*;    public class ServiceLocator {    private static ServiceLocator _instance;    private InitialContext context = null;    private Map cache;    static {    try{    _instance=new ServiceLocator();    } catch(ServiceLocatorException se) {    System.err.println(se);    se.printStackTrace(System.err);        }    }    private ServiceLocator() throws ServiceLocatorException {    try {    context = new InitialContext();    cache=Collection.synchronizedMap(new HashMap());    } catch(NamingException ne) {    throw new ServiceLocatorException(ne);    } catch(Exception e) {    throw new ServiceLocatorException(ne);    }    }    public static ServiceLocator getInstance()     throws ServiceLocatorException {    return _instance;    }    public EJBLocalHome getLocalHome(String jndiHomeName)    throws ServiceLocatorException {    EJBLocalHome localHome = null;    try {    if(cache.containsKey(jndiHomeName)) {    localHome = (EJBLocalHome)cache.get(jndiHomeName);    } else {    localHome = (EJBLocalHome)context,lookup(jndiName);    cache.put(jndiName, localHome);     }    } catch(NamingException nex) {    throw new ServiceLocatorException(ne);    } catch(Exception ex) {    throw new ServiceLocatorException(ne);    }    return localHome;              }     public EJBHome getRemoteHome(String jndiHomeName, Class homeClassName)    throws ServiceLocatorException {    EJBHome remoteHome = null;    try {    if(cache.containsKey(jndiHomeName)) {    remoteHome = (EJBHome)cache.get(jndiHomeName);    } else {    Object objref = context,lookup(jndiName);    Object obj = PortableRemoteObject. narrow(objref, homeClassName);    remoteHome = (EJBHome)obj;    cache.put(jndiName, remoteHome);     }    } catch(NamingException nex) {    throw new ServiceLocatorException(ne);    } catch(Exception ex) {    throw new ServiceLocatorException(ne);    }    return remoteHome;              }     
}    

我们看到了ServiceLocator的核心采用了单子模式，利用ServiceLocator模式对JDNI的使用的进行改进，可以抽象系统的复杂性，向客户端隐藏了JDNI寻址的复杂性；可以为客户端提供统一的服务访问方式，这种统一减少了开发和维护的工作量，我们终于可以免除粘贴复制了；提高了系统的网络性能和客户端性能。
好了，现在就开始重构我们的JNDI代码吧！