JNDI

JNDI(Java Naming and Directory Interface,Java命名和目录接口)是SUN公司提供的一种标准的Java命名系统接口，JNDI提供统一的客户端API，通过不同的访问提供者接口JNDI服务供应接口(SPI)的实现，由管理者将JNDI API映射为特定的命名服务和目录系统，使得Java应用程序可以和这些命名服务和目录服务之间进行交互。

目录服务是命名服务的一种自然扩展。两者之间的关键差别是目录服务中对象不但可以有名称还可以有属性（例如，用户有email地址），而命名服务中对象没有属性。

命名服务

命名服务是一种服务，它提供了为给定的数据集创建一个标准名字的能力。它允许把名称同Java对象或资源关联起来，而不必指出对象或资源的物理ID。

这类似于字典结构（或者是Java的map结构），该结构中键映射到值。

例如在Internet上的域名服务（domain naming service，DNS）就是提供将域名映射到IP地址的命名服务，在打开网站时一般都是在浏览器中输入名字，通过DNS找到相应的IP地址，然后打开。

所有的因特网通信都使用TCP、UDP或IP协议。IP地址由4个字节32位二进制数字组成，数字和名字相比，对于人来说名字比数字要容易记忆，但对于计算机来讲，它更善于处理数字。

其实所有的命名服务都提供DNS这种基本功能，即一个系统向命名服务注册，命名服务提供一个值到另一个值的映射。然后，另外一个系统访问命名服务就可以取得映射信息。这种交互关系对分布式企业级应用来讲显得非常重要，在Java中，基本的名字操作包含在Context接口中。

目录服务

目录服务是一种特殊类型的数据库，与SQL Server、Access、Oracle等关系数据库管理系统相反，构造目录服务的目的是为了处理基于行为的事务，并且使用一种关系信息模型。

目录服务将命名服务的概念进一步引申为提供具有层次结构的信息库，这一信息库除了包含一对一的关系外，还有信息的层次结构。对目录服务而言，这种层次结构通常用于优化搜索操作，并且也可以按实际情况进行分布或者跨网络复制。

一个目录服务通常拥有一个名字服务（但是一个名字服务不必具有一个目录服务）。

如电话簿就是一个典型的目录服务，一般先在电话簿里找到相关的人名，再找到这个人的电话号码。

每一种目录服务都可以存储有关用户名、用户密码、用户组（如有关访问控制的信息）、以太网地址、IP地址等信息。它所支持的信息和操作会因为所使用的目录服务的不同而不同。遗憾的是，访问不同目录服务的协议也会不同，所以读者需要了解多种API。

这就是JNDI的起源，就像JDBC一样，JNDI充当不同名称和目录服务的通用API或者说是前端，然后使用不同的后端适配器来连接实际服务。

JNDI是J2EE技术中的一个完整的组件。它支持通过一个单一的方法访问不同的、新的和已经存在的服务的方法。这种支持允许任何服务提供商执行通过标准服务提供商接口（SPI）协定插入JNDI框架。

作用

JNDI的功能简单说就是可以简单的方式去查找某种资源。

JNDI是一个应用程序设计的API，为开发人员提供了查找和访问各种命名和目录服务的通用、统一的接口，类似JDBC都是构建在抽象层。

比如在Tomcat中配置了一个JNDI数据源，那么在程序中之需要用Java标准的API就可以查找到这个数据源，以后数据源配置发生变化了，等等，程序都不需要改动，之需要改改JNDI的配置就行。

增加了程序的灵活性，也给系统解耦了。

小结

J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。

JNDI 在 J2EE 中的角色就是“交换机” —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下，提供 JNDI 供应者的容器可以充当有限的数据存储，这样管理员就可以设置应用程序的执行属性，并让其他应用程序引用这些属性（Java 管理扩展（Java Management Extensions，JMX）也可以用作这个目的）。

JNDI 在 J2EE 应用程序中的主要角色就是提供间接层，这样组件就可以发现所需要的资源，而不用了解这些间接性。在 J2EE 中，JNDI 是把 J2EE 应用程序合在一起的粘合剂，JNDI 提供的间接寻址允许跨企业交付可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺，而且经过一些计划和预先考虑，这个承诺是完全可以实现的。

实战

前面的一堆话都是铺垫，看实战对比。

场景

程序员开发时，知道要开发访问MySQL数据库的应用，于是将一个对 MySQL JDBC 驱动程序类的引用进行了编码，并通过使用适当的 JDBC URL 连接到数据库。

没有 JNDI

示例代码

Connection conn=null;  
try {  
  Class.forName("com.mysql.jdbc.Driver",  
                true, Thread.currentThread().getContextClassLoader());  
  conn=DriverManager.getConnection("jdbc:mysql://test?user=root&password=XXX");  
  //...
  conn.close();  
} catch(Exception e) {  
  e.printStackTrace();  
} finally {  
  if(conn!=null) {  
    try {  
      conn.close();  
    } catch(SQLException e) {}  
  }  
}  

