Java之JNDI详解

最新推荐文章于 2024-09-18 08:49:58 发布

非往

最新推荐文章于 2024-09-18 08:49:58 发布

阅读量720

点赞数 1

分类专栏： java基础

本文链接：https://blog.csdn.net/qq_42112846/article/details/96343330

版权

java基础专栏收录该内容

27 篇文章 0 订阅

订阅专栏

JNDI的基本应用
        JNDI是Java Naming and Directory Interface（JAVA命名和目录接口）的英文简写，它是为JAVA应用程序提供命名和目录访问服务的API（Application Programing Interface，应用程序编程接口）。

1．命名的概念与应用
        JNDI中的命名（Naming），就是将Java对象以某个名称的形式绑定（binding）到一个容器环境（Context）中，以后调用容器环境（Context）的查找（lookup）方法又可以查找出某个名称所绑定的Java对象。读者也许会感到奇怪：自己创建一个Java对象，将其绑定到JNDI容器环境中后又查询出来，这有什么意思？在真实的项目应用中，通常是由系统程序或框加程序先将资源对象绑定到JNDI环境中，以后在该系统或框架中运行的模块程序就可以从JNDI环境中查找这些资源对象了。例如，Tomcat服务器在启动时可以创建一个连接到某种数据库系统的数据源（DataSource）对象，并将该数据源（DataSource）对象绑定到JNDI环境中，以后在这个Tomcat服务器中运行的Servlet和JSP程序就可以从JNDI环境中查询出这个数据源（DataSource）对象进行使用，而不用关心数据源（DataSource）对象是如何创建出来的，这种方式极大地增强了系统的可维护性，当数据库系统的连接参数发生变更时，这只是Tomcat系统管理员一个人要关心的事情，而与所有的应用程序开发人员无关。
        容器环境（Context）本身也是一个Java对象，它也可以通过一个名称绑定到另一个容器环境（Context）中。将一个Context对象绑定到另外一个Context对象中，这就形成了一种父子级联关系，多个Context对象最终可以级联成一种树状结构，树中的每个Context对象中都可以绑定若干个Java对象，如图6.10所示。

图6.10
图6.10中的每个方框分别代表一个Context对象，它们绑定的名称分别为a、b、c、d、e，b和c是a的子Context，d是b的子Context，e又是d的子Context。图9.x中的各个方框内的每个小椭圆分别代表一个Java对象，它们也都有一个绑定的名称，这些绑定名称分别为dog、pig、sheet等，在同一个Context不能绑定两个相同名称的Java对象，在不同的Context中可以出现同名的绑定对象。可见，Context树的级联结构与文件系统中的目录结构非常类似，Context与其中绑定的Java对象的关系也非常类似于文件系统中的目录与文件的关系。从图6.10中可以看到，要想得到Context树中的一个Java对象，首先要得到其所在的Context对象，只要得到了一个Context对象，就可以调用它的查询（lookup）方法来获得其中绑定的Java对象。另外，调用某个Context对象的lookup方法也可以获得Context树中的任意一个Context对象，这只需要在lookup方法中指定相应的Context路径即可。在JNDI中不存在着“根”Context的概念，也就是说，执行JNDI操作不是从一个“根”Context对象开始，而是可以从Context树中的任意一个Context开始。无论如何，程序必须获得一个作为操作入口的Context对象后才能执行各种JNDI命名操作，为此，JNDI API中提供了一个InitialContext类来创建用作JNDI命名操作的入口Context对象。Context是一个接口，Context对象实际上是Context的某个实现类的实例对象，选择这个具体的Context实现类并创建其实例对象的过程是由一个Context工厂类来完成的，这个工厂类的类名可以通过JNDI的环境属性java.naming.factory.initial指定，也可以根据Context的操作方法的url参数的Schema来选择。

2．目录的概念与应用
JNDI中的目录（Directory）与文件系统中的目录概念有很大的不同，JNDI中的目录（Directory）是指将一个对象的所有属性信息保存到一个容器环境中。JNDI的目录（Directory）原理与JNDI的命名（Naming）原理非常相似，主要的区别在于目录容器环境中保存的是对象的属性信息，而不是对象本身，所以，目录提供的是对属性的各种操作。事实上，JNDI的目录（Directory）与命名（Naming）往往是结合在一起使用的，JNDI API中提供的代表目录容器环境的类为DirContext，DirContext是Context的子类，显然它除了能完成目录相关的操作外，也能完成所有的命名（Naming）操作。DirContext是对Context的扩展，它在Context的基础上增加了对目录属性的操作功能，可以在其中绑定对象的属性信息和查找对象的属性信息。JNDI中的目录（Directory）的结构示意图如图6.11所示。

