The Java Naming and Directory Interface (JNDI) is designed by Sun Microsystems Ltd. to simplify access to the directory infrastructure, which advanced network applications are being built on, by providing an unified set of interfaces. The directory infrastructure includes directories, which are special types of databases that provide quick access to their data stores

1. JNDI:
Java Naming & Directory
Services
D. C. Sherman 1

2. Rationale
A fundamental element in every application is the capability to find and
locate components and services.
A client looking for a component service usually knows its name, but not its
physical location.
The component name corresponds to the actual name, typically much
more difficult to remember and manage.
A well-known naming service is provided in the Internet by DNS
For applications, a naming directory service is the way to refer to a required
service (e.g. a JDBC data source, a JMS connection factory, an EJB
home interface, etc.)

3. Terms
A naming service is an application tht contains a set of objects, or
references to objects, with corresponding names (usually easy to
remember). Such correspondences a recalled bindings.
A directory service allows for the association of attributes to a binding.
Some popular directory implementations:
LDAP (Lightweight Directory Access Protocol)
NDS (Network Directory Service)
AD (Active Directory)
NIS+ (Network Information Service Plus)

4. Overview
JNDI (Java naming Directory Interface) provides Java clients with the
capacity to access naming and directory services.
JNDI is subdivided in the following packages:
javax.naming
javax.naming.directory
javax.naming.event
javax.naming.ldap
javax.naming.spi

5. Configuration
 JNDI configuration can be quite a difficult task
 Whenever we use an EJB server, JNDB is started automatically at he
same time as the server itself. Such a server is usually already
configured for the specific server.
 Also the client applications using JNDI must be configured, which task is
up to the programmer.

6. Properties
A client (object) uses JNDI to locate remote services, but JNDI might be a
remote service as well. How, then, to locate a naming service without
using a naming service?
This can be done using environment properties.
Some standard JNDI properties:
 java.naming.factory.initial
 java.naming.provider.url
 java.naming.security.authorization
etc.

7. Context
Context (interface) is used to deal with objects that have been bound to a
JNDI name.
javax.naming.Context contains methods to put objects in the naming
service, and retrieve them.
All the naming services have an access point, referenced as *InitalContext*
in the JNDI (not thread-safe!):
Select th eservice providerspecify requried configuration
call the *InitialContext* constructor, with teh environment properties

8. InitialContext
InitialContext must be closed after its usage, as it happens for any
resource, e.g. a JDBC connection. The best way to do it is to insert the
invocation of the close method inside a finally block.
The method getEnvironment of Context returns an Hashtable with all the
active properties for the context.
The method lookup(name) returns a reference to the Object corresponding
to name. This way, also EJB "home factories" are looked up.

9. Access
As an EJB usually must not access files, how can an EJB access its
configuration properties?
A smart way to pass a configuration value to a bean is through its
deployment descriptor, adding an env-entry tag, e.g.
 <env-entry>
 <description>what a beautiful entry!</description>
 <env-entry-name>theNicestGirl</env-entry-name>
 <env-entry-type>java.lang.String</env-entry-type>
 <env-entry-value>”Anne”</env-entry-value>
 </env-entry>
An EJB accesses environment properties using an InitialContext object, and
looking up the desired property by its name.