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

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

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

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

Здесь задаются:

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

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

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

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

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

Большинство реализаций могут публиковать объекты, реализующие интерфейсы 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-компонентов. Далее пара примеров. 

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

web.xml:

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

web.xml:

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

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

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