早期的 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 无用。