泰州做网站价格,app应用程序开发公司,江西省住房保障建设厅网站,做网站有要求吗J2EE应用系统是打了“分布式”的标签的#xff0c;所以客户端需要定位业务层的组件和服务#xff0c;常见的比如有#xff1a;EJB Home接口、EJB LocalHome接口、JMS消息列队或主题、JMS消息列队工厂等等#xff0c;当然还有再普通不过的JAVA对象了#xff0c;那么对这些分…J2EE应用系统是打了“分布式”的标签的所以客户端需要定位业务层的组件和服务常见的比如有EJB Home接口、EJB LocalHome接口、JMS消息列队或主题、JMS消息列队工厂等等当然还有再普通不过的JAVA对象了那么对这些分布在不同位置的组件和服务客户端是如何进行寻址的呢这就是JNDI的任务了...
JNDI(The Java Naming and Directory InterfaceJava命名和目录接口)是一组在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{ _instancenew ServiceLocator(); } catch(ServiceLocatorException se) { System.err.println(se); se.printStackTrace(System.err); } } private ServiceLocator() throws ServiceLocatorException { try { context new InitialContext(); cacheCollection.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代码吧
