Naming services provide a good mechanism for mapping objects to identifiable names. There are many mechanisms for organizing and storing these named objects, such as LDAP or RMI or even your computer’s file system. JNDI provides a consistent API for accessing all of these types of naming services. JNDI also allows you to manipulate and traverse the organization of more complex services known as directory services.

Directory Services

Directory services are types of naming services that provide structure to some set of objects or data values. You can think of a phone book as a sort of directory service that organizes collections of names, phone numbers, and addresses based on region, city, state, or country. Typically, the structure of a directory service is hierarchical. For example, most computer file systems start with a root directory and have a series of subdirectories, each containing files. Although this directory structure is common, other attributes of the resources within a directory service namespace may vary greatly. One directory service may be capable of setting information such as the file access permissions or the modified date, while other directory services, such as LDAP, allow the definition of arbitrary attributes on a resource.

Each node or directory structure can be considered the root of the directory tree below it, hierarchically. Clients of the directory set their focus on the specific subdirectory they are interested in accessing. An example of this would be the act of changing directories in your file system and then accessing a file. If you wanted to access the file /usr/tmp/myFile.txt, you could change directories to /usr/tmp and then access the file by referring to it by its name, myFile.txt. Otherwise, if you were at the root directory, you would have to refer to the file by the name /usr/tmp/myFile.txt. Like files in the file system, contents of directories are referred to by name, relative to the current directory. This current directory is called a context.

Context

Each node of a directory structure can be referred to as a context. Directory services allow you to read and modify attributes attached to contexts and have the ability to search a context using those attributes as a filter. For example, you could search an LDAP directory service for all people working in the marketing department named Joe, where Joe is the value of the name attribute of the person you are searching for. In this structure, you could have people listed in your company directory that have the names of their assistants associated with their listing, while others do not even have an assistants attribute.

Service Providers

Each directory service requires a service provider that maps from JNDI into the specific operations supported by the directory service. Directory services may vary greatly in how they organize information, search directories, and modify attributes. However, JNDI provides a consistent interface, so your Java program can retrieve and modify values in a directory with a single API. One of the most prominent directory services that you will want to access in your enterprise will be an LDAP server. This service is discussed in Chapter 5, “Using JNDI,” to show how to use the directory features of JNDI. A list of currently available service providers is presented in Table 4.1.

---

NOTE:  For the most recent list of service providers, check the URL http://java.sun.com/products/jndi/serviceproviders.html.

---

LDAP

Lightweight Directory Access Protocol (LDAP) directory service provides a lightweight version of X.500 directory service that can run on the TCP/IP protocol stack. This protocol is becoming popular and is a common service integrated in products such as Netscape’s Enterprise Server. The protocol allows networked users access to information and resources in a consistent fashion by providing a simple searching facility that allows you to search and modify items based on their position in the directory hierarchy, referred to as a context. For example, you could search LDAP for all the people in the marketing department that have a fax number in the 415 area code. Once you located them, you could change their area code to 650. The search could ignore anyone that did not have a fax number attribute associated with their information. The attributes associated with a context are variable, which provides flexibility but does require extra discipline by administrators to adhere to a consistent naming structure. In other words, LDAP does define some standard in how to organize information, but it is fairly free-form, so the administrator must take care when naming attributes and deciding where attributes belong in the directory. For example, one person could have an attribute called telephone while another person could have an attribute called phone. This is legal in LDAP but would make it difficult to search for people by their telephone numbers, because you would need to search for the existence of either attribute.