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内部完成了。
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内部完成了。
在保留http://www.javajia.com原出处的情况下,欢迎转载!