早期的 EJB 有個“EJB 裝配者”的角色，這種實際的工作模式，也許只有 Sun 公司才會有，其它大部分公司都不會有此類角色----大部分公司，都是小型公司，人員分工沒有這么細，很多IT系統，連接池參數的調整，是由開發人員完成。 JNDI 也陷入了類似的角色分工問題：很多公司的角色分工與 Sun 公司不一樣，Sun 把一個角色分工問題，引入到技術層面，可以想象，問題是很大的。

    拋開一大堆技術名詞，JNDI 本質是把一些環境變量配置參數放在一起集中維護，或者把可以遠程調用的 Java 對象，放在一起集中維護。

    其優點是：

a. 分工更專業，可以讓一個人管理多個系統的相同的部分，比如數據庫連接池配置參數。

b. 其它的優點，沒有了。

 

    早期的 EJB 有個“EJB 裝配者”的角色，這種實際的工作模式，也許只有 Sun 公司才會有，其它大部分公司都不會有此類角色----大部分公司，都是小型公司，人員分工沒有這么細，很多IT系統，連接池參數的調整，是由開發人員完成。

 

    JNDI 也陷入了類似的角色分工問題：很多公司的角色分工與 Sun 公司不一樣，Sun 把一個角色分工問題，引入到技術層面，可以想象，問題是很大的。

 

    JNDI 集中維護，帶來一個風險，那就是，單點故障風險。

    假設我有10個IT系統，都用到 JNDI , 如果運行 JNDI 的服務器癱瘓，那么我這10個IT系統都不能正常工作，影響太大了。稍微有點頭腦的人，都會立即想到：分散風險，每個IT系統的服務器，在同一臺計算機上運行 JNDI服務。這樣問題就來了：還要 JNDI 做什么？

 

    JNDI 剛開始出現的時候，使用 JNDI 有一個特別的目的：有 JNDI 功能支持的 Java EE 服務器，帶有連接池。用了 JNDI 就用了連接池。然后，很快 Apache DBCP 和 BoneCP 等獨立的數據庫連接池組件出現了。如果我用 DBCP ，把數據庫連接參數寫在環境變量中，數據庫連接池參數寫在初始化代碼處，相比 JNDI 而言，有什么不好么？沒有。

 

    結論：JNDI 無用。

---------歡迎大家下載試用我們的 web 單點登錄系統, http://zheguisoft.com