April 24, 2014
Hot Topics:
RSS RSS feed Download our iPhone app

Locating Resources Using JNDI (Java Naming and Directory Interface)

  • June 2, 2003
  • By Sams Publishing
  • Send Email »
  • More Articles »

This material is from Chapter 13, Locating Resources Using JNDI, from the book JavaServer Pages Developer's Handbook (ISBN: 0-672-32438-5) written by Nick Todd and Mark Szolkowski, published by Sams Publishing.

Chapter 13: Locating Resources Using JNDI

Chapter 13: Locating Resources Using JNDI

This chapter introduces the concepts surrounding the Java Naming and Directory Interface (JNDI). It discusses the need for naming services, and the purposes for which Web applications use them. Directory services are also described, and by the time you have read this chapter you will be able to distinguish between the two types of service.

You will then be introduced to JNDI and its architecture before seeing the specifics of using JNDI in a Web application. In the next chapter (Chapter 14, "Databases and JSP") there are examples of using JNDI to locate JDBC datasources. In Chapter 15, "JSP and EJB Interaction," you will see Web applications that use JNDI to locate Enterprise JavaBeans (EJBs).

Note - If you want to run the demonstration applications for this chapter, you will need the chapter13.ear and chapter13.jar files from the book Web site (http://www.samspublishing.com). The source code for the standalone examples is in the file chapter13.jar in the CommandLineJNDI folder.

Naming and Directory Services

This part of the chapter discusses naming services, and then directory services. After you have read them you will know what each is, as well as the differences between them. You have probably already come across several such services, such as DNS and NDS.

Overview of Naming Services

A naming service is quite simply a software application that associates a name with the location of information or services. This means that the software you write can utilize objects without any knowledge of where those objects are located. The objects need not even reside on your local machine, but can live on any machine that is accessible on the network.

Another benefit to using a naming service is that for most people it is much easier to remember a logical name rather than a URL or some other object reference. For example, you can associate a logical name with a JDBC datasource. It is much easier to remember a name like CUSTOMER_ADDRESSES than a JDBC URL such as jdbc:mysql://localhost:3306/ADDRESS!

This really is not that much different from many examples in day-to-day life. For example, if you want to make a telephone call to somebody whose number you don't know, you normally look that number up in a telephone book. Conversely, you can register your own telephone number with the producers of the telephone book so that other people can look you up.

The only tricky part about looking up somebody's number in a telephone book (assuming that they are listed) is making sure that you are looking in the correct telephone book. You have a similar problem to overcome when writing computer software that uses a naming service, in that you can only lookup an object if you search the correct naming service. The term given to this is that you must obtain a context.

When you then use a context to retrieve information from a naming service, you are said to perform a lookup. The act of storing the name/resource pair in the naming service in the first place is known as binding. However, when people use the term a binding, they are referring to the association between an object and its name. After an object has been registered by name in the naming service, a client can retrieve a reference to the object by specifying the same name.

Figure 13.1 shows the basic architecture involved with using a naming service. The diagram depicts a client that retrieves an object by specifying a name that was previously used to bind an object into the naming service. You can see that the naming service associates a name with an object (a binding).

Figure 13.1
The architecture of a naming service.

You have just read that a context is a set of name/resource pairs. A naming system contains a set of related contexts that have the same naming convention. It is this naming system that provides the naming service to clients. The set of names in a naming system is known as a namespace.

Several common naming services are

  • The CORBA Common Object Services (COS) Naming Service provides a hierarchical directory in which you can store object references, in a way that is comparable to directories in file systems. The COS Naming Service is widely used in Java-based distributed environments as a way of storing information about the location of remote objects. You can find further information on the COS Naming Service at http://www.omg.org.

  • Domain Name Service (DNS) is the Internet naming service that identifies hosts on a network by performing a translation between host names and Internet addresses. All Internet clients use DNS, for example, Web browsers. More information on DNS can be found online at http://www.dns.net/dnsrd/rfc/.

  • Network Information Service (NIS) from Sun Microsystems provides system-wide information about users, files, printers, machines, and networks. You will normally encounter NIS when working with systems that use the Solaris operating system. There are, however, other systems such as Linux and other Unix operating systems that support NIS.

  • Novell Directory Services (NDS) provides information about network services such as printers and files. NDS is mainly found in environments where Novell provides the main networking software.

  • File systems in general. File and directory objects are bound to names and are generally stored in a hierarchical form.

  • The RMI registry is a simple server-side bootstrap naming facility that enables remote clients to obtain a reference to a remote object.

One example of a binding is a file that is bound to its filename. Another is an IP address that is bound to a hostname in DNS or WINS.

At the very least, a naming service must provide the capability to bind objects to a name and support the retrieval of those objects by name. However, the way in which the naming service can store the objects can differ. For example, the actual resource might be stored inside or outside the naming service. A naming service that does not store the resource directly is DNS. DNS simply maps a logical name such as http://www.samspublishing.com to an IP address (, but does not store the remote host itself. This situation also arises when the object that is associated with the name is large, and you do not want to store it in the naming service. In this case you can store a reference to the object instead.

An example of a naming service that can store objects internally is the file system provided by Microsoft Windows NT. For efficiency, NTFS stores files that are smaller than about 1KB in the Master File Table (MFT). Anything larger than this is stored externally.

It is possible to overwrite an existing binding by specifying the same name, but a different resource. This is known as rebinding. In the previous telephone number example, this is analogous to moving and being allocated a new number by the telephone company. Other things that you can do with a naming service include renaming a bound object, and unbinding it completely so that it is no longer available to clients.JNDI also supports the notion of federated namespaces. This is when a resource is identified by a name that spans multiple naming systems. For example, consider the name myhost.somedomain.com/documents/manual.txt. The first part of this name (myhost.somedomain.com) is a host name that must be resolved via DNS, and the rest of the name (documents/manual.txt) is a file system name. For details of how this works, see the JNDI tutorial at http://java.sun.com/products/jndi/tutorial/beyond/fed/index.html.

Overview of Directory Services

A directory service is similar to a naming service in that it enables you to associate names with objects. However, a major distinction between the two is that a directory service enables you to store information about the object (these pieces of information are known as attributes), in addition to providing mechanisms for searching for objects based on that information. For example, if you need to print out a color photograph, you could use a directory service to find the locations of color printers in your office building. See Figure 13.2 for a diagram of a generic directory service.

Figure 13.2
The architecture of a directory naming service.

Going back to the real-world telephone book example, using a directory service is similar to using the Yellow Pages phone directory. Instead of simply listing the name of a business along with a contact telephone number, the Yellow Pages directory often includes advertisements that contain additional information that add value to the entry. For example, a business might list location maps, professional qualifications, and even affiliated organizations. The fact that a directory service enables you to search for objects based on the values of these attributes means that you can, for example, search for all plumbers who operate a 24-hour emergency service in your neighborhood.

Page 1 of 7

Comment and Contribute


(Maximum characters: 1200). You have characters left.



Sitemap | Contact Us

Rocket Fuel