利用ServiceLocator模式改进JNDI实践

      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代码吧！