为什么使用JNDI作为数据源

Question

任何人都可以帮助解释为什么JNDI应该是公开服务（如数据库/ jms）的首选方式吗？

我遇到的帖子都讨论了不需要加载特定驱动程序管理器，从连接池等获益的优点，但通过在属性文件中指定驱动程序管理器并使用反射可以轻松实现。

连接池也可以通过将正确实现通过弹簧或其他方式连接到应用程序bean中来实现。

那么为什么要使用JNDI会更好？

Answer 1

当您必须在环境之间移动应用程序时，JNDI才真正发挥作用：开发到集成以测试生产。如果您将每个应用服务器配置为使用相同的JNDI名称，则可以在每个环境中拥有不同的数据库，而不必更改代码。您只需拾取WAR文件并将其放入新环境。

这里有一些其他的假设是至关重要的了解判断这个答案时：

• 我没有获得关于该代码部署在所有的服务器，除了只读访问日志。
• 编写和打包代码的人与配置和管理服务器的人不是同一个人。
• 一旦WAR文件开始执行PROD时，它不能再次更改，而无需返回到开头。如果WAR被改变，任何由测试服务器上的QA完成的测试都必须重新进行。

也许你没有看到这种好处，因为你是一位在本地桌面上编写代码并部署生产权的独立开发人员。

Answer 2

我认为“首选”机制是做管理员和配置的人首选的机制。正如duffymo所指出的那样，配置对于可部署的工件来说是至关重要的，但除此之外，我会说什么都行。如果您的系统管理员更喜欢使用GUI来配置JDNI条目，那么很酷。如果他/她喜欢用cssh和vi编辑属性文件，也很酷。如果您负责开发和配置/部署您的应用程序，那么这就是您的呼叫。就我个人而言，我喜欢在我的工件中尽可能多地实施，这意味着我的数据源和驱动程序也在那里生存。

如果您想了解JNDI在替代方案方面的技术优势，我不确定有没有，但您可能想澄清一下您的问题。

Answer 3

正如其他人所提到的，JNDI大部分用于服务位置查找，但主要用于DB类资源。

最令人讨厌的是Java的LDAP API也是JNDI API。在使用LDAP时，抽象非常混乱。 JNDI有时也是单点故障的缺点。

通过使用主机名别名，您可以轻松完成JNDI所做的大部分工作。这是一个别名，在您的/etc/hosts（或您的env的任何地方）将MYRESOURCE指向127.0.0.1。然后在你的App配置中使用MYRESOURCE作为主机名（例如在一个jdbc url中）。

然后，当您将应用程序移至生产时，只需将生产的/etc/hosts文件更改为将MYRESOURCE指向生产资源/服务（如prod数据库服务器）即可。

上面是一个更方便的小脚印命名目录，将在其他语言（红宝石，python）工作的方式。它也可以处理通常不像JNDI那样使用REST服务的事情。唯一令人烦恼的是，你将不得不更新你的服务器主机文件，但这可以通过SSH脚本自动完成。

Answer 4

当部署到集群环境时，JNDI对属性文件的真正好处就来了。使用属性文件会导致某些服务器实例具有不同值的可能性。使用JNDI时，域控制器会将相同的值推送到所有群集服务器，从而无需将相同的属性文件复制到所有服务器（并且可能重新启动服务器/应用程序）。

Answer 5

另一个领域JNDI帮助：

它摘要资源的查找。通常，JNDI配置存储在应用程序服务器上的XML文件中，但不一定是。例如，该配置可能存储在LDAP服务器上，以便更易于集中维护。

如果您运行的应用程序使用JNDI来查找他们需要的内容，则可以从配置文件切换到使用LDAP服务器而不用修改应用程序。如果每个应用程序都期望一个带有硬编码名称的属性文件，那么您运气不好。想象一下，在生产中有几十个应用程序的企业 - 改变它们都将是一个重大问题。

换句话说，JNDI主要照耀复杂的部署方案，如：

• 许多应用服务器（可能是聚集的）
• 许多不同的应用
• 集中配置
• 不同的服务器级（测试，生产）

所以它可能看起来有点矫枉过正，但是非常这些场景很有用。当然，即使对于小型部署也有一些好处，例如DB连接的标准化配置。