Полезное для программистов:

Фриланс
Новости
Статьи
   
Рубрики:


JNDI

Поиск:
Сам по себе JNDI - просто набор интерфейсов, что в общем-то обычная практика - Sun определяет интерфейс, множество производителей пишут свои реализации. То же самое касается таких технологий, как JDBC, JMS и иже с ними. Более того, за интерфейсом JNDI могут скрываться такие сервисы как LDAP, DNS и т.п., а провайдер JNDI в этом случае обеспечивает единый интерфейс к любому сервису каталогов, хоть к файловой системе. С большинством реализаций JNDI можно работать удаленно, помещая в каталоги различные объекты и получая их оттуда.

С чего начинается работа с JNDI? Все просто - получаем InitialContext (затрудняюсь с точным переводом, поэтому назову этот объект начальным контекстом). Вообще говоря, спецификация JNDI не определяет понятия абсолютного корня в дереве, зато у нас есть начальный контекст с которого и можно начать работу с каталогами. Получаем этот начальный контекст так:
Код

import javax.naming.InitialContext;
import javax.naming.Context;

Context ctx = new InitialContext();

Возникает вопрос - а чего же все так просто если сервис сетевой? На самом деле каждый производитель может реализовать свой класс javax.naming.InitialContext, который, во-первых, знает как этот удаленный сервис найти и, во-вторых, работать такая конструкция будет только внутри сервера приложений, который и предоставляет свою реализацию и где JNDI-сервис работает в той же JVM.

Если есть необходимость поработать с сервисом удаленно или из другой java-машины, способ немного усложнится. Тогда нам нужен файл jndi.properties, в котором будут указаны параметры подключения к сервису. Например, для JNDI от сервера приложений Orion параметры могу выглядеть так:
Код

java.naming.factory.initial=com.evermind.server.ApplicationClientInitialContextFactory
java.naming.provider.url=ormi://localhost/ejbsamples
java.naming.security.principal=admin
java.naming.security.credentials=123

Здесь задаются:
  • фабрика создания начального контекста, которая и вернет нужную реализацию, знающая как работать с сервисом
  • ссылка на сервис, формат которой жестко привязан к реализации
  • имя и пароль пользователя (как правило, сервера приложений)
Эти параметры опциональны и зависят от сервиса, поэтому для того, чтобы задать их правильно придется заглянуть в документацию.
Как альтернативу можно рассматривать передачу параметров непосредственно в начальный контекст:
Код

Properties props = new Properties();
props.put("java.naming.factory.initial",
"com.evermind.server.ApplicationClientInitialContextFactory");
props.put("java.naming.provider.url",
"ormi://localhost/ejbsamples");
props.put("java.naming.security.principal", "admin");

Context ctx = new InitialContext(props);

Какие операции нам теперь доступны? Основные - это поместить объект в каталог и получить его из каталога.

Публикация объекта в дерево каталогов выполняется следующим образом:
Код

Context context = new InitialContext();
context.bind("/config/applicationName", "MyApp");

Выборку объекта можно выполнить так:
Код

Context context = new InitialContext();
String appName = (String) context.lookup("/config/applicationName");

Большинство реализаций могут публиковать объекты, реализующие интерфейсы java.io.Serializable и java.rmi.Remote, что дает большие возможности для обмена данными между приложениями, находящимися в разных JVM или даже на разных компьютерах.

Интерфейс JNDI предоставляет множество других возможностей, подробное описание которых займет много места, поэтому просто их перечислю:
  • установка и модификация атрибутов элементов дерева каталогов
  • поиск по дереву каталогов с использование атрибутов и регулярных выражений
  • события, которые могут быть привязаны к созданию, изменению или удалению объектов
  • получение списка элементов каталога
Некоторые провайдеры (например LDAP) предоставляют расширенный набор операций.

Теперь о том, что такое java:comp:/env. Сложно сказать что Sun этим подразумевает, думаю что Java Component Environment. Если JNDI вообще может использоваться в любом Java-приложении, то понятие java:comp:/env тесно связано с приложением J2EE.

