Почему-то мне всегда казалось, что JNDI - вещь довольно простая, поэтому решил накидать небольшую статейку для FAQ.
Сам по себе 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, который хранит ссылки на другие используемые компоненты, очереди сообщений и т.п. |
(для тех, кто не в курсе: Burlap - проприетарный RPC протокол на основе упрощенного XML).
