JAVA JNDI簡介

JNDI是 Java 命名與目錄接口（Java Naming and Directory Interface），在J2EE規範中是重要的規範之一，不少專家認為，沒有透徹了解JNDI的意義和作用，就沒有真正掌握J2EE特别是EJB的知識。

那麼，JNDI到底起什麼作用？

要了解JNDI的作用，我們可以從“如果不用JNDI我們怎樣做？用了JNDI後我們又将怎樣做？”這個問題來探讨。

1. 沒有JNDI的做法

程式員開發時，知道要開發通路MySQL資料庫的應用，于是将一個對 MySQL JDBC 驅動程式類的引用進行了編碼，并通過使用适當的 JDBC URL 連接配接到資料庫。

就像以下代碼這樣：

Connection conn=null;

try {

   Class.forName("com.mysql.jdbc.Driver",

                 true, Thread.currentThread().getContextClassLoader());

   conn=DriverManager.getConnection("jdbc:mysql://MyDBServer?user=qingfeng&password=mingyue");

   conn.close();

}

catch(Exception e) {

   e.printStackTrace();

}

finally {

   if(conn!=null) {

     try {

       conn.close();

     } catch(SQLException e) {}

   }

}

這是傳統的做法，也是以前非Java程式員（如Delphi、VB等）常見的做法。這種做法一般在小規模的開發過程中不會産生問題，隻要程式員熟悉Java語言、了解JDBC技術和MySQL，可以很快開發出相應的應用程式。

沒有JNDI的做法存在的問題：

1、資料庫伺服器名稱MyDBServer 、使用者名和密碼都可能需要改變，由此引發JDBC URL需要修改；

2、資料庫可能改用别的産品，如改用DB2或者Oracle，引發JDBC驅動程式包和類名需要修改；

3、随着實際使用終端的增加，原配置的連接配接池參數可能需要調整；

4、......

解決辦法：

程式員應該不需要關心“具體的資料庫背景是什麼？JDBC驅動程式是什麼？JDBC URL格式是什麼？通路資料庫的使用者名和密碼是什麼？”等等這些問題，程式員編寫的程式應該沒有對 JDBC 驅動程式的引用，沒有伺服器名稱，沒有使用者名稱或密碼 —— 甚至沒有資料庫池或連接配接管理。而是把這些問題交給J2EE容器來配置和管理，程式員隻需要對這些配置和管理進行引用即可。

由此，就有了JNDI。

2. 用了JNDI之後的做法

首先，在在J2EE容器中配置JNDI參數，定義一個資料源，也就是JDBC引用參數，給這個資料源設定一個名稱；然後，在程式中，通過資料源名稱引用資料源進而通路背景資料庫。

具體操作如下（以JBoss為例）：

1、配置資料源

在JBoss的 D:"jboss420GA"docs"examples"jca 檔案夾下面，有很多不同資料庫引用的資料源定義模闆。将其中的 mysql-ds.xml 檔案Copy到你使用的伺服器下，如 D:"jboss420GA"server"default"deploy。

修改 mysql-ds.xml 檔案的内容，使之能通過JDBC正确通路你的MySQL資料庫，如下：

<?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>

這裡，定義了一個名為MySqlDS的資料源，其參數包括JDBC的URL，驅動類名，使用者名及密碼等。 

Tomcat中的配置方法：

<context path="/tudu" docbase="/home/web/Tudu &gt;&lt;br /&gt;&lt;Resource name=" auth="Container" type="javax.sql.DataSource">

<resourceparams name="jdbc/tudu">

<parameter>

<name>username</name>

<value>system</value>

</parameter>

<parameter>

<name>password</name>

<value>manager</value>

</parameter>

<parameter>

<name>driverClassName</name>

<value>com.mysql.jdbc.Driver</value>

</parameter>

<parameter>

<name>url</name>

<value>jdbc:mysql://localhost:3306/tudu</value>

</parameter>

</resourceparams>

</context>

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 規範的實作。JNDI 在 J2EE 中的角色就是“交換機” —— J2EE 元件在運作時間接地查找其他元件、資源或服務的通用機制。在多數情況下，提供 JNDI 供應者的容器可以充當有限的資料存儲，這樣管理者就可以設定應用程式的執行屬性，并讓其他應用程式引用這些屬性（Java 管理擴充（Java Management Extensions，JMX）也可以用作這個目的）。JNDI 在 J2EE 應用程式中的主要角色就是提供間接層，這樣元件就可以發現所需要的資源，而不用了解這些間接性。

在 J2EE 中，JNDI 是把 J2EE 應用程式合在一起的粘合劑，JNDI 提供的間接尋址允許跨企業傳遞可伸縮的、功能強大且很靈活的應用程式。這是 J2EE 的承諾，而且經過一些計劃和預先考慮，這個承諾是完全可以實作的。