Java命名與目錄接口——JNDI

jndi是 java

命名與目錄接口（java naming and directory interface），在j2ee規範中是重要的規範之一，不少專家認為，沒有透徹了解jndi的意義和作用，就沒有真正掌握j2ee特别是ejb的知識。jndi到底起什麼作用？

沒有jndi的做法

程式員開發時，知道要開發通路mysql資料庫的應用，于是将一個對

mysql jdbc 驅動程式類的引用進行了編碼，并通過使用适當的 jdbc url

連接配接到資料庫。

就像以下代碼這樣：

connection conn=null;

class.forname("com.mysql.jdbc.driver", true, thread.currentthread().getcontextclassloader());

conn=drivermanager.getconnection("jdbc:mysql://mydbserver?user=qingfeng&password=mingyue");

 ......

conn.close();

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

存在的問題

1、資料庫伺服器名稱mydbserver

、使用者名和密碼都可能需要改變，由此引發jdbc url需要修改；

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

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

jndi的産生

程式員應該不需要關心“具體的資料庫背景是什麼？jdbc驅動程式是什麼？jdbc

url格式是什麼？通路資料庫的使用者名和密碼是什麼？”等等這些問題，程式員編寫的程式應該沒有對

jdbc 驅動程式的引用，沒有伺服器名稱，沒有使用者名稱或密碼 ——

甚至沒有資料庫池或連接配接管理。而是把這些問題交給j2ee容器來配置和管理，程式員隻需要對這些配置和管理進行引用即可。由此就有了jndi。

用了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，驅動類名，使用者名及密碼等。

2、在程式中引用資料源

context ctx=new initialcontext();

object datasourceref=ctx.lookup("java:mysqlds"); //引用資料源

datasource ds=(datasource)datasourceref;

conn=ds.getconnection();

......

c.close();

直接使用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 元件在運作時間接地查找其他元件、資源或服務的通用機制。在多數情況下，提供 jndi

供應者的容器可以充當有限的資料存儲，這樣管理者就可以設定應用程式的執行屬性，并讓其他應用程式引用這些屬性（java

管理擴充（java management extensions，jmx）也可以用作這個目的）。jndi

應用程式中的主要角色就是提供間接層，這樣元件就可以發現所需要的資源，而不用了解這些間接性。

中，jndi

是把 j2ee

應用程式合在一起的粘合劑，jndi

提供的間接尋址允許跨企業傳遞可伸縮的、功能強大且很靈活的應用程式。這是 j2ee

的承諾，而且經過一些計劃和預先考慮，這個承諾是完全可以實作的。