Зачем использовать JNDI для источников данных

Question

Может кто-нибудь помочь объяснить, почему JNDI должен быть предпочтительным способом предоставления таких услуг, как база данных / jms?

В постах, на которые я наталкиваюсь, рассказывается о том, что нет необходимости загружать конкретный диспетчер драйверов, выигрывать от пула соединений и т. Д., Но этого легко достичь, указав диспетчер драйверов в файле свойств и используя отражение.

Пул соединений также может быть достигнут путем подключения правильной реализации к компоненту приложения с помощью пружины или иным образом.

Так почему же лучше использовать JNDI?

Answer 1

JNDI действительно сияет, когда вам нужно переместить приложение между средами: от разработки к интеграции, чтобы протестировать до производства. Если вы сконфигурируете каждый сервер приложений для использования одного и того же имени JNDI, у вас могут быть разные базы данных в каждой среде, и вам не придется менять свой код. Вы просто берете файл WAR и помещаете его в новую среду.

Вот некоторые другие предположения, которые важно знать при оценке этого ответа:

• У меня вообще нет доступа к серверам, на которых развернут код, кроме доступа к журналам только для чтения.
• Тот, кто пишет и упаковывает код, не тот, кто настраивает и управляет сервером.
• Как только WAR-файл начинается в его пути к PROD, он не может быть изменен снова без возврата к началу. Любое тестирование, выполненное QA на тестовом сервере, должно быть повторно выполнено, если WAR изменен.

Возможно, вы не видите этого преимущества, потому что вы одинокий разработчик, который пишет код на локальном рабочем столе и развертывает право на производство.

Answer 2

Я думаю, что «предпочтительным» механизмом является тот, который предпочитает человек, выполняющий администрирование и настройку. Как отметил Даффимо, крайне важно, чтобы конфигурация была внешней по отношению к вашему развертываемому артефакту, но в противном случае я бы сказал, что все идет хорошо. Если ваш системный администратор предпочитает использовать графический интерфейс для настройки записей JDNI, круто. Если он / она предпочитает редактировать файлы свойств с помощью cssh и vi, тоже здорово. Если вы несете ответственность как за разработку, так и за настройку / развертывание своего приложения, тогда это ваш вызов. Лично мне нравится хранить как можно больше реализаций внутри моего артефакта, а это означает, что мой источник данных и драйверы тоже там живут.

Если вы спрашиваете о технических преимуществах JNDI над альтернативами, я не уверен, что они есть, но вы, возможно, захотите уточнить свой вопрос.

Answer 3

Как уже упоминалось, JNDI по большей части используется для поиска местоположения службы, но в основном для ресурсов, подобных БД.

Больше всего раздражает то, что LDAP-интерфейс Java также является JNDI-API.При работе с LDAP абстракции очень и очень запутаны.Недостатком JNDI также является то, что он иногда является единственной точкой отказа.

Большую часть того, что делает JNDI, можно легко выполнить, используя псевдонимы имени хоста.То есть создайте псевдоним, который указывает MYRESOURCE на 127.0.0.1 в вашем /etc/hosts (или там, где он есть для вашей env).Затем в конфигурации приложения используйте MYRESOURCE в качестве имени хоста (например, в URL-адресе jdbc).

Затем, когда вы переводите свое приложение в производство, просто измените файл /etc/hosts производства, указав MYRESOURCE на производственный ресурс /сервис (как сервер базы данных prod).

Вышеприведенный способ представляет собой более переносимый каталог имен меньшего размера, который будет работать на других языках (ruby, python).Он также будет работать с вещами, которые обычно не выполняются с JNDI, такими как службы REST.Единственное, что раздражает, это то, что вам придется обновлять файлы хостов ваших серверов, но это можно автоматизировать с помощью сценариев SSH.

Answer 4

Реальное преимущество JNDI перед файлами свойств достигается при развертывании в кластерной среде.Использование файлов свойств оставляет возможность для некоторых экземпляров сервера иметь другое значение.При использовании JNDI контроллер домена выдает одно и то же значение на все кластерные серверы, что устраняет необходимость копировать один и тот же файл свойств на все серверы (и, возможно, перезагружать сервер / приложение).

Answer 5

Другая область, в которой помогает JNDI:

Это абстракт поиск ресурсов. Обычно конфигурация JNDI хранится в файле XML на сервере приложений, но это не обязательно. Например, конфигурация может храниться на сервере LDAP, чтобы упростить централизованное обслуживание.

Если приложения, которые вы запускаете, используют JNDI для поиска того, что им нужно, вы можете переключиться с файлов конфигурации на использование сервера LDAP без изменения приложений . Если каждое приложение ожидает файл свойств с жестко заданным именем, вам не повезло. Представьте себе предприятие с десятками приложений, находящихся в производстве - изменение их всех было бы серьезной проблемой.

Другими словами, JNDI в основном подходит для сложных сценариев развертывания, например:

• много серверов приложений (возможно, кластеризованных)
• много разных приложений
• централизованная конфигурация
• различные серверные стадии (тестирование, производство)

Так что на первый взгляд это может показаться излишним, но очень полезно в этих сценариях. Конечно, некоторые преимущества применимы даже для небольших развертываний, например стандартизированная конфигурация соединений с БД.