JNDI设计内幕

转载 2005年03月02日 13:05:00
1 将接口分为Context 和 DirContext   

  JNDI有两个核心接口Context和DirContext,Context中包含了基本的名字操作,而DirContext则将这些操作扩展到目录服务。将这些操作分为两个包一方面为了模块化,另一方面也可以使服务减少不必要的开销。名字是计算服务中的一个基本功能,使用基本的名字服务就可以获得文件系统、电子表格、日历服务等功能;DirContext 对Context进行了扩展,提供了基本的目录服务操作,对名字对象属性的维护、基于属性的名字查找等等。   

  2 将JNDI 分成多个功能包   

  JNDI 分为两个客户端包(javax.naming,javax.naming.directory) 和一个服务端包 (javax.naming.spi)。这样做也同样是为了减少应用程序不必要的开销,使得应用程序只需要包括所必须的包。   

  3 将客户端API 和 服务端的API 分开   

  JNDI 将客户端接口与服务提供商需要的接口分开为不同的包。比如,客户端程序只需要使用javax.naming包中提供的类,而服务提供商可能需要javax.naming和javax.naming.spi两中包。这样分开可以使客户和服务器端只专注于与自身有关的类信息。   

  4 上下文列表的多种方法   

  一般来说有两种进行上下文列表的应用:上下文浏览应用和对上下文中的对象进行实际操作的应用。   

  上下文浏览应用一般只需要显示上下文中包含内容的名字,或者再获取一些诸如对象的类型之类的信息。这种类型的应用一般都是交互式的,可以允许用户在列举的上下文列表中选择一些进行进一步的显示。   

  另外有一些应用需要对上下文中的对象进行实际的操作,比如,一个备份程序需要对目录中所有文件的状态进行操作,或者某打印机管理员可能需要对大楼中的所有打印机进行复位。为了进行这样的操作,程序需要获取上下文中的实际对象。   

  对于这样两种类型的应用,Context接口提供了两种上下文列表方法list()和listBindings()。其中list()只返回一系列名字/类映射,而listBindings() 则返回名字、类和对象本身。显然list()用于上下文浏览应用而listBindings()用于那些需要对对象进行实际操作的应用。   

  5 对联合的支持   

联合是JNDI的一个基本概念,在客户端接口中可以支持跨越多个名字空间的名字,调用名字接口的程序不需要知道细节问题,只需要指定有关的名字,有关在几个名字系统中如何解析复合名字的问题留给服务提供商来解决,与客户无关。   

 6 DirContext 与 DirObject   

  对于目录服务的实现来说,如果不用扩展Context的DirContext接口,也可以使用一个单独的包含了所有目录相关方法的接口如DirObject,这样的话如果应用只使用目录服务就可以只包括DirObject,而如果名字服务和目录服务都使用,则可以包括Context和DirObject。这样当然条理比较清晰,但是对于某些混合操作,比如一些对目录和名字都有效的操作就不太方便了,所以JNDI采用了DirContext而不是DirObject。   

  7 Schema的支持   

  DirContext接口包含对schema的支持,例如,客户可以通过DirContext对象获得指向该DirContext实例的schema的定义空间的schema对象,或者获取该schema对象的类定义。Attribute类还更进一步地支持获取属性类型信息、属性定义等的方法。服务提供商既可以动态地返回这些schema信息,也可以静态地事先准备好有关的schema信息。   

 8 Context 和 DirContext   

  接口中的方法重载 在Context和DirContext接口中的每个接受Name参数的方法都有一个接受字符串参数的同名方法。 设计以字符串为参数的方法的原因是由于有很多应用只通过对象的名字来访问这些对象,对于这些应用来说,直接使用名字来访问这些方法当然是最直观的。   

  而设计以Name类对象为参数的方法的动机,也是由于有不少对名字进行维护的应用并不关系名字的字面表达,所以需要以Name对象作为参数。 在JNDI中这两种形式的方法都可以调用,以方便各种不同的应用。   

  9 引用   

  JNDI包容了多种使用目录来定位对象的方法,例如,一些应用直接将对象自身绑定在目录中;一些应用可能动态地产生目录树,当应用退出时就删去该树;另外一些应用可能只是将指向对象的URL存贮在名字空间里;还有一些系统可能将一些引用信息绑定到树中,当使用时再用这些信息来访问实际的对象。   

   针对这些不同的方式,JNDI定义了一个Reference类来为应用信息的表达提供一种统一的方式。Reference类包含了诸如地址、类型信息等用于访问具体对象的信息。为了能将对象的引用绑定到目录树中,该对象的类必须实现Referenceable接口,其中包含了方法 getReference() 。 Serializable接口与Referenceable接口有颇多相似之处,不同在于可引用的对象只包含一些用于创建实际对象的信息而Serializable会包含更多的甚至不适合存储在目录结构中的信息。   

  10 引用到实际对象的自动定位 对于作为引用绑定在目录树中的对象,JNDI SPI 指定针对引用创建实际的对象。因此,在程序中只需要认为用lookup()方法返回的对象就是实际对象,而不用在调用什么方法来将引用转换为实际对象了,所有的工作都由JNDI内部完成了。  

