JNDI的理解
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資料庫,如下:
- <?xmlversion="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 的承諾,而且經過一些計劃和預先考慮,這個承諾是完全可以實現的。