为什么使用JNDI来处理数据源
任何人都可以帮助解释为什么JNDI应该是一个暴露服务，如数据库/ JMS的首选方式？
我遇到的post都谈到了无需加载特定的驱动程序pipe理器的好处，从连接池等方面的好处，但通过在属性文件中指定驱动程序pipe理器并使用reflection，可以轻松实现。
连接池也可以通过将正确的实现通过弹簧或其他方式连接到应用程序bean来实现。
那么为什么使用JNDI会更好呢？
当你必须在环境之间移动一个应用程序时，JNDI才会真正的发光：开发到集成，testing到生产。 如果将每个应用程序服务器configuration为使用相同的JNDI名称，则可以在每个环境中使用不同的数据库，而不必更改代码。 您只需拿起WAR文件并将其放在新环境中即可。
以下是判断这个答案时很重要的其他假设：
- 除了对日志的只读访问外，我根本无法访问部署代码的服务器。
- 编写和打包代码的人不是configuration和pipe理服务器的同一个人。
- 一旦一个WAR文件启动到PROD的行程，它不能再被改变，而不会回到开始。 如果WAR被改变，任何由testing服务器上的QA完成的testing都必须重新进行。
也许你没有看到这样的好处，因为你是一个在本地桌面上编写代码并部署生产权的独立开发者。
我认为“首选”机制是做pipe理员和configuration人员所喜欢的机制。 正如duffymo所指出的那样，configuration在可部署的工件外部是至关重要的，否则，我会说什么都行。 如果你的系统pipe理员更喜欢使用GUI来configurationJDNI条目，那么很酷。 如果他/她喜欢用cssh和vi编辑属性文件，那么也很酷。 如果你负责开发和configuration/部署你的应用程序，那么这几乎是你的电话。 就我个人而言，我喜欢在我的工件内保留尽可能多的实现，这意味着我的数据源和驱动程序也在那里生存。
如果您问到JNDI在替代方面的技术优势，我不确定有没有，但是您可能想澄清一下您的问题。
正如其他人所提到的，JNDI大部分用于服务位置查找，但主要针对数据库资源。
最令人讨厌的是Java的LDAP API也是JNDI API。 使用LDAP时，抽象是非常混乱的。 JNDI也有缺点，有时是单点故障。
通过使用主机名别名，您可以轻松完成JNDI所做的大部分工作。 这是一个别名，指出你的/etc/hosts MYRESOURCE为127.0.0.1 （或者你的env在哪里）。 然后在你的Appconfiguration中使用MYRESOURCE作为主机名（例如在一个jdbc url中）。
然后，当您将应用程序移至生产环境时，只需将生产的/etc/hosts文件更改为将MYRESOURCE指向生产资源/服务（如prod数据库服务器）即可。
以上是一个更便携的小脚印命名目录，将在其他语言（ruby，python）的工作方式。 它也可以处理通常不像JNDI那样使用REST服务的事情。 唯一烦人的是你将不得不更新你的服务器主机文件，但是这可以通过SSH脚本自动完成。
在部署到集群环境时，JNDI对属性文件的真正好处就来了。 使用属性文件可能会导致某些服务器实例具有不同的值。 使用JNDI时，域控制器会将相同的值推送到所有群集服务器，从而无需将相同的属性文件复制到所有服务器（并可能重新启动服务器/应用程序）。
JNDI帮助的另一个领域是：
它抽象了资源的查找。 通常，JNDIconfiguration存储在应用程序服务器上的XML文件中，但不一定是。 例如，可以将configuration存储在LDAP服务器上，以便更易于集中维护。
如果您运行的应用程序使用JNDI来查找它们所需的内容，则可以从configuration文件切换到使用LDAP服务器， 而无需修改应用程序 。 如果每个应用程序都期望一个带有硬编码名称的属性文件，那么您运气不好。 想象一下，在生产中有几十个应用程序的企业 – 改变它们都是一个重大的问题。
换句话说，JNDI主要用于复杂的部署场景，如：
- 许多应用程序服务器（可能集群）
- 许多不同的应用
- 集中configuration
- 不同的服务器阶段（testing，生产）
所以起初可能看起来有点矫枉过正，但在这些场景中非常有用。 当然，即使对于小型部署也有一些好处，例如DB连接的标准化configuration。
检查url，以获得良好的演示文稿： http : //www.databaseskill.com/216815/
