JAVA NAMING DIRECTORY INTERFACE (JNDI)

1. Introduction:
Name is a tag to every person to identify himself in a given group of people. A
fundamental facility in any computing system is the naming service—the means by which
names are associated with objects, and by which objects can be identified. In almost any
computer program or system, name is a mandatory item. When you use an electronic mail
system, for example, you must provide the name of the recipient to whom you want to send
mail. When you want to access a file in the computer, you must supply its name.
Many naming services are extended with a directory serviced. While a naming service
allows you to look up an object given its name, a directory service also allows such objects to
have attributes. Therefore, in addition to lookup, you can also get an object’s attributes or
search for objects given their attributes.
You might be familiar with the telephone company’s directory service. A computer’s
directory service is very much like a telephone company’s directory service in that both can
be used to store information such as telephone numbers and addresses.
In addition, the computer’s directory service is much more powerful in that it is
available online and can be used to store a variety of information, for consumption by users,
programs, and even computer systems themselves.
2. Naming Concepts:
The primary function of a naming system is to map names to objects. It maps people
friendly names to addresses, identifiers, or objects typically used by computer programs. For
example, the Internet Domain Name System (DNS) maps machine names (such as
www.sun.com) to IP addresses (like 192.9.48.5). a file system maps a file name (c:\bin\
autoexec.bat ) to a file handle that a program can use to access the contents of the file. These
two examples also illustrate the wide spectrum of naming services that exist i.e., from an
entity on the Internet to a file on the local file system.
2.1 Names:
To look up an object form a naming system, you supply it the name of the object. The
naming system determines the syntax that the name must follow. This syntax is sometimes
called the naming system’s naming convention.
For example, the Unix file system’s naming convention is that a file is named from its
path relative to the root of the file system, with each component in the path separated left-to-

1
right using the slash character(‘/’). The Unix path name, /usr/hello, for example, names a file
hello in the file directory usr, which is located in the root of the file system.
In the DNS, the naming convention is that components in the DNS name are ordered
from right to left, and are delimited by dot characters (‘.’). thus, the DNS name
sales.Wiz.COM names a DNS entry with the name sales, relative to the DNS entry
Wiz.COM. the DNS entry Wiz.COM, in turn, names an entry with the name Wiz in the COM
entry.
In the Lightweight Directory Access Protocol (LDAP), the naming convention is that
components are ordered right to left, and are delimited by comma characters (‘,’). Thus, the
LDAP employee name cn = Arun, o = CSEL, c = IN names an LDPA entry cn = Arun,
relative to the entry o = CSEL, which in turn, is relative to c = IN. the LDAP has the further
rule that each component of the name must be a name / value pair with the name and value
separated by an equal character (‘=’).
2.2 Bindings :
The association of a name with an object is called a binding. For example, a file name
is bound to a file. The DNS contains bindings that map machine names to IP addresses. An
LDAP name is bound to an LDAP entry.
2.3 References and Addresses:
The reference of an object contains one or more addresses. Depending on the naming
service, some objects cannot be stored directly. A reference is one means by which such an
object can be bound and accessed.
A file object, for example, is accessed using a file reference, or file handle as it is
often called .a printer object, for example, might contain the state of the printer, such as its
current queue and amount of paper. A printer object reference, on the other hand, might
contain only information on how to reach the printer, such as its print server name and
printing protocol. As another example, an airplane object might contain a list of its
passengers and crew, its flight plan, and fuel and instrument status. By contrast, an airplane
object reference might contain only its flight number and departure time. In all of these
examples, the reference is a much more compact representation that can be sued to
communicate with the object, while the object itself might contain a lot more state. Using the
reference, you can contact he object and obtain more information about the object.
For simplicity, an object reference and the object it refers to are sometimes
interchangeable.
2.4 Context:

2
 A context is a set of name-to-object bindings. Every context has an associated naming
