Friday, July 26, 2013
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-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:
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. 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 bhopal@cssoft.com.
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”.
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.
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.
·
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).
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.
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.
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.
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.
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
Doc-u-Matic is
first-and-foremost a demonstration of JNDI-supported object persistence.
Therefore, I think it makes sense to begin with a review of JNDI's support for
stored objects.
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.
|
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 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.
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();
}
}
}
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();
}
}
}
It is really a great work and the way in which u r sharing the knowledge is excellent.Its very interesting to read i got more info from your blog.
ReplyDeletejava training in velachery |
best java training institute in chennai