再谈jndi

       在以前的blog中我曾谈到了jndi，在最近的学习中发现还是有些对jndi的新的见解的地方需要探讨。 

       我们知道jndi是java的命名和目录服务的api，为什么要有它了，是因为我们在网络条件下可能要查找和使用一些分布式的资源。好比我们现在使用的操作系统，它本身有一个类似于jndi的东西，这样我们才能找到和存放一些资源，如文件等。例如windows系统的分区和目录，它就是一个目录服务，还有linux的以文件夹的方式也是相当于一个目录服务；DNS就是一个命名服务等等，这些应用都有jndi的影子。考虑在网络条件下，我们要查找一个资源，我们不知道它所在的机器是什么操作系统，采用的什么目录和命名模式，所以sun提供了一个更高层次的接口，即jndi，让我们查找和使用资源是忽略这些不同的地方。否则试想一下以windows的目录结构试着去匹配linux的目录结构肯定是不行的。

      sun给的jndi只是个接口，各家都有自己的实现，这些实现就包括了一个统一的目录结构和查找（包括索引）。sun本身的jdk给了4种实现，还包含另一种简单的以文件系统为命名服务的实现。

     通常我们在程序中new出Context（在目录结构中的每一个结点称为context。每一个JNDI名字都是相对于context的）需要提及做些工作（如果是在j2ee容器中的代码则不必），需要两步，一是实现类的initcontextfactory,另一个就是provider_url,它我感觉相当于给出具体资源在什么位置，并且以什么协议的形式作为其目录方案。有了这两个我们就能new出context,然后lookup出资源。以文件系统为命名服务的更简单，它只须一个factory就可以了。