DeveloperNet University Home > Online Courses > LDAP extensions for JNDI

eBook (Printable PDF format)

Overview of JNDI

If distributed application's components are unable to locate one another, then they can't work together. As a result, distributed applications require something to help the components to find each other. The Java Naming and Directory Interface (JNDI) provides this capability.

Naming Service

In this day and age, how many of you still get the urge to go to the library to read a book? With all the on-line items available, a lot of reading can be done from the comfort of your home via an Internet connection. If you do go to the library, finding a particular book can be easier if you use the card catalog to find out exactly where the book is. A card catalog is very similar to the idea of a naming service in computing jargon. A naming service associates names with the locations of services and with information. A naming service provides computer programs with a single location where they can find the resources they need. When a program utilizes a naming service it doesn't waste time by performing the electronic equivalent of walking up and down the aisles, and also doesn't require that the locations be hard-coded into their logic either.

Finding resources is of a particular importance in large-scale enterprise environments, where applications you build may depend on services provided by applications, written by other groups in other departments. A well thought-out naming infrastructure makes such projects possible. On the converse, the lack of one makes them impossible.

JNDI provides a common-denominator interface to many existing naming services. As such, JNDI was not designed to replace existing technology, rather, it provides a common interface to existing naming services.

Introduction to Naming Services

Figure 2, shows the organization of a generic naming service.

Figure 2: A Naming Service.

A naming service maintains a set of bindings. Bindings relate to the names of objects. All objects in a naming system are named in the same way, which is referred to as subscribing to the same naming convention. Clients use the naming service to locate objects by name.

There are several naming services available, a few of which will be described below. They each follow the pattern depicted in Figure 2, but differ in details.

COS (Common Object Services) Naming: The naming service for CORBA applications; allows applications to store and access references to CORBA objects.

DNS (Domain Name System): The Internet's naming services, maps people-friendly names (such as http://www.novell.com) into computer-friendly IP (Internet Protocol) addresses in dotted-quad notation (207.69.107.37). The DNS naming service is distributed, meaning that the service and its underlying database is spread across many hosts on the Internet.

LDAP: Developed by the University of Michigan, it is a lightweight version of the Directory Access Protocol (DAP), which in turn is a part of X.500, which is a standard for network directory services.

NIS (Network Information System) and NIS+: Network naming services developed by Sun Microsystems. Both flavors allow users to access files and applications on any host with a single ID and password.

Common Naming Features

Remember that the primary function of a naming system is to bind names to objects, or in some cases, to references to objects. In order to be a naming service, a service must at the very least provide the ability to bind names to objects and to look up objects by name.

Several naming systems do not store objects directly. Instead, they store references to objects. As an example, consider DNS. The address 207.69.107.37 is a reference to a computer's location on the Internet, not the actual computer.

JNDI provides an interface that supports all this common functionality.

Differences Among Naming Features

It is also important to understand how existing naming services differ, since JNDI must provide a workable abstraction that gets around these differences.

The biggest difference between naming services, well the most noticeable, is the different way each naming service requires names to be specified (referring to its naming convention). The following are a few examples of this concept:

1. In DNS, names are built from components that are separated by dots ("."). They read from right to left. The name http://www.novell.com names a machine called "www" in the "novell.com" domain. Likewise, the name "novell.com" names the domain "novell" in the top-level domain "com."
   
   
2. As we have discussed earlier, in LDAP, the situation is more complicated. Names are built from components that are separated by commas (","). Like DNS names, they read from right to left, however, components in an LDAP name must be specified as name/value pairs. The name "cn=Aaron Osmond, o=Novell, c=US" names the person "cn=Aaron Osmond" in the organization "o=Novell, c=US." Likewise, the name "o=Novell, c=US" names the organization "o-Novell" in the country "c=US."
   
   

As the two examples above illustrate, a naming service's naming convention alone has the potential to introduce a significant amount of the flavor of the underlying naming service into JNDI. This is not particularly a feature an implementation-independent interface should have.

JNDI solves this problem with the Name class and its subclasses and helper classes. The Name class represents a name composed of an ordered sequences of subnames, and provides methods for working with names independent of the underlying naming service.