这种实现的缺陷

1、数据库服务器名称、用户名和口令都可能需要改变，由此引发JDBC URL需要修改；

2、数据库可能改用别的产品，如改用DB2或者Oracle，引发JDBC驱动程序包和类名需要修改；

3、随着实际使用终端的增加，原配置的连接池参数可能需要调整；

解决办法

程序员应该不需要关心“具体的数据库后台是什么？JDBC驱动程序是什么？JDBC URL格式是什么？访问数据库的用户名和口令是什么？”等等这些问题，程序员编写的程序应该没有对 JDBC 驱动程序的引用，没有服务器名称，没有用户名称或口令 —— 甚至没有数据库池或连接管理。

而是把这些问题交给J2EE容器来配置和管理，程序员只需要对这些配置和管理进行引用即可。

由此，就有了JNDI。

ps: 我们平时最常用的，使用 jdbc.properties 去处理连接信息，也是同样的道理。

下面的例子可能看起来比较复杂，但是二者的核心思想是一致的。

使用 JNDI

示意代码

Connection conn=null;
try {
  Context ctx=new InitialContext();
  Object datasourceRef=ctx.lookup("java:comp/env/jdbc/mydatasource");
  DataSource ds=(Datasource)datasourceRef;
  Connection c=ds.getConnection();
  /* use the connection */
  c.close();
} 
catch(Exception e) {
  e.printStackTrace();
} 
finally {
  if(conn!=null) {
    try {
      conn.close();
    } catch(SQLException e) { }
  }
}

配置 JNDI 引用

为了让 JNDI 解析 java:comp/env/jdbc/mydatasource 引用，部署人员必须把 <resource-ref> 标签插入 web.xml 文件（Web 应用程序的部署描述符）。

<resource-ref> 标签的意思就是“这个组件依赖于外部资源”。

<resource-ref>
  <description>Dollys DataSource</description>
  <res-ref-name>jdbc/mydatasource</res-ref-name>
  <res-ref-type>javax.sql.DataSource</res-ref-type>
  <res-auth>Container</res-auth>
</resource-ref>

<resource-ref> 入口告诉 servlet 容器，部署人员要在组件命名上下文（component naming context）中设置一个叫做 jdbc/mydatasource 的资源。

组件命名上下文由前缀 java:comp/env/ 表示，所以完全限定的本地资源名称是： java:comp/env/jdbc/mydatasource.

实际资源

这只定义了到外部资源的本地引用，还没有创建引用指向的实际资源。（在 Java 语言中，类似的情况可能是： <resource-ref> 声明了一个引用，比如 Object foo，但是没有把 foo 设置成实际引用任何 Object。）

部署人员的工作就是创建 DataSource（或者是创建一个 Object 对象，让 foo 指向它，在我们的 Java 语言示例中就是这样）。每个容器都有自己设置数据源的机制。

例如，在 JBoss 中，是利用服务来定义数据源（请参阅 $JBOSS/server/default/deploy/hsqldb-ds.xml，把它作为示例），它指定自己是 DataSource 的全局 JNDI 名称（默认情况下是 DefaultDS）。

在创建资源之后，第三步仍然很关键：把资源连接或者绑定到应用程序组件使用的本地名称。

在使用 Web 应用程序的情况下，是使用特定于供应商的部署描述符扩展来指定这个绑定，清单 4 中显示了一个这样的例子。（JBoss 用称为 jboss-Web.xml 的文件作为特定于供应商的 Web 应用程序部署描述符。）

<resource-ref>
   <res-ref-name>jdbc/mydatasource</res-ref-name>
   <jndi-name>java:DefaultDS</jndi-name>
</resource-ref>

这表明应该将本地资源引用名称（ jdbc/mydatasource）映射到名为 java:DefaultDS 的全局资源。

如果全局资源名称出于某种原因发生了变化，而应用程序的代码无需变化，那么只需修改这个映射即可。

在这里，有两个级别的间接寻址：一个定义并命名资源（ java:DefaultDS），另一个把特定于本地组件的名称（ jdbc/mydatasource）绑定到命名的资源。

（实际上，当您在 EAR 级别上映射资源时，可能还存在第三级别的间接寻址。）

参考资料

https://www.oracle.com/technetwork/java/jndi/index.html

https://en.wikipedia.org/wiki/Java_Naming_and_Directory_Interface

https://www.kancloud.cn/shx_ky/java/109710

实际作用

https://blog.csdn.net/zhaosg198312/article/details/3979435

http://shitou521.iteye.com/blog/696006

https://www.ibm.com/developerworks/cn/java/j-jndi/index.html

JNDI学习总结(一)——JNDI数据源的配置

JNDI
实战
参考资料