convention. A context provides a lookup (resolution) operation that returns the object, ad may
provide operations such as those for binding names, unbinding names, and listing bound
names. A name in one context object can be bound to another context object with the same
naming convention, called a sub-context.
For example, a file directory, such as /usr, in the UNIX file system is a context. A file
directory named relative to another file directory is a sub-context (some UNIX users refer to
this as a subdirectory). For example, given a file directory /usr/bin, the directory bin is a sub-
context of usr.
A DNS domain, such as COM, is a context. A DNS domain named relative to another
DNS domain is a sub-context. For example, given a DNS domain Sun.COM, the DNS
domain Sun is a sub-context of COM.
An LDAP directory, such as c= IN, is a context. An LDAP directory named relative
to another LDAP directory is a sub-context. For example, given an LDAP entry o = CSEL, c
= IN, the entry o = CSEL is a sub-context of c = IN.
2.5 Naming Systems and Namespaces:
A naming system is a connected set of contexts of the same type (having the same
naming convention) and providing a common set of operations. For example, the DNS is a
naming system. A system that communicates using the LDAP is a naming system.
A naming system provides a naming service to tits customers for performing naming-
related operations. A naming service is accessed through its interface. For example, the DNS
offers a naming service that maps machine names to IP addresses. The LDAP offers a naming
service that maps LDAP names to LDAP entries. The file system offers a naming service that
maps the names to files and directories.
A namespace is the set of names in a naming system. For example, the Unix file
system has a namespace consisting of all the names of files and directories in that file system.
The DNS namespace contains names of DNS domains and entries. The LDAP namespace
contains names of LDAP entries.

3
3. Directory Concepts:
A directory object represents an object in a computing environment. A directory
object can be used, for example, to represent a printer, a person, a computer, or a network. A
distinguishing trait of a directory object is that it contains attributes for describing the object
that it represents.
3.1 Attributes:
A directory object can have attributes associated with it. For example, a printer might
be represented by a directory object that has attributes like speed, resolution, and color. A
user might be represented by a directory object that has attributes like user’s email address,
various telephone numbers, postal mail address, and computer account information. An
attribute has an attribute identifier and a set of attribute values. The email address, for
example, might have an attribute identifier of “mail” and value of [email protected].
3.2 Directory and Directory Services :
A directory is a connected set of directory objects. A directory service provides
operations for creating, adding, removing, and modifying the attributes associated with
objects in a director. The service is accessed through its interface. There are many examples
of directory services. The NDS is a directory service from Novell, which provides
information about many networking services such as the file and print services. Network
information Service (NIS) is a directory service available on the Solaris operating system for
storing system related information such as that relating to machines, networks, printers, and
users. The NETSCAPE Directory is a general-purpose directory service based on the
emerging Internet standard Lightweight Directory Access Protocol (LDAP).
3.3 Searches and Search Filters:
You can look up a directory object by supplying its name to the directory service.
Alternatively, many directories, such as those based on the LDAP, support the notion of
searches where instead of a name; you can supply a query consisting of a logical expression
specifying the attributes that the object or objects must have. The query is called a search
filter and this style of searching is sometimes called traverse lookup or content-based
searching. The directory service searches for and returns the objects that satisfy the search
filter.
For example, you can ask the directory service to find all users with the attribute
“age” greater than 40 years. Similarly, you can ask the directory service to find all machines
whose IP address starts with “192.1.2.100”.

4
3.4 Combining Naming and Directory:
Directories often arrange their objects in a hierarchy. For example, the LDAP has the
notion of a directory information tree (DIT) by which all objects in the directory are arranged.
An organization object, for example, might contain group objects, which might in turn
contain person objects. When directory objects are arranged in this way, they are playing the
role of naming contexts in addition to being containers of attributes.
3.5 Directory-enabled Java applications:
Directory service is a vital component of network computing. Using a directory
service, you can simplify applications and their administration by centralizing the storage of
shared information. As use of the Java programming language for writing practical
applications in a network environment increases, the ability to access naming and directory
services becomes essential.
3.6 Traditional Use of the Directory:
A directory-enabled application is an application that uses the naming or directory
service. Directory-enabled Java applications and applets, like any other programs running on
the network, can make use of the directory in the traditional way: to store and retrieve
attributes of directory objects.
A Java mail client program, for example, can use the directory as an address book for
retrieving the address of mail recipients. A Java mail transfer agent program can use the
directory to retrieve mail routing information. A Java calendar program can use the directory
to retrieve user preference settings.
By making use of the directory, applications can share the common infrastructure
provided by the directory to make applications that are deployed across the system, and even
the network, more coherent and manageable. For example, printer configuration and mail
routing information could be stored in the directory, so that such information could be
replicated and distributed for use by all printer-related and mail-related applications and
services.

5
3.7 The Directory as an Object Store:
In addition, using the directory in the traditional way, Java applications can also use it
as a repository for Java objects. In other words, Java applications can use the directory to
store and retrieve Java objects.
For example, a Java print client pogrom should be able to look up a printer object
from the directory, and send a data stream to the printer object for printing.
4. Terms used in JNDI:
 Address: A specification of a communications endpoint.
 Alias: It is a object that contains the name of another object. This allows one object to be