图6.11
图6.11中的每个最外层的方框分别代表一个DirContext对象，它们绑定的名称分别为a、b，b是a的子DirContext。图6.11中的各个最外层的方框内的每个小椭圆分别代表一个Java对象，各个里层的方框分别代表一个对象的属性。从名称为a的DirContext中的内容可以看到，一个DirContext容器环境中即可以绑定对象自身，也可以绑定对象的属性信息，绑定的对象和绑定的属性是完全独立的两个事物，即使它们的绑定名称相同，它们的操作也是完全独立的。另外，一个属性可以有多个属性值，例如，dog对象的category属性就设置了两个属性值：meat和pet。从名称为b的DirContext中的内容可以看到，一个DirContext容器环境中也可以只绑定对象的属性信息，而不绑定任何对象自身。与Context的操作原理类似，JNDI API中提供了一个InitialDirContext类来创建用作JNDI命名与目录属性操作的入口DirContext对象。

3.我们先来了解一下没有jndi的做法

没有JNDI的做法存在的问题：
1、数据库服务器名称MyDBServer 、用户名和口令都可能需要改变，由此引发JDBC URL需要修改；
2、数据库可能改用别的产品，如改用DB2或者Oracle，引发JDBC驱动程序包和类名需要修改；
3、随着实际使用终端的增加，原配置的连接池参数可能需要调整；
4、......

解决办法：
程序员应该不需要关心“具体的数据库后台是什么？JDBC驱动程序是什么？JDBC URL格式是什么？访问数据库的用户名和口令是什么？”等等这些问题，程序员编写的程序应该没有对 JDBC 驱动程序的引用，没有服务器名称，没有用户名称或口令 —— 甚至没有数据库池或连接管理。而是把这些问题交给J2EE容器来配置和管理，程序员只需要对这些配置和管理进行引用即可。

由此，就有了JNDI。
//看的出来，是为了一个最最核心的问题：是为了解耦，是为了开发出更加可维护、可扩展//的系统

用了JNDI之后的做法：
首先，在在J2EE容器中配置JNDI参数，定义一个数据源，也就是JDBC引用参数，给这个数据源设置一个名称；然后，在程序中，通过数据源名称引用数据源从而访问后台数据库。

//红色的字可以看出，JNDI是由j2ee容器提供的功能

注：DataSource / ConnectionPool / JNDI 三者关系

DataSource：数据源是在 JDBC2.0 中引入的一个概念；

在 JDBC 扩展包中定义了Java.sql.DataSource 接口，它负责建立与数据库的连接；

在应用程序访问数据库是不必编写连接数据库的代码，可直接从数据源获得数据库连接。

ConnectionPool ：在数据源中初始化建立了多个数据库连接，这些数据库连接保存在连接池（ConnectionPool）中。

Java程序访问数据库时，只需从连接池中取出空闲状态的数据库连接，当访问结束时，将数据库连接返回给连接池。

JNDI : （Java Naming and Directory Interface）Java命名与目录接口；

为开发人员提供了查找和访问各种命名和目录服务的通用、统一的接口。

其实可以将 JNDI 理解为一种对象和名字绑定的技术，即指定一个资源名称，将该名称与某一资源或服务相关联。

结合图和上面的简述，数据层关键性对象都已展露无遗，同样也很容易理解。

JNDI 避免了程序与数据库之间的紧耦合，使应用更加易于配置、易于部署。

具体操作如下（以JBoss为例）：
3.1、配置数据源
在JBoss 的 D:\jboss420GA\docs\examples\jca 文件夹下面，有很多不同数据库引用的数据源定义模板。将其中的 mysql-ds.xml 文件Copy到你使用的服务器下，如 D:\jboss420GA\server\default\deploy。
修改 mysql-ds.xml 文件的内容，使之能通过JDBC正确访问你的MySQL数据库，如下：

