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?<code class="html string">autoReconnect=true</code>" --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 的承諾，而且經過一些計劃和預先考慮，

            這個承諾是完全可以實現的。