named using different names.
 Atomic name: An indivisible component of a name, as defined by the naming convention
of the context in which the name is bound.
 Attribute: Information associate with a directory object. An attribute consists of an
attribute identifier and a set of attribute values.
 Binding: The association of an atomic name with an object.
 Composite name: A name that spans multiple naming systems composite name
resolution. The process of resolving a name that spans multiple naming systems.
 Composite namespace: The arranged of namespaces from autonomous naming systems
to form one logical namespace.
 Compound name: A name in the namespace of a single naming system. It is a sequence
of zero or more atomic names composed according to the naming convention of that
naming system.
 Context: An object whose state is a set of bindings with distinct atomic names.
 Context factory: A specialization of an object factory. A context factory accepts
information about how to create a context, such as a reference, and returns an instance of
the context.
 Directory: A connected set of directory objects.
 Directory object: An object that is in the directory. Sometimes referred to as a directory
entry.
 Directory service: Provides operations for creating, adding, removing, and modifying the
attributes associated with objects in a directory.
 Environment properties: Used to specify various preferences and properties that define
his environment in which naming and directory services are accessed.

6
 Federated namespace: Same as composite namespace.
 Federated naming service: Provides operations on a federated naming system.
 Federated naming system: An aggregation of autonomous naming systems that
cooperate to support name resolution of composite names through a standard interface.
Each member of the federation has autonomy in its choice of operations and naming
conventions.
 Initial context: The starting point for resolution of names for naming and directory
operations.
 Name: A people-friendly identifier for identifying an object or a reference to an object.
 Name resolution: The process of resolving a name to the object to which it is bound.
 Naming convention: The set of syntactic rules that govern how a name is generated.
These rules determine whether a name is valid or invalid in the context in which the name
is used.
 Naming service: Provides the operations on a naming system.
 Naming system: A connected set of contexts of the same type (having the same naming
conventions).
 Object factory: A producer of objects that accepts some information about how to create
an object such as a reference, and then returns an instance of that object.
 Operational attribute: An attribute maintained and used for administrative purposes and
is not visible to clients unless explicitly requested.
 Referral: It is an object that contains the name(s) and location(s) of other object(s). it is a
generalization of an alias.
 Reference: It contains one or more addresses for communication or referring to an object.
 Next naming system: The subordinate naming system in a federation of naming systems.
 Schema: It specifies the types of objects a directory may contain, and the mandatory and
optional attributes that directory objects of different types are to have. It may also specify
the structure of the namespace and the relationship between different types of objects.
 Search filter: A logical expression specifying the attributes that the directory objects
being requested should have and used by the directory to locate those objects.
 Service provider: An implementation of a context or initial context that can be plugged
in dynamically to the JNDI architecture to be used by the JNDI client.
 Sub context : It is a context that is bound in another context of the same type (having the
same naming convention).

7
5. JNDI Overview:
The Java Naming and Directory Interface TM (JNDI) is an API that provides naming
and directory functionality to applications written in the Java programming language. The
JNDI is defined to be independent of any specific directory service implementation. Thus, a
variety of directories-new, emerging, and already deployed ones-can be accessed in a
common way.
6. Architecture :
The JNDI architecture consists of an API (Application Programming Interface) and an
SPI (Service Provider Interface). Java applications use the JNDI API to access variety of
naming and directory services. The JNDI SPI enables a variety of naming and directory
services to be plugged in transparently, allowing the Java application using the JNDI API to
access their services.

Java Application

JNDI API
Naming Manager
JNDI SPI

LADP DNS NIS NDS RMI CORBA

JNDI Implementation Possibilities

8
6.1 Packaging :
The JNDI is a Java Standard Extension. It extends the platform to provide naming and
directory functionality. In order to use the JNDI, you must first download the JNDI classes
and one or more service providers.
The JNDI is divided into three packages.
 javax.naming
 javax.naming.directory
 javax.naming.spi