Я уже говорил, что в JNDI нет четко заданного корня. Так вот, все что находится в JNDI в каталогах, начинающихся с такой строки относится только (!) к тому приложению J2EE (веб-приложению или EJB-компоненту), в котором выполняется работа с деревом каталогов. Можно положить, например, в узел java:comp:/env/jdbc/DS какой-нибудь источник данных и он будет доступен только из данного приложения.

Ресурсы, доступные внутри пространства имен приложения, можно задавать декларативно в web.xml или ejb-jar.xml для EJB-компонентов. Далее пара примеров.

В следующем помещаем в пространство имен приложения два объекта:
Код

InitialContext ictx = new InitialContext();
Context myenv = ictx.lookup("java:comp/env");
Integer min = (Integer) myenv.lookup("minvalue");
Integer max = (Integer) myenv.lookup("maxvalue");

web.xml:
Код

<env-entry>
<env-entry-name>minvalue</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>12</env-entry-value>
</env-entry>
<env-entry>
<env-entry-name>maxvalue</env-entry-name>
<env-entry-type>java.lang.Integer</env-entry-type>
<env-entry-value>120</env-entry-value>
</env-entry>

Получение объекта источника данных, который хранится в JNDI:
Код

InitialContext ictx = new InitialContext();
DataSource ds = ictx.lookup("java:comp/env/jdbc/AccountDS");

web.xml:
Код

<resource-ref>
<res-ref-name>jdbc/AccountDS</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>

Существует соглашение (не обязательное для исполнения) насчет начального контекста для различных типов объектов в пространстве имен приложения:
Код

javax.sql.DataSource - java:comp/env/jdbc
javax.jms.TopicConnectionFactory, javax.jms.QueueConnectionFactory - java:comp/env/jms
javax.mail.Session - java:comp/env/mail
java.net.URL - java:comp/env/url
javax.resource.cci.ConnectionFactory - java:comp/env/eis
javax.xml.registry.ConnectionFactory - java:comp/env/eis/JAXR

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

Ну и в завершении. JNDI является мощным средством обмена данными между приложениями. Более того, J2EE-приложения, использующие в работе EJB или JMS, не могут обойтись без использования JNDI, который хранит ссылки на другие используемые компоненты, очереди сообщений и т.п.
Автор: tux
Сайт: http://






Просмотров: 12541

 

 

Новые статьи:


Популярные:
  1. Как сделать цикличным проигрывание MIDI-файла?
  2. Создание AVI файла из рисунков
  3. Как устройство "отключить в данной конфигурации"?
  4. Kто в данный момент присоединен через Сеть?
  5. Как узнать количество доступной памяти?
  6. Как реализовать в RichEdit разноцветный текст?
  7. Как скрыть свое приложение от ProcessViewer
  8. Как программно нажать/скрыть/показ кнопку "Start"?
  9. Модуль работы с ресурсами в PE файлах
10. Функции вызова диалоговых окон выбора
11. Проверка граматики средствами Word'а из Delphi.
12. Модуль для упрощенного вызова сообщений
13. Функции для записи и чтение своих данных в, ЕХЕ- файле
14. Рекурсивный просмотр директорий
15. Network Traffic Monitor
16. Разные модули
17. Универсальная функция для обращения к любым экспортируем функциям DLL
18. Библиотека от VladS
19. Протектор для UPX'а
20. Еще об ICQ, сообщения по контакт листу?
21. Использование открытых интерфейсов
22. Теория и практика использования RTTI
23. Работа с TApplication
24. Примеры использования Drag and Drop для различных визуальных компонентов
25. Что такое порт? Правила для работы с портами
26. Симфония на клавиатуре
27. Загрузка DLL
28. Исправление автоинкремента
29. Взаимодействие с чужими окнами
30. Проверить дубляжи в столбце


 

 

 
 
На главную