这里，定义了一个名为MySqlDS的数据源，其参数包括JDBC的URL，驱动类名，用户名及密码等。

<?xml version="1.0" encoding="UTF-8"?>  
<datasources>  
<local-tx-datasource>  
    <jndi-name>MySqlDS</jndi-name>  
    <connection-url>jdbc:mysql://localhost:3306/lw</connection-url>  
    <driver-class>com.mysql.jdbc.Driver</driver-class>  
    <user-name>root</user-name>  
    <password>rootpassword</password>  
<exception-sorter-class-name>  
org.jboss.resource.adapter.jdbc.vendor.MySQLExceptionSorter  
</exception-sorter-class-name>  
    <metadata>  
       <type-mapping>mySQL</type-mapping>  
    </metadata>  
</local-tx-datasource>  
</datasources>

3.2、在程序中引用数据源：

Connection conn=null;  
try {  
  Context ctx=new InitialContext();  
  Object datasourceRef=ctx.lookup("java:MySqlDS"); //引用数据源  
  DataSource ds=(Datasource)datasourceRef;  
  conn=ds.getConnection();  
  ......  
  c.close();  
} catch(Exception e) {  
  e.printStackTrace();  
} finally {  
  if(conn!=null) {  
    try {  
      conn.close();  
    } catch(SQLException e) { }  
  }  
}

直接使用JDBC或者通过JNDI引用数据源的编程代码量相差无几，但是现在的程序可以不用关心具体JDBC参数了。

//解藕了，可扩展了
在系统部署后，如果数据库的相关参数变更，只需要重新配置 mysql-ds.xml 修改其中的JDBC参数，只要保证数据源的名称不变，那么程序源代码就无需修改。

由此可见，JNDI避免了程序与数据库之间的紧耦合，使应用更加易于配置、易于部署。

JNDI的扩展：
JNDI在满足了数据源配置的要求的基础上，还进一步扩充了作用：所有与系统外部的资源的引用，都可以通过JNDI定义和引用。
//注意什么叫资源

所以，在J2EE规范中，J2EE 中的资源并不局限于 JDBC 数据源。引用的类型有很多，其中包括资源引用（已经讨论过）、环境实体和 EJB 引用。特别是 EJB 引用，它暴露了 JNDI 在 J2EE 中的另外一项关键角色：查找其他应用程序组件。

EJB 的 JNDI 引用非常类似于 JDBC 资源的引用。在服务趋于转换的环境中，这是一种很有效的方法。可以对应用程序架构中所得到的所有组件进行这类配置管理，从 EJB 组件到 JMS 队列和主题，再到简单配置字符串或其他对象，这可以降低随时间的推移服务变更所产生的维护成本，同时还可以简化部署，减少集成工作。外部资源”。

总结：
J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。//sun 果然喜欢制定规范JNDI 在 J2EE 中的角色就是“交换机” —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下，提供 JNDI 供应者的容器可以充当有限的数据存储，这样管理员就可以设置应用程序的执行属性，并让其他应用程序引用这些属性（Java 管理扩展（Java Management Extensions，JMX）也可以用作这个目的）。JNDI 在 J2EE 应用程序中的主要角色就是提供间接层，这样组件就可以发现所需要的资源，而不用了解这些间接性。

在 J2EE 中，JNDI 是把 J2EE 应用程序合在一起的粘合剂，JNDI 提供的间接寻址允许跨企业交付可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺，而且经过一些计划和预先考虑，这个承诺是完全可以实现的。

从上面的文章中可以看出：
1、JNDI 提出的目的是为了解藕，是为了开发更加容易维护，容易扩展，容易部署的应用。
2、JNDI 是一个sun提出的一个规范(类似于jdbc),具体的实现是各个j2ee容器提供商，sun 只是要求，j2ee容器必须有JNDI这样的功能。
3、JNDI 在j2ee系统中的角色是“交换机”，是J2EE组件在运行时间接地查找其他组件、资源或服务的通用机制。
4、JNDI 是通过资源的名字来查找的，资源的名字在整个j2ee应用中(j2ee容器中)是唯一的。

参考文章：

https://blog.csdn.net/jdfkldjlkjdl/article/details/40655115

https://blog.csdn.net/u010430304/article/details/54601302

https://blog.csdn.net/u011402896/article/details/80964627