JNDI Glean
邓赤岩
[b]JNDI 基本说明[/b]
JNDI ( Java Naming and Directory Interface )，是 Java 提供的一组与各种命名目录服务系统交互的接口。它是一套标准的接口，独立于各种命名目录服务系统，与具体类型的命名目录服务无关。Java 应用程序通过 JNDI 接口与命名目录服务交互，交互细节由服务提供者实现，Java 应用程序无需关心。
（个人觉得这是JAVA 的特点：向Java应用程序开发人员开放简单的接口，复杂的实现细节由服务提供者完成）
命令目录服务包括两个服务：命名服务（Naming Service）和目录（Directory Service）服务。命名服务就是用一个人类容易理解的名称与对象相关联，并且允许通过该名称找到与之对应的对象。我们天天都会用到的命名服务：DNS。个人觉得，目录服务是命名服务的超集，目录服务除了有命名服务的功能外，它的对象还可以有属性。常用的目录服务类型有 LDAP 等。
[b]JNDI 上下文[/b]
JNDI 一个主要功能就是用名字（name）来标识对象（object）。name 在 JNDI 中唯一，它跟某个特定的 object 关联，这种关联关系称之为 binding。binding的集合在 JNDI 中称为上下文 context。在JNDI 特定的上下文中，通过 name就可以找到相应的对象。
Naming Service Context：命名服务上下文视图：
[img]http://dl.iteye.com/upload/attachment/439218/b4bdef6a-4fea-357a-b03b-36e1bc796f4e.png[/img]
在上图中，a 为根 context，在它下面绑定有 dog、pig和 sheep 三个对象，同时又有 b 和 c 两个子 context，而 b 中有 d 这个子 context，d 又有 e 这个子 context，每个 context 中都绑定了相应的对象。
如果当前 context 为 a，那么 acontext.lookup(“dog”)就得到 dog 对象，而 acontext.lookup(“b/d/e/cat”) 就可得到猫这个对象。
如果当地 context 为 d，那么 dcontext.lookup(“wolf”) 就可得到 wolf 对象，dcontext.lookup(“e/rabit”) 就可得到 rabit 对象。
Directory Service Context：目录服务上下文视图：
[img]http://dl.iteye.com/upload/attachment/439208/3b7a4585-44f6-39fa-9a8b-7ffc84ab4a3e.png[/img]
可以看到，目录服务上下文 context 与命名服务上下文结构关系相似，只是目录服务上下文的中的对象多了属性。如在 a 上下文中，dog 对象有 name、color 和category属性，在 b 上下文中，cat 对象也有相同的属性。
也可以用map来帮助理解JNDI 的context。一个map 就相当于一个 JNDI context， map 的一个 entry 就是 JNDI context 的一个 binding，而 entry 的 key 相当于 binding 的 name，entry 的value 相当于 binding 的 object。当然这种理解不是非常准确的，因为 JNDI 的 context 还有目录层次的结构，但是可以用子 map 的方式来理解整个 JNDI 的 context，如下图所示：
[img]http://dl.iteye.com/upload/attachment/439216/fe19939f-e159-38c6-b090-16e92591e95c.png[/img]
在上图中，如果当前 context 为 rootMap，那么 context.lookup(“/mysqlDS”) 将得到 mysql 的连接池对象 DataSource。因为name “/mysqlDS”是跟 DataSource 绑定的；如果用context.lookup(“/jmxServerUrl”) ，将得到 JMX 服务器的连接 URL 对象 JMX_URL；同理，context.lookup(“/name_n+1/sub_name_1”) 将得到对象 sub_object1。
如果当前context为 subMap1，那么用context.lookup(“mysqlDS”) 就可以得到DataSource，而不用在 “mysqlDS” 中加上 “/”。同时，context.getSubContext(“name_n+1”) 可以得到 subMap2 的 context subcontext，并且 subcontext.lookup(“sub_name_1”) 就可得到对象 sub_object1。
在上图中，上下文结构及对象信息是维护在命名目录服务器中的， JNDI 只是操作接口。
[b]JNDI 架构[/b]
JNDI 的实现原理其实跟 JDBC 的实现原理是一样的。在 JDBC 中，Java 定义了一套标准的、独立于数据库系统的 API。JDBC 开发者只管使用 JDBC 的 API，并加载（安装）相应数据库的驱动即可，完全不用理会该数据库驱动是怎么跟它的数据库交互的。如 JDBC 的设计架构如下图所示：
[img]http://dl.iteye.com/upload/attachment/439210/202b9ec2-4e52-342d-8e3b-8e1206abab3e.png[/img]
在上图中，Java 应用程序 Application1 和 Application2 只与 JDBC API 交互，而不用管数据库的 JDBC驱动是怎么跟数据库交互的（JAVA 又是这样：向Java应用程序开发人员开放 JDBC接口，复杂的实现细节由相应的 JDBC 驱动完成）。如果系统用的是 MySQL 数据库，那么就得加载 MySQL JDBC 驱动，如果是 Oracle 数据库，那么就得提供 Oracle 的 JDBC 驱动，驱动管理者（DriverManager）会自动帮Java 应用程序 Application1 和 Application2 选择对应的 JDBC 驱动与数据库进行交互。
JNDI 的实现架构跟 JDBC 的实现架构相似，如下图所示：
[img]http://dl.iteye.com/upload/attachment/439212/ac982638-f5ea-3c2f-b720-c1a724d3e5d6.png[/img]
JNDI API 对应于 JDBC API
Naming Manager 对应于 Driver Manager
LDAP、DNS、RMI对应于 MySQL、Oracle 的 JDBC 驱动
Java Application 只与 JNDI API 交互，而不管具体的命名目录服务系统是 LDAP、DNS 还是 RMI。如果系统与 LDAP 命名目录服务系统交互，那么必须加载（安装）LDAP 驱动，如果与 DNS 命名服务系统交互，那么必须加载（安装）DNS 驱动。
[b]JNDI SPI[/b]
在 JNDI 中，有一个概念叫做 SPI（Server Provider Interface），服务提供者接口，是 JNDI 定义的标准接口。服务提供者根据命名命令服务系统的不同，需对接口做相应的实现，并使用该实现与命名命令服务系统交互。如上图中，LDAP、DNS、RMI 就是服务提供者，它们都实现了标准的 LDAP、DNS、RMI 访问协议，使用这些协议，可以与 LDAP 系统、DNS 系统和RMI 服务器交互。
如，MySQL 和 Oracle 的 JDBC 驱动就相当于 JNDI 中的服务提供者。
Java 从 1.3 版本开始就包含了 LDAP、CORBA和 RMI 的驱动实现（服务提供者），所以访问者三种类型的命名目录服务的话不用再另外加载（安装）驱动，但如果不是，就需加载相应的驱动，就像Java 访问 MySQL 数据库需加载 MySQL 的 JDBC 驱动一样。例如通过 JNDI 访问本地文件系统的话，需加载相应的访问文件系统的驱动，sun 有一个这样的驱动实现：com.sun.jndi.fscontext.RefFSContextFactory。
[b]Tomcat 的 JNDI SPI 实现[/b]
在上面的 JNDI 架构中，命名目录服务系统有可能部署在远程主机中，JNDI 使用相应的驱动与命名目录服务系统进行远程通信。如，LDAP 的驱动将与远程 LDAP 服务器进行通信，命名和目录信息存储于远程命名目录服务系统中。
但是在Tomcat 中稍有不同。Tomcat也有相应的 JNDI SPI 实现，但是该 SPI 实现（LDAP驱动）并不访问远程命名目录服务，它只是在内存中实现了一个虚拟命名目录服务，用于存储命名和对象信息并维护相应的绑定关系。Tomcat 中的数据源就对象就是存储于 Tomcat 实现的本地命名目录服务中的。
关于 Tomcat 的 JNDI SPI 实现，可以通过这两个类进行跟踪：
org.apache.naming.java.javaURLContextFactory
org.apache.naming.NamingContext
下面用两张图说明 LDAP 驱动与 Tomcat 驱动（SPI 实现）访问过程的不同：
LDAP 访问过程:
[img]http://dl.iteye.com/upload/attachment/439214/e4ea39da-ed0e-35be-ac2e-c23e911cf319.png[/img]
TOMCAT 访问过程图:
[img]http://dl.iteye.com/upload/attachment/439220/df4dd9d1-8d0f-37e4-b064-638c60c493a8.png[/img]
由上图可以看到，Java App 通过 JNDI 访问 LDAP 服务，LDAP 驱动要跟 LDAP服务进行远程通信，即LDAP 服务是在 Java App 的 JVM 之外的（Java App 与 LDAP 驱动在同一 JVM 内）。
但是 Tomcat 的 JNDI SPI 驱动实现不同。由上图可以看出，Servlet 通过 JNDI 接口访问 Tomcat 的虚拟命名目录服务时，Tomcat 的 JNDI SPI 实现直接访问其内存虚拟命名目录服务，而不需要跨越 JVM，即在 Tomcat 中，Servlet、Tomcat JNDI SPI 驱动以及 Tomcat 的内存虚拟命名目录都在同一 JVM 。
Tomcat 的 JNDI SPI 实现规定，命名空间必须以 java: 开头，如，我们通常在 Tomcat 中这样查找数据源（如 Servlet）：
Context ctx=new InitialContext();
Object o = ctx.lookup("java:comp/env/mysqlDataSource");
DataSource ds=(DataSource)o;
这里，我们在初始化 context 的时候，不用指定加载的实现驱动，是因为 Tomcat 在启动的时候已经指定了其 SPI 实现到系统属性中：
见：org.apache.catalina.startup.Embedded
System.setProperty(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
"org.apache.naming.java.javaURLContextFactory");
当初始化 context 不指定加载驱动时，JVM 自动从指定的系统属性（javax.naming.Context.INITIAL_CONTEXT_FACTORY）中查找该驱动。
所以，我们对 mysqlDataSource 的查找请求转到 Tomcat 的 JNDI SPI 实现中，JNDI SPI 实现
根据名称从其内存的虚拟命名目录服务查找 mysql 的数据源对象，并返回给应用程序。
[b]JNDI 简单使用[/b]
JNDI 的使用相对简单，JNDI 开发人员只需初始化一个 context 实例（可以把该实例看成是命名目录服务系统的一个镜像），并通过该 context 实例绑定对象、查找对象以及解除对象。
在初始化context 实例时，需根据目标命名目录服务系统提供相应的驱动类供 JNDI 加载使用：
Hashtable env = new Hashtable(11); env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.fscontext.RefFSContextFactory");
Context ctx = new InitialContext(env);
在上例中，要访问的目标命名目录服务系统是本地文件系统，所以需提供 JNDI 的文件系统驱动。如果是访问 LDAP 系统，那么 context 的初始化应该提供 LDAP 驱动类：
Hashtable env = new Hashtable(11);
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL,"ldap://localhost:389/o=JNDITutorial");
DirContext ctx = new InitialDirContext(env);
常用的 JNDI 操作有
查找对象：lookup(String name)
绑定对象：bind(String name, Object obj)
解除对象：unbind(String name)
还有重命名、重绑定、创建子 context 等。
关于 JNDI 的更多细节，请参阅相应书籍。
JNDI ( Java Naming and Directory Interface )，是 Java 提供的一组与各种命名目录服务系统交互的接口。它是一套标准的接口，独立于各种命名目录服务系统，与具体类型的命名目录服务无关。Java 应用程序通过 JNDI 接口与命名目录服务交互，交互细节由服务提供者实现，Java 应用程序无需关心。
（个人觉得这是JAVA 的特点：向Java应用程序开发人员开放简单的接口，复杂的实现细节由服务提供者完成）
命令目录服务包括两个服务：命名服务（Naming Service）和目录（Directory Service）服务。命名服务就是用一个人类容易理解的名称与对象相关联，并且允许通过该名称找到与之对应的对象。我们天天都会用到的命名服务：DNS。个人觉得，目录服务是命名服务的超集，目录服务除了有命名服务的功能外，它的对象还可以有属性。常用的目录服务类型有 LDAP 等。
[b]JNDI 上下文[/b]
JNDI 一个主要功能就是用名字（name）来标识对象（object）。name 在 JNDI 中唯一，它跟某个特定的 object 关联，这种关联关系称之为 binding。binding的集合在 JNDI 中称为上下文 context。在JNDI 特定的上下文中，通过 name就可以找到相应的对象。
Naming Service Context：命名服务上下文视图：
[img]http://dl.iteye.com/upload/attachment/439218/b4bdef6a-4fea-357a-b03b-36e1bc796f4e.png[/img]
在上图中，a 为根 context，在它下面绑定有 dog、pig和 sheep 三个对象，同时又有 b 和 c 两个子 context，而 b 中有 d 这个子 context，d 又有 e 这个子 context，每个 context 中都绑定了相应的对象。
如果当前 context 为 a，那么 acontext.lookup(“dog”)就得到 dog 对象，而 acontext.lookup(“b/d/e/cat”) 就可得到猫这个对象。
如果当地 context 为 d，那么 dcontext.lookup(“wolf”) 就可得到 wolf 对象，dcontext.lookup(“e/rabit”) 就可得到 rabit 对象。
Directory Service Context：目录服务上下文视图：
[img]http://dl.iteye.com/upload/attachment/439208/3b7a4585-44f6-39fa-9a8b-7ffc84ab4a3e.png[/img]
可以看到，目录服务上下文 context 与命名服务上下文结构关系相似，只是目录服务上下文的中的对象多了属性。如在 a 上下文中，dog 对象有 name、color 和category属性，在 b 上下文中，cat 对象也有相同的属性。
也可以用map来帮助理解JNDI 的context。一个map 就相当于一个 JNDI context， map 的一个 entry 就是 JNDI context 的一个 binding，而 entry 的 key 相当于 binding 的 name，entry 的value 相当于 binding 的 object。当然这种理解不是非常准确的，因为 JNDI 的 context 还有目录层次的结构，但是可以用子 map 的方式来理解整个 JNDI 的 context，如下图所示：
[img]http://dl.iteye.com/upload/attachment/439216/fe19939f-e159-38c6-b090-16e92591e95c.png[/img]
在上图中，如果当前 context 为 rootMap，那么 context.lookup(“/mysqlDS”) 将得到 mysql 的连接池对象 DataSource。因为name “/mysqlDS”是跟 DataSource 绑定的；如果用context.lookup(“/jmxServerUrl”) ，将得到 JMX 服务器的连接 URL 对象 JMX_URL；同理，context.lookup(“/name_n+1/sub_name_1”) 将得到对象 sub_object1。
如果当前context为 subMap1，那么用context.lookup(“mysqlDS”) 就可以得到DataSource，而不用在 “mysqlDS” 中加上 “/”。同时，context.getSubContext(“name_n+1”) 可以得到 subMap2 的 context subcontext，并且 subcontext.lookup(“sub_name_1”) 就可得到对象 sub_object1。
在上图中，上下文结构及对象信息是维护在命名目录服务器中的， JNDI 只是操作接口。
[b]JNDI 架构[/b]
JNDI 的实现原理其实跟 JDBC 的实现原理是一样的。在 JDBC 中，Java 定义了一套标准的、独立于数据库系统的 API。JDBC 开发者只管使用 JDBC 的 API，并加载（安装）相应数据库的驱动即可，完全不用理会该数据库驱动是怎么跟它的数据库交互的。如 JDBC 的设计架构如下图所示：
[img]http://dl.iteye.com/upload/attachment/439210/202b9ec2-4e52-342d-8e3b-8e1206abab3e.png[/img]
在上图中，Java 应用程序 Application1 和 Application2 只与 JDBC API 交互，而不用管数据库的 JDBC驱动是怎么跟数据库交互的（JAVA 又是这样：向Java应用程序开发人员开放 JDBC接口，复杂的实现细节由相应的 JDBC 驱动完成）。如果系统用的是 MySQL 数据库，那么就得加载 MySQL JDBC 驱动，如果是 Oracle 数据库，那么就得提供 Oracle 的 JDBC 驱动，驱动管理者（DriverManager）会自动帮Java 应用程序 Application1 和 Application2 选择对应的 JDBC 驱动与数据库进行交互。
JNDI 的实现架构跟 JDBC 的实现架构相似，如下图所示：
[img]http://dl.iteye.com/upload/attachment/439212/ac982638-f5ea-3c2f-b720-c1a724d3e5d6.png[/img]
JNDI API 对应于 JDBC API
Naming Manager 对应于 Driver Manager
LDAP、DNS、RMI对应于 MySQL、Oracle 的 JDBC 驱动
Java Application 只与 JNDI API 交互，而不管具体的命名目录服务系统是 LDAP、DNS 还是 RMI。如果系统与 LDAP 命名目录服务系统交互，那么必须加载（安装）LDAP 驱动，如果与 DNS 命名服务系统交互，那么必须加载（安装）DNS 驱动。
[b]JNDI SPI[/b]
在 JNDI 中，有一个概念叫做 SPI（Server Provider Interface），服务提供者接口，是 JNDI 定义的标准接口。服务提供者根据命名命令服务系统的不同，需对接口做相应的实现，并使用该实现与命名命令服务系统交互。如上图中，LDAP、DNS、RMI 就是服务提供者，它们都实现了标准的 LDAP、DNS、RMI 访问协议，使用这些协议，可以与 LDAP 系统、DNS 系统和RMI 服务器交互。
如，MySQL 和 Oracle 的 JDBC 驱动就相当于 JNDI 中的服务提供者。
Java 从 1.3 版本开始就包含了 LDAP、CORBA和 RMI 的驱动实现（服务提供者），所以访问者三种类型的命名目录服务的话不用再另外加载（安装）驱动，但如果不是，就需加载相应的驱动，就像Java 访问 MySQL 数据库需加载 MySQL 的 JDBC 驱动一样。例如通过 JNDI 访问本地文件系统的话，需加载相应的访问文件系统的驱动，sun 有一个这样的驱动实现：com.sun.jndi.fscontext.RefFSContextFactory。
[b]Tomcat 的 JNDI SPI 实现[/b]
在上面的 JNDI 架构中，命名目录服务系统有可能部署在远程主机中，JNDI 使用相应的驱动与命名目录服务系统进行远程通信。如，LDAP 的驱动将与远程 LDAP 服务器进行通信，命名和目录信息存储于远程命名目录服务系统中。
但是在Tomcat 中稍有不同。Tomcat也有相应的 JNDI SPI 实现，但是该 SPI 实现（LDAP驱动）并不访问远程命名目录服务，它只是在内存中实现了一个虚拟命名目录服务，用于存储命名和对象信息并维护相应的绑定关系。Tomcat 中的数据源就对象就是存储于 Tomcat 实现的本地命名目录服务中的。
关于 Tomcat 的 JNDI SPI 实现，可以通过这两个类进行跟踪：
org.apache.naming.java.javaURLContextFactory
org.apache.naming.NamingContext
下面用两张图说明 LDAP 驱动与 Tomcat 驱动（SPI 实现）访问过程的不同：
LDAP 访问过程:
[img]http://dl.iteye.com/upload/attachment/439214/e4ea39da-ed0e-35be-ac2e-c23e911cf319.png[/img]
TOMCAT 访问过程图:
[img]http://dl.iteye.com/upload/attachment/439220/df4dd9d1-8d0f-37e4-b064-638c60c493a8.png[/img]
由上图可以看到，Java App 通过 JNDI 访问 LDAP 服务，LDAP 驱动要跟 LDAP服务进行远程通信，即LDAP 服务是在 Java App 的 JVM 之外的（Java App 与 LDAP 驱动在同一 JVM 内）。
但是 Tomcat 的 JNDI SPI 驱动实现不同。由上图可以看出，Servlet 通过 JNDI 接口访问 Tomcat 的虚拟命名目录服务时，Tomcat 的 JNDI SPI 实现直接访问其内存虚拟命名目录服务，而不需要跨越 JVM，即在 Tomcat 中，Servlet、Tomcat JNDI SPI 驱动以及 Tomcat 的内存虚拟命名目录都在同一 JVM 。
Tomcat 的 JNDI SPI 实现规定，命名空间必须以 java: 开头，如，我们通常在 Tomcat 中这样查找数据源（如 Servlet）：
Context ctx=new InitialContext();
Object o = ctx.lookup("java:comp/env/mysqlDataSource");
DataSource ds=(DataSource)o;
这里，我们在初始化 context 的时候，不用指定加载的实现驱动，是因为 Tomcat 在启动的时候已经指定了其 SPI 实现到系统属性中：
见：org.apache.catalina.startup.Embedded
System.setProperty(javax.naming.Context.INITIAL_CONTEXT_FACTORY,
"org.apache.naming.java.javaURLContextFactory");
当初始化 context 不指定加载驱动时，JVM 自动从指定的系统属性（javax.naming.Context.INITIAL_CONTEXT_FACTORY）中查找该驱动。
所以，我们对 mysqlDataSource 的查找请求转到 Tomcat 的 JNDI SPI 实现中，JNDI SPI 实现
根据名称从其内存的虚拟命名目录服务查找 mysql 的数据源对象，并返回给应用程序。
[b]JNDI 简单使用[/b]
JNDI 的使用相对简单，JNDI 开发人员只需初始化一个 context 实例（可以把该实例看成是命名目录服务系统的一个镜像），并通过该 context 实例绑定对象、查找对象以及解除对象。
在初始化context 实例时，需根据目标命名目录服务系统提供相应的驱动类供 JNDI 加载使用：
Hashtable env = new Hashtable(11); env.put(Context.INITIAL_CONTEXT_FACTORY,"com.sun.jndi.fscontext.RefFSContextFactory");
Context ctx = new InitialContext(env);
在上例中，要访问的目标命名目录服务系统是本地文件系统，所以需提供 JNDI 的文件系统驱动。如果是访问 LDAP 系统，那么 context 的初始化应该提供 LDAP 驱动类：
Hashtable env = new Hashtable(11);
env.put(Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.ldap.LdapCtxFactory");
env.put(Context.PROVIDER_URL,"ldap://localhost:389/o=JNDITutorial");
DirContext ctx = new InitialDirContext(env);
常用的 JNDI 操作有
查找对象：lookup(String name)
绑定对象：bind(String name, Object obj)
解除对象：unbind(String name)
还有重命名、重绑定、创建子 context 等。
关于 JNDI 的更多细节，请参阅相应书籍。
类似资料：