为什么将 JNDI 用于数据源答案

【问题标题】：Why use JNDI for data sources为什么将 JNDI 用于数据源
【发布时间】：2011-12-07 07:47:19
【问题描述】：

谁能帮助解释为什么 JNDI 应该是公开数据库/jms 等服务的首选方式？

我遇到的所有帖子都谈到了不必加载特定驱动程序管理器、受益于连接池等的优点，但这很容易通过在属性文件中指定驱动程序管理器并使用反射来实现。

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

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

【问题讨论】：

【解决方案1】：

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

以下是判断此答案时需要了解的一些其他假设：

除了对日志的只读访问权限外，我根本无权访问部署代码的服务器。
编写和打包代码的人不是配置和管理服务器的人。
一旦 WAR 文件开始其到 PROD 的旅程，它就无法再次更改，除非回到开始。如果 WAR 被更改，QA 在测试服务器上完成的任何测试都必须重新完成。

也许您看不到这种好处，因为您是一个在本地桌面上编写代码并直接部署到生产环境的开发人员。

【讨论】：

那么这与在每个环境中都有一个属性文件有什么不同呢？毕竟，管理员正在管理每台服务器上的数据库连接。
属性文件通常打包在 WAR 中，因此您无需更改它们。您必须按环境区分文件并传递一个变量来识别您的位置。如果你真的很喜欢按照自己的方式去做，那么一定要这样做。我不想卖任何东西；你听起来不像真的想承认任何差异。有些人只是喜欢让他们的想法得到验证；也许你就是其中之一。
我只是想真正了解其中的区别，仅此而已:) 如果我理解正确，使用 JNDI 可以让容器管理这些属性，因此您不必在自己的文件中管理它们.我还看到一些关于通过属性文件设置 jndi 配置的帖子 - activemq.apache.org/jndi-support.html - 那么这是否在某种程度上违背了目的？
当我在 WAR 文件中进行部署时，我总是这样做，我的 CLASSPATH 由 WEB-INF/lib 中的 JAR 和 WEB-INF/classes 下的包组成 - 就是这样。除非我为 WAR 中的每个环境都放置一个 .properties 文件，否则在我转向 PROD 时我不会更改任何内容。我不依赖 CLASSPATH 环境变量或脚本更改，因为我无权访问我部署的服务器。
您可以通过使用主机名别名轻松完成 JNDI 所做的大部分工作。那就是在 /etc/hosts 中创建一个别名，将 MYRESOURCE 指向 127.0.0.1 （或者它在你的环境中的任何位置）。然后在您的应用程序配置中使用 MYRESOURCE（例如在 jdbc url 中）。在那里，您刚刚创建了一种更便携的更小的足迹命名目录，可以在其他语言（ruby、python）中使用。

【解决方案2】：

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

如果您询问 JNDI 相对于替代方案的技术优势，我不确定是否有任何优势，但您可能想澄清您的问题。

【讨论】：

【解决方案3】：

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

最烦人的是Java 的LDAP API 也是JNDI API。使用 LDAP 时，抽象非常混乱。 JNDI 还有一个缺点，就是有时会出现单点故障。

您可以通过使用主机名别名轻松完成 JNDI 所做的大部分工作。那就是在您的/etc/hosts（或您的环境中的任何位置）中创建一个将MYRESOURCE 指向127.0.0.1 的别名。然后在您的应用配置中使用 MYRESOURCE 作为主机名（例如在 jdbc url 中）。

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

以上是一种更便携、占用空间更小的命名目录，适用于其他语言（ruby、python）。它也适用于 JNDI 通常无法完成的事情，例如 REST 服务。唯一烦人的是您必须更新您的服务器主机文件，但这可以通过 SSH 脚本自动完成。

【讨论】：

【解决方案4】：

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

【讨论】：

【解决方案5】：

JNDI 提供帮助的另一个领域：

它抽象资源的查找。通常，JNDI 配置存储在应用程序服务器上的 XML 文件中，但并非必须如此。例如，配置可能存储在 LDAP 服务器上，以便于集中维护。

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

也就是说，JNDI 主要适用于复杂的部署场景，比如：

许多应用服务器（可能是集群的）
许多不同的应用程序
集中配置
不同的服务器阶段（测试、生产）

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

【讨论】：

“不修改应用程序”是一个巨大的海市蜃楼。就像连接到资源（数据库等）时必须维护连接信息一样，连接到 LDAP 本身也需要连接信息。只有当他/她连接到多个资源并将所有资源配置放入同一个 LDAP 存储时，才能节省时间。如果使用 LDAP 来管理与单个资源的连接，那就是浪费时间 - 变成了另一个间接层。
@Faustas：如果许多不同的应用程序需要相同的信息 - 改变一切的中心点，LDAP 也很有意义。是的，在这种情况下，必须改为管理 LDAP 连接信息。这是一个权衡 - 没有免费的午餐 :-)。