Why Applications Need Naming and Directory Services

A fundamental facility of any enterprise application is the capability to locate components and services. A client wishing to locate a component or service in an enterprise typically will know the name of the component or service, but probably will be unaware of the physical location of that component. The name of the component usually is an alias or user -friendly substitution for the real name, which might be more of a computer-friendly name. This is similar to how the Internet Domain Name Service (DNS) maps machine names , such as www.apache.org , to Internet Protocol (IP) addresses such as 64.208.42.41 .

Building software applications where components and services are decentralized throughout the enterprise increases the need for a naming service when compared to a more traditional two-tier client/server application. In a multi-tier enterprise application, you typically have the Client tier (browser), Web tier (Web server), Application tier (application server), and the Enterprise Information System tier (RDBMS and ERP systems). All these tiers can be located on different machines.

So now that components are spread throughout the network, how do they find each other when they need to request services from one another? The whole idea of separating services into components is to assign responsibilities and to allow for components to invoke requests on other components. They need a way to locate each other that is transparent. By transparent , we mean that the client component does not know the exact physical location of the server component. For example, if we had an OrderFulfillment component that was called by the Web tier, and the OrderFulfillment component moved to a different physical server, it should not negatively affect the other components that use its services. The reason why enterprise applications need some type of naming and/or directory service is to help locate each other in this vast expanse we call the enterprise. Remember, for an enterprise application, a component might be a client in one request and then a server in another.

For enterprise applications, a naming and directory service provides a means by which your application can locate a reference to needed services. The service might be a JDBC datasource, a JMS connection factory, a reference to a home interface for an enterprise bean, or any other object or data that is needed by the enterprise.

Naming and directory services each provide a distinct purpose for use in enterprise applications. Although we'll describe each service briefly in the next section, our aim is to understand the naming service. We'll not spend any considerable amount of time on directory services other than to describe what they are. For the purpose of this book, it's the naming service that we need to understand.

Naming Service

A naming service is an application that holds on to a collection of objects or references to objects and associates a user-friendly name with each one. This association is known as a binding . Figure 4.1 shows an example of a binding.

Figure 4.1. An example of a naming service binding.

A resource bound to a name can be an object or possibly a reference to an object that resides somewhere else on the reachable network. For example, you could build a Hashtable with data in it and store this object into a naming service and associate it with a name. You could also build a Hashtable and create an RMI server to access that Hashtable and associate the RMI stub with a name. In either case, clients who wanted to get the information from the Hashtable could connect to the naming service and find it by using the name that it was associated with.

Note

How you go about connecting to a naming service and locating objects in it are covered later in this chapter.

This is similar to a phone book, if you use your imagination a bit. In a phone book, let's say the name "Fred's Plumbing Service" points to an advertisement for a plumbing service. I use the name of the service to locate the telephone number, which is just a reference to the actual service. If I wanted to make a request on the service, I would have to follow the reference, in this case make a phone call. If we were referring to an actual naming service instead of a phone number, we might locate an RMI proxy object. In that case, we could follow the reference and invoke methods on the remote object.

This also is analogous with how a DNS works. When you look up a Web site address such as java.sun.com , the DNS doesn't store the sun.com domain; it stores a reference to the IP address that has been associated with this domain. Using the IP address, a client can get in touch with the Web site by using the address 204.160.241.48.

Figure 4.2 shows how references can be stored as well as objects in a naming service.

Figure 4.2. Naming services can store references as well as the object data.

A collection of interconnected bindings make up something called a namespace . All telephone numbers in a phone book, for example, could be considered a namespace, just as the sun.com domain is essentially a namespace. The naming service is responsible for managing the bindings within the namespace. For enterprise applications, you can locate a resource within a namespace by using the user-friendly name and getting the resource that is associated with that name. Figure 4.3 shows how bindings and namespaces are related .

Figure 4.3. Namespaces are made up of a set of bindings.

Directory Services

A Directory service is just an extension of the features provided by a naming service. Directory services allow attributes to be associated with a binding. Clients can use a directory service to search for a specific binding with specific attribute values.

We'll use one of the most common examples to describe how you might use a directory service. Let's say an organization has several printers and each one of these printers is accessible through a naming and directory service. Each printer in the directory service could have an attribute that says whether or not it can print in duplex mode (this means on both sides). A client could find a printer in the directory service by filtering bindings where the duplex mode is true.

The following is a list of some common directory service implementations :

• Lightweight Directory Access Protocol (LDAP)

• Network Directory Service (NDS)

• Network Information Service Plus (NIS+)

• X.500