JNDI，Java Naming Directory Interface，J2EE的标准之一，所有的J2EE容器都必须提供一个JNDI的服务，但是，我一直都没用过，至少是没有刻意地去用过。因为，我也曾经把数据源配置在Tomcat的JNDI服务中，但那时，我也只是刚刚涉足JAVA，有人告诉我应该这么干而已。后来，我开始使用自定义的数据库连接配置文件，就再也没有跟JNDI打过交道了，直到今天。
现在之所以又想看一下，只是因为觉得这是J2EE的重要标准之一，如果不懂得的话，似乎有点说不过去。
JNDI的主要功能可以这样描述，它使用一张哈希表存储对象（大多数的J2EE容器也的确是这样做的），然后，开发人员可以使用键值——也就是一个字符串——来获取这个对象。这里就包括取JNDI的两个最主要操作，bind和lookup。bind操作负责往哈希表里存对象，存对象的时候要定义好对象的键值字符串，lookup则根据这个键值字符串往外取对象。
JNDI的命称可能会让人产生混淆，似乎觉得这是一个用来操作目录的，事实上，我更愿意把这个目录理解成为JNDI存放对象时使用的格式，也就是说，JNDI以目录的方式存储对象的属性。例如，用户通过JNDI存储一个汽车对象，那么，汽车就是根目录，汽车的轮子、引擎之类的子对象就算是子目录，而属性，比如说汽车的牌子、重量之类，就算是汽车目录下的文件。
JNDI的功能既然就是根据一个字符串键值就可以取得一个想要得到的对象，我一开始就觉得这不是跟COM或CORBA一样吗？SUN也是有野心的企业啊，JNDI应该就是它要努力推行的JAVA下的分布式开发的标准吧。
JNDI的出现应该就是为了分步式开发服务的，有人负责开发这种分布式对象，有人只需要使用这些分布式对象就可以了，这两组人不必属于同一个公司，而且这种开发通常应该是不并行的，也不必是会了同一个项目服务。就如果数据源对象，它放在JNDI中，只要想要用的人，直接通过JNDI服务取来用就可以了，至于当初是谁把它放进JNDI中的，还是不用操这份心了吧。而我一直没有使用JNDI，也就是这个原因，项目中的所有对象都在我控制之下，我不去使用别人的对象，也没打算把我的对象贡献出来给别人使用，那自然也就没必要去跟JNDI打交道。我觉得是否使用JNDI，这应该是关键原因，至于什么方便性、安全性之类的考虑，应该不是JNDI的主要目的，就如同你可以用JAVA来做网站，但JAVA并不是专门用来做网站的。
可能有人觉得这种功能跟IoC也很象，这个我倒不觉得，虽然对于对象的使用人员来说的确是这种感觉，且不说IoC需要为对象定义接口，而JNDI并无此限制，先说这里有一个使用环境问题，我觉得IoC是用来解决并行开发问题的，也就是说IoC主要是用于明确设计人员与实现/使用人员的分工，无论是设计的，还是使用的，通常是一个项目组里的人，使用IoC，可以使得设计人员专注于设计，加快设计速度。因此，IoC的用途要比JNDI广泛的多，现在大型系统中，不使用IoC的，几稀矣。
以上废话是为题记。