相关文章推荐

Spring技术内幕——深入解析Spring架构与设计原理(二)AOP

关于AOP的个人理解  AOP联盟定义的AOP体系结构把与AOP相关的概念大致分为了由高到低、从使用到实现的三个层次。关于这个体系结构,个人的理解是这样的,从上往下,最高层是语言和开发环境,在这...

关于阅读陆舟老师《Struts2技术内幕-深入解析Struts2架构设计与实现原理》一书的阅读笔记(1)

我们为什么要学习框架?这些框架到底从何而来?框架的本质是什么?使用框架,又能给我们的开发带来什么样的好处呢? 拿struts2来说,我们在web项目中引入struts2时,除了引入必要的jar包,我们...

Spring技术内幕——深入解析Spring架构与设计原理(三)数据库的操作实现

最近事情实在是比较多,没有及时更新帖子,还望大家见谅啊。今天,一起讨论讨论Spring JDBC的实现吧。  关于Spring JDBC  还是从Spring JDBC说起吧,虽然现在应用很多...

Spring技术内幕——深入解析Spring架构与设计原理(三)数据库的操作实现

关于Spring JDBC 还是从Spring JDBC说起吧,虽然现在应用很多都是直接使用Hibernate或者其他的ORM工具。但JDBC毕竟还是很基本的,其中的JdbcTemplate就是我们...

Spring技术内幕——深入解析Spring架构与设计原理(一)IOC实现原理

内容较多,新开一贴,以便阅读和讨论,请管理员见谅。  IOC的基础  下面我们从IOC/AOP开始,它们是Spring平台实现的核心部分;虽然,我们一开始大多只是在这个层面上,做一些配置和...

游戏核心算法编程内幕学习(三):设计模式

1.单体模式:是个全局对象,整个应用程序中只有一个实例 2.策略模式: 为了避免过量的switch,为了使代码更优雅。分开类定义与一个或几个成员 的算法,使这些算法可以在运行时交换。这样...

Spring技术内幕——深入解析Spring架构与设计原理(一)IOC实现原理

转自:http://www.javaeye.com/topic/493282?page=1 简单来说,自己的软件产品是一个基于互联网的SaaS协同软件平台,操作简单,支持流程定义,管理和多种客户...

Spring技术内幕——深入解析Spring架构与设计原理(一)IOC实现原理

转载自:http://jiwenke.iteye.com/blog/493965 Spring技术内幕——深入解析Spring架构与设计原理(一)IOC实现原理 IOC的基础  ...
  • dudet
  • dudet
  • 2016-03-12 20:40
  • 285

【读过的书,留下的迹】Spring技术内幕——深入解析Spring架构与设计原理

前言   最近发现有时候看完一本书,时间久了容易忘记,看书不总结思考效果大打折扣,故打算写这一系列文章,一是为了整理书中的要点,帮助自己消化理解;二是勉励自己多看书思考。文章中不会把书中内容讲解的非...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

(最多只允许输入30个字)