为什么将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(或者你的env的任何地方).然后在您的App配置中使用MYRESOURCE作为主机名(例如,在jdbc url中).

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

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

Answer 4

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

Answer 5

JNDI 的另一个帮助领域：

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

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

换句话说，JNDI 主要适用于复杂的部署场景，例如：

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

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