在以前的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就可以了。