JavaEE 中无用技术之 JNDI

2012-03-13 14:47

 

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

 

 

欢迎转载,转载请注明出处: https://www.zheguisoft.com/staff_blogs/jacklondon_chen/2012, 及 https://www.cnblogs.com/jacklondon/archive/2012/03/13/2393852.html