7. Naming Package :
This package contains classes and interfaces for accessing naming services.
7.1 Context :
This package defines the notion of a Context, which is the core interface for looking
up, binding/unbinding, renaming objects, and creating and destroying sub contexts.
lookup() is the most commonly used operation. You supply lookup() the name of the
object you want to look up, and it returns the object bound to that name. For example, the
following code fragment looks up a printer and sends a document to the printer object to be
printed.
Printer printer = (Printer)ctx.lookup(“treekiller”);
printer. print (report);
7.2 Names :
Every naming method in the Context interface has two overloads: one that accepts a
Name argument and one that accepts a string name. Name is an interface that represents a
generic name-an ordered sequence of zero of more components. For these methods, Name
represents a composite name so that you can name an object using a name, which spans
multiple namespaces. Composite names and multiple namespaces are covered in the Beyond
the Basics trail.
The overloads that accept Name are useful for applications that need to manipulate
names: composing them, comparing components, and so on. The overloads that accept string
names are likely to be more useful for simple applications, such as those that simply read in a
name and look up the corresponding object.

9
7.3 Bindings :
listBindings() reruns an enumeration of name-to-object bindings. Each binding is
represented by an instance of the Binding class. A binding is a tuple containing the name of
the bound object, the name of the object’s class, and the object itself.
lsit() is similar to listBindings(), except that it returns an enumeration of
NameClassPair. NameClassPair contains an object’s name and the name of the object’s class.
The list method is useful for applications such as browsers that wish to discover information
about the objects bound within a context, but don’t need all of the actual objects. Although
listBindings() provides all of the same information, it is potentially a much more expensive
operation.
7.4 References:
Objects are stored in naming and directory services in different ways. If an object
store supports strong Java objects, it might support storing an object in tis serialized form.
However, some naming and directory services do not support the storing of Java objects.
Furthermore, for some objects in the directory, Java programs are but one group of
applications that access them. In this case, a serialized Java object might not be the most
appropriate representation. Finally, a reference might be a very compact representation of an
object while its serialized form might contain a lot more state.
The JNDI defines the Reference class to represent a reference. A reference contains
information on how to construct a copy of the object. The JNDI will attempt to turn
references looked up from the directory into the Java objects they represent, so that JNDI
clients have the illusion that what is stored in the directory are Java objects.
The Initial context :
In the JNDI, all naming and directory operations are performed relative to a context.
There are no absolute roots. Therefore the JNDI defines an initial context, which provides a
starting point for naming and directory operations. Once you have an initial context, you can
use it to look up other contexts and objects.
7.5 Exceptions:
The JNDI defines a class hierarchy for exceptions that can be thrown in the course of
performing naming and directory operations. The root of this clas hierarchy a
NamingException. Programmers interested in dealing with a particular exception can catch
the corresponding subclass of the exception. Otherwise, they should catch NamingException.

10
8. Directory Package :
This package extends the javax.naming package to provide functionality for accessing
directory services in addition to naming services. This package allows applications to retrieve
attributes associated with objects stored in the directory and to search for objects using
specified attributes.
8.1 The Directory Context :
The DirContext interface represents a directory context. It defines methods for
examining and updating attributes associated with a directory object.
You use getAttributes() to retrieve the attributes associated with a directory object (for
which you supply the name). Attributes are modified using modifyAttrubute(). You can add,
replace, or remove attributes and / or attribute values using this operation.
DirContext also behaves as a naming context by extending the Context interface. This
means that any directory object can also provide a naming context. For example, a directory
object for a person might contain attributes about that person and at the same time provide a
context for naming objects such as his printers and file system relative to that person
directory object.
8.2 Searches :
DirContext contains methods for performing content-based searching of the directory.
In the simplest and most common form of usage, the application specifies a set of attributes-
possibly with specific values-to match, and submits this attribute set, to the search() method.
There are other overloaded forms of search() that support more sophisticated search filters.
9. Service Provider Package :
This package provides the means by which developers of different naming/directory
service providers can develop and hook up their implementations so that the corresponding
services are accessible from applications that use the JNDI.
9.1 Plug- in Architecture :
The service provider package allows different implementations to be plugged in
dynamically. These different implementations include those for the initial context, and
implementations for contexts that can be reached from the initial context.

11
9.2 Java Object Support :
The service provider package provides support for implementers of the
Context.lookup() method and related methods to return Java objects that are natural and
intuitive for the Java programmer. For example, when looking up a printer name form the
directory, it is natural for you to expect to get back a printer object on which to operate.
9.3 Multiple Naming Systems (Federation) :
JNDI operations allow applications to supply names that span multiple naming
systems. So in the process of completing an operation, one service provider might need to
interact with another service provider, for example, to pass on the operation to be continued
in the next naming system. The service provider package provides support for different
providers to cooperate and complete JNDI operations.

10. Keep the objects around

