JNDI 的理解
阿新 • • 發佈：2017-08-18
並且 data enume 級別 java程序 -name 管理 and cti
JNDI是 Java 命名與文件夾接口（Java Naming and Directory Interface），在J2EE規範中是重要的規範之中的一個，不少專家覺得，沒有透徹理解JNDI的意義和作用，就沒有真正掌握J2EE特別是EJB的知識。
那麽，JNDI究竟起什麽作用？//帶著問題看文章是最有效的
要了解JNDI的作用，我們能夠從“假設不用JNDI我們如何做？用了JNDI後我們又將如何做？”這個問題來探討。
沒有JNDI的做法：
程序猿開發時，知道要開發訪問MySQL數據庫的應用，於是將一個對 MySQL JDBC 驅動程序類的引用進行了編碼，並通過使用適當的 JDBC URL 連接到數據庫。
就像以下代碼這樣：
Java代碼
這是傳統的做法，也是曾經非Java程序猿（如Delphi、VB等）常見的做法。
沒有JNDI的做法存在的問題：
1、數據庫server名稱MyDBServer 、username和口令都可能須要改變，由此引發JDBC URL須要改動；
2、數據庫可能改用別的產品，如改用DB2或者Oracle，引發JDBC驅動程序包和類名須要改動；
3、隨著實際使用終端的添加，原配置的連接池參數可能須要調整；
4、......
解決的方法：
程序猿應該不須要關心“詳細的數據庫後臺是什麽？JDBC驅動程序是什麽？JDBC URL格式是什麽？訪問數據庫的username和口令是什麽？”等等這些問題。程序猿編寫的程序應該沒有對 JDBC 驅動程序的引用，沒有server名稱，沒實username稱或口令 —— 甚至沒有數據庫池或連接管理。
由此，就有了JNDI。
//看的出來。是為了一個最最核心的問題：是為了解耦，是為了開發出更加可維護、可擴展//的系統
用了JNDI之後的做法：
首先。在在J2EE容器中配置JNDI參數，定義一個數據源。也就是JDBC引用參數，給這個數據源設置一個名稱；然後，在程序中，通過數據源名稱引用數據源從而訪問後臺數據庫。
//紅色的字能夠看出。JNDI是由j2ee容器提供的功能
詳細操作例如以下（以JBoss為例）：
1、配置數據源
在JBoss 的 D:\jboss420GA\docs\examples\jca 文件夾以下。有非常多不同數據庫引用的數據源定義模板。
改動 mysql-ds.xml 文件的內容，使之能通過JDBC正確訪問你的MySQL數據庫。例如以下：
Java代碼
這裏，定義了一個名為MySqlDS的數據源。其參數包含JDBC的URL。驅動類名，username及密碼等。
2、在程序中引用數據源：
Java代碼
直接使用JDBC或者通過JNDI引用數據源的編程代碼量相差無幾，可是如今的程序能夠不用關心詳細JDBC參數了。//解藕了。可擴展了
在系統部署後。假設數據庫的相關參數變更。僅僅須要又一次配置 mysql-ds.xml 改動當中的JDBC參數，僅僅要保證數據源的名稱不變，那麽程序源碼就無需改動。
由此可見。JNDI避免了程序與數據庫之間的緊耦合，使應用更加易於配置、易於部署。
JNDI的擴展：
JNDI在滿足了數據源配置的要求的基礎上。還進一步擴充了作用：全部與系統外部的資源的引用，都能夠通過JNDI定義和引用。
//註意什麽叫資源
所以，在J2EE規範中，J2EE 中的資源並不局限於 JDBC 數據源。
EJB 的 JNDI 引用非常相似於 JDBC 資源的引用。在服務趨於轉換的環境中，這是一種非常有效的方法。能夠對應用程序架構中所得到的全部組件進行這類配置管理，從 EJB 組件到 JMS 隊列和主題。再到簡單配置字符串或其它對象。這能夠降低隨時間的推移服務變更所產生的維護成本，同一時候還能夠簡化部署，降低集成工作。外部資源”。
總結：
J2EE 規範要求全部 J2EE 容器都要提供 JNDI 規範的實現。//sun 果然喜歡制定規範JNDI 在 J2EE 中的角色就是“交換機” —— J2EE 組件在執行時間接地查找其它組件、資源或服務的通用機制。在多數情況下，提供 JNDI 供應者的容器能夠充當有限的數據存儲。這樣管理員就能夠設置應用程序的執行屬性，並讓其它應用程序引用這些屬性（Java 管理擴展（Java Management Extensions，JMX）也能夠用作這個目的）。JNDI 在 J2EE 應用程序中的主要角色就是提供間接層，這樣組件就能夠發現所須要的資源，而不用了解這些間接性。
在 J2EE 中，JNDI 是把 J2EE 應用程序合在一起的粘合劑。JNDI 提供的間接尋址同意跨企業交付可伸縮的、功能強大且非常靈活的應用程序。
從上面的文章中能夠看出：
1、JNDI 提出的目的是為了解藕，是為了開發更加easy維護，easy擴展。easy部署的應用。
2、JNDI 是一個sun提出的一個規範(相似於jdbc),詳細的實現是各個j2ee容器提供商。sun 僅僅是要求，j2ee容器必須有JNDI這種功能。
JNDI全稱 Java Naming and Directory Interface
JNDI是Java平臺的一個標準擴展，提供了一組接口、類和關於命名空間的概念。如同其它非常多Java技術一樣，JDNI是provider-based的技術，暴露了一個API和一個服務供應接口（SPI）。這意味著不論什麽基於名字的技術都能通過JNDI而提供服務。僅僅要JNDI支持這項技術。
JDNI通過綁定的概念將對象和名稱聯系起來。
JNDI中的一組綁定作為上下文來引用。每一個上下文暴露的一組操作是一致的。比如，每一個上下文提供了一個查找操作。返回指定名字的對應對象。每一個上下文都提供了綁定和撤除綁定名字到某個對象的操作。
jndi的用途：
1。你能夠用jndi來得到object類的屬性
如：
Java代碼
2。你能夠用jndi來搜索對象
如：
Java代碼
查找誰的名字叫Fox在wiz部門的員工？
3。你能夠用jndi通過naming/directory服務查詢像printers和databases的對象
如：查詢 Printer
Java代碼
4。你能夠用jndi列表出命名空間的特殊級別的內容
如：
Java代碼
那麽，JNDI究竟起什麽作用？//帶著問題看文章是最有效的
要了解JNDI的作用，我們能夠從“假設不用JNDI我們如何做？用了JNDI後我們又將如何做？”這個問題來探討。
沒有JNDI的做法：
程序猿開發時，知道要開發訪問MySQL數據庫的應用，於是將一個對 MySQL JDBC 驅動程序類的引用進行了編碼，並通過使用適當的 JDBC URL 連接到數據庫。
就像以下代碼這樣：
Java代碼
- 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、數據庫server名稱MyDBServer 、username和口令都可能須要改變，由此引發JDBC URL須要改動；
2、數據庫可能改用別的產品，如改用DB2或者Oracle，引發JDBC驅動程序包和類名須要改動；
3、隨著實際使用終端的添加，原配置的連接池參數可能須要調整；
4、......
解決的方法：
程序猿應該不須要關心“詳細的數據庫後臺是什麽？JDBC驅動程序是什麽？JDBC URL格式是什麽？訪問數據庫的username和口令是什麽？”等等這些問題。程序猿編寫的程序應該沒有對 JDBC 驅動程序的引用，沒有server名稱，沒實username稱或口令 —— 甚至沒有數據庫池或連接管理。
而是把這些問題交給J2EE容器（比方weblogic）來配置和管理，程序猿僅僅須要對這些配置和管理進行引用就可以。
由此，就有了JNDI。
//看的出來。是為了一個最最核心的問題：是為了解耦，是為了開發出更加可維護、可擴展//的系統
用了JNDI之後的做法：
首先。在在J2EE容器中配置JNDI參數，定義一個數據源。也就是JDBC引用參數，給這個數據源設置一個名稱；然後，在程序中，通過數據源名稱引用數據源從而訪問後臺數據庫。
//紅色的字能夠看出。JNDI是由j2ee容器提供的功能
詳細操作例如以下（以JBoss為例）：
1、配置數據源
在JBoss 的 D:\jboss420GA\docs\examples\jca 文件夾以下。有非常多不同數據庫引用的數據源定義模板。
將當中的 mysql-ds.xml 文件Copy到你使用的server下，如 D:\jboss420GA\server\default\deploy。
改動 mysql-ds.xml 文件的內容，使之能通過JDBC正確訪問你的MySQL數據庫。例如以下：
Java代碼
- <?
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。驅動類名，username及密碼等。
2、在程序中引用數據源：
Java代碼
- 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 規範的實現。//sun 果然喜歡制定規範JNDI 在 J2EE 中的角色就是“交換機” —— J2EE 組件在執行時間接地查找其它組件、資源或服務的通用機制。在多數情況下，提供 JNDI 供應者的容器能夠充當有限的數據存儲。這樣管理員就能夠設置應用程序的執行屬性，並讓其它應用程序引用這些屬性（Java 管理擴展（Java Management Extensions，JMX）也能夠用作這個目的）。JNDI 在 J2EE 應用程序中的主要角色就是提供間接層，這樣組件就能夠發現所須要的資源，而不用了解這些間接性。
在 J2EE 中，JNDI 是把 J2EE 應用程序合在一起的粘合劑。JNDI 提供的間接尋址同意跨企業交付可伸縮的、功能強大且非常靈活的應用程序。
這是 J2EE 的承諾，並且經過一些計劃和預先考慮。這個承諾是全然能夠實現的。
從上面的文章中能夠看出：
1、JNDI 提出的目的是為了解藕，是為了開發更加easy維護，easy擴展。easy部署的應用。
2、JNDI 是一個sun提出的一個規範(相似於jdbc),詳細的實現是各個j2ee容器提供商。sun 僅僅是要求，j2ee容器必須有JNDI這種功能。
3、JNDI 在j2ee系統中的角色是“交換機”，是J2EE組件在執行時間接地查找其它組件、資源或服務的通用機制。
4、JNDI 是通過資源的名字來查找的，資源的名字在整個j2ee應用中(j2ee容器中)是唯一的。
再轉一篇文章：
JNDI全稱 Java Naming and Directory Interface
JNDI是Java平臺的一個標準擴展，提供了一組接口、類和關於命名空間的概念。如同其它非常多Java技術一樣，JDNI是provider-based的技術，暴露了一個API和一個服務供應接口（SPI）。這意味著不論什麽基於名字的技術都能通過JNDI而提供服務。僅僅要JNDI支持這項技術。
JNDI眼下所支持的技術包含LDAP、CORBA Common Object Service（COS）名字服務、RMI、NDS、DNS、Windows註冊表等等。非常多J2EE技術，包含EJB都依靠JNDI來組織和定位實體。
JDNI通過綁定的概念將對象和名稱聯系起來。
在一個文件系統中。文件名稱被綁定給文件。在DNS中，一個IP地址綁定一個URL。在文件夾服務中。一個對象名被綁定給一個對象實體。
JNDI中的一組綁定作為上下文來引用。每一個上下文暴露的一組操作是一致的。比如，每一個上下文提供了一個查找操作。返回指定名字的對應對象。每一個上下文都提供了綁定和撤除綁定名字到某個對象的操作。
JNDI使用通用的方式來暴露命名空間，即使用分層上下文以及使用同樣命名語法的子上下文。
jndi的用途：
1。你能夠用jndi來得到object類的屬性
如：
Java代碼
- Attribute attr =directory.getAttributes(personName).get("email");
- String email = (String)attr.get();
2。你能夠用jndi來搜索對象
如：
Java代碼
- foxes = directory.search("o=Wiz,c=US", "sn=Fox", controls);
查找誰的名字叫Fox在wiz部門的員工？
3。你能夠用jndi通過naming/directory服務查詢像printers和databases的對象
如：查詢 Printer
Java代碼
- Printer printer = (Printer)namespace.lookup(printerName);
- printer.print(document);
4。你能夠用jndi列表出命名空間的特殊級別的內容
如：
Java代碼
- NamingEnumeration list = namespace.list("o=Widget, c=US";
- while (list.hasMore()) {
- NameClassPair entry = (NameClassPair)list.next();
- display(entry.getName(), entry.getClassName());
- }
JNDI 的理解