JNDI到底是什么？

       前言

              在上一篇文章中笔者就J2EE的十三种技术规范做了一个简单的总结。虽然很多种技术规范小生

          都没有接触过，不过总结一下方便日后的学习。也使自己对J2EE整个有一个认知。上篇文章中笔

          者对JNDI完全没弄明白是怎么回事。通过查找资料总算是有些眉目了，现做一个总结。

              要理解JNDI，我们要从其作用入手，通过对比不使用JNDI和使用JNDI来理解他，体会使用它的

          好处。

        NO JNDI

               首先我们看看不是用JNDI的情况。

               我们在进行数据库应用开发的时候，必然会使用JDBC来操作数据库。通过不同的URL我们可以

           连接到不同的数据库。这种代码可能我们已经写过很多次了。就像这样。     

package com.kiritor;/** * 数据库连接 * @author Kiritor*/import java.sql.Connection;import java.sql.DriverManager;import java.sql.SQLException;public class DBUitls {private static String username = "root";private static String password = "root";private static String url = "jdbc:mysql://localhost:3306/manchat";public static Connection buildCollection() {Connection connection = null;try {Class.forName("com.mysql.jdbc.Driver");connection = DriverManager.getConnection(url, username, password);if (connection != null) {System.out.println("数据库连接成功!" + connection);}} catch (ClassNotFoundException | SQLException e) {e.printStackTrace();}return connection;}}

                 这是较为传统的做法，这种做法在小规模的开发中不会产生太大问题。不过仔细思考下

          会存在下面几方面的问题。

                 1、数据库服务器名称，用户名，密码很可能需要改变，我们就必须去修改源码，这不是

                     一种合理的做法。

                  2、数据库可能改用其他产品(MySQL->Oracle)，这也会引起修改。

                  3、数据库实际使用的终端增加，原配置的连接池可能需要调整。

            意识到上述的缺点，JNDI就是来帮助我们解决这个问题的。看看是如何解决的吧！

        使用JNDI

                使用JNDI之前我们需要做一些配置，这里笔者使用的是Tomcat7.0系列的和以前版本的Tomcat

           配置略有不同。

                 1、在项目的WebContent-META-INF下新建一个context.xml文件，注意必须在这个目录下配置。

            Tomcat会自动的找到这个文件(其实这是一种JNDI局部配置的方式)。

<?xml version="1.0" encoding="UTF-8"?><Context    crossContext="true"    path=""    reloadable="true" >    <Resource        name="jndi/mybatis" --mybatis一般设置为该项目的项目名        auth="Container" --该项为不可变项        driverClassName="com.mysql.jdbc.Driver" --数据库驱动名        maxActive="100" --最大连接数        maxIdle="30" --最大空闲连接数        maxWait="10000" --最大等待毫秒数，若为-1则无限等待        password="root"        type="javax.sql.DataSource" --该项为不可变项        url="jdbc:mysql://127.0.0.1:3306/manchat?autoReconnect=true" --url        username="root" /></Context>

             
                2、自Tomcat6.0之后我们就可以不在web.xml中做配置了。亲测可行！

              不过这里还是将其配置代码贴出来。 

<?xml version="1.0" encoding="UTF-8"?><web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">  <display-name>Test</display-name>  <welcome-file-list>    <welcome-file>index.html</welcome-file>    <welcome-file>index.htm</welcome-file>    <welcome-file>index.jsp</welcome-file>    <welcome-file>default.html</welcome-file>    <welcome-file>default.htm</welcome-file>    <welcome-file>default.jsp</welcome-file>  </welcome-file-list>  <resource-ref>  <description>JNDI DataSource</description>  <res-ref-name>jndi/mybatis</res-ref-name> --这里的名字应该要和context.xml的名字一样  <res-type>javax.sql.DataSource</res-type>  <res-auth>Container</res-auth>  </resource-ref></web-app>

                3、我们使用JNDI连接池技术来得到数据库的连接。

package com.kiritor;import java.sql.Connection;import java.sql.SQLException;import javax.naming.Context;import javax.naming.InitialContext;import javax.sql.DataSource;public class JNDIDB {  public static Connection bulidConnection()  {  Connection conn=null;  try {  InitialContext ctx = new InitialContext();  Context envContext = (Context) ctx.lookup("java:comp/env");  DataSource ds = (DataSource) envContext.lookup("jndi/mybatis");   conn = ds.getConnection();  }   catch(Exception e) {    e.printStackTrace();  }   return conn;   }}

               4、测试，注意这里不能简单的使用一个Main进行测试的，必须结合前台和后台进行测试。

            这里我们在JSP页面中调用JNDIDB的方法，看看是否产生一个conn对象。

<jsp:useBean id="db" class="com.kiritor.JNDIDB" /><%out.println(db.bulidConnection());%>

                  最后页面上确实产生了connection对象的，图就不贴了。

                 通过上述步骤我们看到了，似乎是用JNDI和传统的JDBC得到连接的代码量差不多，但JNDI却

             多了 更多的配置。那么JNDI的有点体现在哪里呢？

                  简单的说是用JNDI的配置虽然多了，但是在数据库的相关参数变更是，我们只需要重新修改一

             下 配置文件就行了，只要保证数据源的名字不变，那么程序的源代码就不需要改变，而传统JDBC

              的方式我们必须修改源文件，且对他进行重新编译。

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

           JNDI扩展

                     JNDI在满足了数据源配置的要求的基础上，还进一步扩充了作用：所有与系统外部的资源

              的引用，都可以通过JNDI定义和引用。所以，在J2EE规范中，J2EE 中的资源并不局限于 JDBC

              数据源。引用的类型有很多，其中包括资源引用（已经讨论过）、环境实体和 EJB 引用。特别是

              EJB 引用，它暴露了 JNDI 在 J2EE 中的另外一项关键角色：查找其他应用程序组件。

                    EJB 的 JNDI 引用非常类似于 JDBC 资源的引用。在服务趋于转换的环境中，这是一种很有效

              的方法。可以对应用程序架构中所得到的所有组件进行这类配置管理，从 EJB 组件到 JMS 队列和

              主题，再到简单配置字符串或其他对象，这可以降低随时间的推移服务变更所产生的维护成本，

              同时还可以简化部署，减少集成工作。 外部资源”。

          总结：

                  J2EE 规范要求所有 J2EE 容器都要提供 JNDI 规范的实现。JNDI 在 J2EE 中的角色就是“交换机”

           —— J2EE 组件在运行时间接地查找其他组件、资源或服务的通用机制。在多数情况下，提供 JNDI

           供应者的容器可以充当有限的数据存储，这样管理员就可以设置应用程序的执行属性，并让其他应用程

           序引用这些属性（Java 管理扩展（Java Management Extensions，JMX）也可以用作这个目的）。

           JNDI 在 J2EE 应用程序中的主要角色就是提供间接层，这样组件就可以发现所需要的资源，而不用了

           解这些间接性。

                 在 J2EE 中，JNDI 是把 J2EE 应用程序合在一起的粘合剂，JNDI 提供的间接寻址允许跨企业交付

            可伸缩的、功能强大且很灵活的应用程序。这是 J2EE 的承诺，而且经过一些计划和预先考虑，

            这个承诺是完全可以实现的。