You may recall from March's column that there are three techniques for storing Java objects
in a JNDI service: as serialized data, as a reference to an object, and as the attributes on a
directory context. Storing an object as serialized data is the simplest of the three techniques.
Storing an object as a reference is useful in situations in which it doesn't make sense (or isn't
possible) to store actual objects. Finally, storing objects as

attributes on a directory context is useful when other, non-Java applications need access to
the object's information. The application I've developed uses the first two methods of object
storage.

10.1 The Functional Units : Figure 1, below, illustrates Doc-u-Matic from a functional
perspective. Doc-u-Matic consists of three major functional units: the JNDI service (of
course), a library service, and one or more clients.

12
 Figure 1. Doc-u-Matic: A functional view

A library is a place to which you publish objects and from which you retrieve

them. An object can be any Java instance, as long as it supports one of the storage methods
mentioned above -- it can be a String, a JavaBean, and so on. JNDI plays two roles in Doc-u-
Matic. It provides a single, well-known location where clients can locate the library service
(standard address-book functionality), and it supports the implementation of the library
service itself. On the latter point, it's worth noting that

nothing in the design of a library implies that it has to be implemented on top of JNDI --
that's just the direction I took (since this is an article on JNDI). You could implement a
library on top of any technology that provides support for publishing and retrieving
information, including HTTP, JDBC, NNTP, or IMAP. Best of all, the

clients would never know the difference.

11. JNDI Everywhere

JNDI plays a role in a number of Java technologies. Let's consider three of them: JDBC (the
Java Database Connectivity package), JMS (the Java Messaging Service), and EJB
(Enterprise JavaBeans).JDBC is the Java technology for relational databases. JNDI first
appeared in the JDBC 2.0 Optional Package (see Resources) in conjunction with the
DataSource interface. A DataSource instance, as its name implies, represents a source of data
-- often from a database but not always. A DataSource instance stores information about a
data source -- such as its name, the driver to load and use, and its location -- and allows an

13
application to obtain a connection to the data source without regard to the underlying details.
The JDBC specification recommends using JNDI to store DataSource objects.

JMS is the Java technology for messaging. The JMS specification describes administered
objects -- objects that contain JMS configuration information and are used by JMS clients to
locate specific message queues and topics. As is the case with JDBC, the specification
recommends locating JMS administered objects via JNDI.

Finally, consider Enterprise JavaBeans. All enterprise beans publish a home interface -- the
single location through which clients locate a specific enterprise bean -- via JNDI.

What does JNDI bring to the table that causes it to be so highly regarded?

First, JNDI promotes the notion of a centrally managed information source -- a key
requirement for enterprise applications. A centrally managed information source is easier to
administer than a distributed collection of information sources. It's also simpler for clients to
locate needed information if they only have to look in one place.

Second, as you shall see, JNDI's ability to directly store Java objects allows it to integrate
almost transparently into Java applications.

14
Naming Example:
Server Code :

package examples.jndi.news;
import java.rmi.*;
import javax.naming.*;
import java.util.*;
import weblogic.jndi.*;
public class OneServer()
{
public static void main(String []args)
{
try{
Context ctx = null;
Hashtable ht = new Hashtable();
ht.put(cpntext.INITIAL_OCNTEXT_FACTORY,”weblogic.jndi.
TengahInitialContextFactory();
ht.put(Context.PROVIDER_URL, “t3://localhost:7001”);
try{
ctx = new InitialContext(ht);
String s = “Hello jndi this is so simple – NetGSC”;
ctx.rebind(“News”,s);
}
catch(NamingException e)
{
e.printStackTrace();
}
finally
{
try{
ctx.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}catch(Exception e)
{
e.printStackTrace();
}
}
}

15
Client Code :
package examples.jndi.news;
import java.rmi.*;
import javax.naming.*;
import java.util.*;
public class Client
{
public static void main(String[] args)
{
try
{
Context ctx = null;
Hashtable ht = new Hashtable();
Ht.put(Context.INITIAL_CONTEXT_FACTORY,”weblogic.
jndi.TengahInitialContextFactory”);
ht.put(Context.PROVIDER_URL,”t3://localhost:7001”);
try
{
ctx = new InitialContext(ht);
String hi=(String)ctx.lookup(“News”);
System.out.println(“This is from client”+hi);
}
catch(NamingException e)
{
e.printStackTrace();
}
finally
{
try
{
ctx.close();
}
catch(Exception e)
{
e.printStackTrace();
}
}
}
catch(Exception e)
{
e.printStackTrace();
}
}
}

16
17