Какова цель JNDI

91

Как можно реализовать использование JNDI, если возможно, на примере?

java jndi Аджай
источник
3
Вы можете проверить примеры использования в личном блоге: tshikatshikaaa.blogspot.com/2013/01/…
Jérôme Verstrynge
@JVerstry +1 за ссылку на статью, в которой рассказывается о связанных LDAP, JCA и CCI.
Ajay
Проверьте эту тему SO
Аникет Такур,

Ответы:

110

JNDI - это интерфейс именования и каталогов Java. Он используется , чтобы отделить проблемы приложения разработчика и приложения Deployer . Когда вы пишете приложение, использующее базу данных, вам не нужно беспокоиться об имени пользователя или пароле для подключения к этой базе данных. JNDI позволяет разработчику дать имя базе данных и рассчитывать на то, что разработчик сопоставит это имя с фактическим экземпляром базы данных.

Например, если вы пишете код, работающий в контейнере Java EE, вы можете написать это, чтобы получить источник данных с именем JNDI «База данных»:


DataSource dataSource = null;
try
{
    Context context = new InitialContext();
    dataSource = (DataSource) context.lookup("Database");
}
catch (NamingException e)
{
    // Couldn't find the data source: give up
}

Обратите внимание, что здесь нет ничего о драйвере базы данных, имени пользователя или пароле. Это настраивается внутри контейнера.

JNDI не ограничивается базами данных (JDBC); всевозможным услугам можно давать имена. Для получения дополнительных сведений обратитесь к руководству Oracle .

Саймон Никерсон
источник
10
Итак, в этом примере на картинке, чем JNDI отличается от размещения имен баз данных в конфигурационном XML-файле или файле свойств и последующего чтения их оттуда?
Ajay
11
Во-первых, вам нужно будет сохранить пароль в виде обычного текста в вашем файле конфигурации. Во-вторых, если у вас есть несколько приложений, указывающих на одну и ту же базу данных, и что-то в конфигурации базы данных меняется, вам необходимо обновить конфигурацию в нескольких местах.
Саймон Никерсон
1
ну как тут помогает JNDI?
Ajay
1
он должен содержать все, что вам нужно знать о JNDI, будь то в контексте J2EE или в контексте JavaSE. javaworld.com/javaworld/jw-04-2002/jw-0419-jndi.html
Нико,
5
@SimonNickerson Привет !. Я изучаю JNDI. Это хороший ответ, но если вы заметили вопрос «Как можно реализовать использование JNDI?» тогда это выглядит незаконченным. Вы описали реализацию с точки зрения разработчика. Как насчет точки зрения разработчика?
lxknvlk
31

JNDI - это очень мощный механизм как для организации информации о конфигурации, так и для обнаружения и прослушивания сервисов с помощью EventContext. В JNDI вы можете искать и прослушивать любой объект (не только объекты DataSource), если ваш поставщик услуг JNDI поддерживает его.

Конечно, единственная проблема заключается в наличии поставщика услуг JNDI; Самое замечательное в этом то, что на удивление легко свернуть свою собственную. В конце концов вы можете кодировать любой экземпляр Java в XMLиспользовании JavaBeans XMLEncoderи XMLDecoderвы не должны полагаться на работы в сервере приложений!

Так в чем разница между наличием файлов конфигурации? Что ж, это может быть намного чище, потому что все ваши приложения могут получать свою конфигурацию из одного места . Если им необходимо совместно использовать информацию о конфигурации (например, расположение базы данных), это можно определить один раз в JNDI . Предположим, вы переместили серверы баз данных: вам не нужно запоминать файлы конфигурации gazillion с указанием их местоположения. Вы просто идете в одно место: JNDI.

Oxbow_lakes
источник
Это, безусловно, наиболее полное разъяснение - Спасибо, oxbow_lakes! Кстати, были бы у вас указатели кода, где любой экземпляр Java был закодирован, как вы предлагаете?
Рохан Кумар
13

JNDI - это API, используемый для доступа к службам каталогов и имен (т. Е. Средств, с помощью которых имена связываются с объектами). Связь имени с объектом называется привязкой.

Базовым примером службы имен является DNS, которая сопоставляет имена машин с IP-адресами.

Используя JNDI, приложения могут сохранять и извлекать именованные объекты Java любого типа.

В контексте java это можно использовать в файлах конфигурации, где вы не хотите жестко кодировать переменные среды.

Пример весны:

Файл контекста Spring

<bean id="WSClientConfig" class="com.example.BaseClientConfigImpl">
<property name="protocol">
    <jee:jndi-lookup jndi-name="java:comp/env/protocol" />
</property>
<property name="endpoint">
    <jee:jndi-lookup jndi-name="java:comp/env/endpoint" />
</property>
<property name="requestPath">
<jee:jndi-lookup jndi-name="java:comp/env/requestPath" />    
</property>

Файл контекста Tomcat

<Environment name="protocol" type="java.lang.String" value="https://"/>
<Environment name="endpoint" type="java.lang.String" value="172.0.0.1"/>
<Environment name="requestPath" type="java.lang.String" value="/path/to/service"/>
Ithar
источник
3

JNDI позволяет упростить конструкцию ресурса до простого имени . Итак, многие детали сгруппированы в 1 для удобства / безопасности / и т. Д. (также известный как слой абстракции)

для реализации: настройте список свойств, который соответствует предопределенным полям в Jndi Context Interface. (эти свойства определяют настройки для выполнения jndi; но * не имя поиска)

Properties props = new Properties();
//field Context.INITIAL_CONTEXT_FACTORY => property name java.naming.factory.initial
    //field Context.PROVIDER_URL => property name java.naming.provider.url
props.load(new FileInputStream("*properties file*")); //prop file in this case

Context ctx = new InitialContext(props);
    Object o = ctx.lookup("*name of resource*");

в идеале должна существовать специализированная функция для поддержки каталога LDAP, DNS и т. д. в вашей организации (так что единый единый набор сопоставлений обслуживает все, уменьшая расхождения)

Список поставщиков услуг JNDI: https://www.ibm.com/support/knowledgecenter/en/SSVSD8_8.4.1/com.ibm.websphere.dtx.adapjndi.doc/concepts/c_jndi_JNDI_Service_Providers_.htm

Ilupper
источник