为什么将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的大部分工作。这是一个别名，它将MYRESOURCE指向127.0.0.1中的/etc/hosts（或者您的环境的任何地方）。然后在您的App配置中使用MYRESOURCE作为主机名（例如，在jdbc url中）。

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

以上是一种更便携的小型脚本命名目录，可以在其他语言中工作（ruby，python）。它也适用于通常不像JNDI那样用REST服务完成的事情。唯一令人烦恼的是，您必须更新服务器主机文件，但这可以通过SSH脚本自动完成。

Answer 4

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

Answer 5

JNDI帮助的另一个领域：

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

如果您运行的应用程序使用JNDI查找所需内容，则可以从配置文件切换到使用LDAP服务器而无需修改应用程序。如果每个应用程序都需要一个带有硬编码名称的属性文件，那么你就不走运了。想象一下，一个拥有数十个生产应用程序的企业 - 将它们全部更改将是一个重大问题。

换句话说，JNDI主要针对复杂的部署方案，例如：

• 许多应用程序服务器（可能是群集的）
• 许多不同的应用程序
• 集中配置
• 不同的服务器阶段（测试，制作）

一开始看起来有点矫枉过正，但在这些场景中非常有用。当然，即使对于小型部署，例如DB连接的标准化配置，也会有一些好处。