在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
每个子上下文名被用作 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 将这个细节从应用 程序中隐藏了起来，因此代码只需知道资源的名称，而不用知道诸如提供者所包含资源的 内容、如何对提供者 |
|||||||||||||||||||||
凌众科技专业提供服务器租用、服务器托管、企业邮局、虚拟主机等服务，公司网站：http://www.lingzhong.cn 为了给广大客户了解更多的技术信息，本技术文章收集来源于网络,凌众科技尊重文章作者的版权，如果有涉及你的版权有必要删除你的文章，请和我们联系。以上信息与文章正文是不可分割的一部分,如果您要转载本文章,请保留以上信息，谢谢! |
