JNDI 是什麼 .

JNDI是 Java 命名與目錄介面（Java Naming and Directory Interface），在J2EE規範中是重要的規範之一，不少專家認為，沒有透徹理解JNDI的意義和作用，就沒有真正掌握J2EE特別是EJB的知識。 那麼，JNDI到底起什麼作用。 要瞭解JNDI的作用，我們可以從“如果不用JNDI我們怎樣做。用了JNDI後我們又將怎樣做。”這個問題來探討。 沒有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並進行SQL操作 */ ...... 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。 用了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、在程式中引用資料來源： Connection conn=null;try { Context ctx=new InitialContext(); Object datasourceRef=ctx.lookup("java:MySqlDS"); //引用資料來源 DataSource ds=(Datasource)datasourceRef; conn=ds.getConnection(); /* 使用conn進行資料庫SQL操作 */ ...... 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 的承諾，而且經過一些計劃和預先考慮，這個承諾是完全可以實現的。