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 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).
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
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 to an IP address (220.127.116.11), 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.
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 for a diagram of a generic directory service.
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. A popular protocol for accessing directory services is the Lightweight Directory and Access Protocol (LDAP). LDAP is a protocol that defines how client applications can manipulate data on a directory server, but says nothing about how the data should be stored. Generally speaking though, directory services usually allow you to store objects in a hierarchical fashion. LDAP servers, for example, arrange all objects in a tree known as the Directory Information Tree (DIT).The categorization of entries can simplify the search for particular objects. For example, a Yellow Pages directory might have categories for lawyers and carpet fitters.The categorized entries are a form of subcontext within the directory context of the Yellow Pages directory. In essence, a directory service is really just a simple database that enables you to search for data, and to narrow that search by specifying search criteria.When you perform a search of a directory service, there are three pieces of information that you need to specify:
Relational Database Management Systems (RDBMS) is another technology that might spring to mind while reading this discussion of directory services.An RDBMS enables you to create, update, retrieve, and remove entries that are stored within it, as does a directory service. One difference is that the internal data tends to be stored differently. This is because an RDBMS generally uses a relational information model that involves the use of tables. An RDBMS usually also supports transactions that allow a group of operations to be rolled back if a particular step fails for some reason. Directory services are designed more to be very quick at reading and searching for data, and use a hierarchical data model as mentioned earlier.
Note that the syntax for specifying names varies between naming services. For example, the Microsoft Windows operating system allows you to use the character to separate the components in a path such as c:winntsystem32driversetchosts.When you use the DNS naming convention, you specify a name, such as where each component in the path is separated by the . character. LDAP servers use names that are based on the X.500 standard. Such names (known as distinguished names) have the following general form: cn=Peter Szolkowski, ou=Bikers, o=MANX_RACERS, c=uk
This form might also be familiar to you if you have used Microsoft’s Active Directory service, which also uses names based on the X.500 standard.The difference is that it uses the / character rather than commas to delimit the name components: cn=Peter Szolkowski/ou=Bikers/o=MANX_RACERS/c=uk
Both LDAP and Active Directory use hierarchical names.When the names are read from left to right, the most specific part of the name occurs first and the least specific part occurs last. When you use JNDI, most of the time you simply specify a string that JNDI passes on to the underlying naming service with a minimum of interpretation.You should be aware that JNDI also provides support for creating and manipulating structured names.
Why Use a Naming Service?
One reason to use a naming service is that it enables you to decouple the provider of a service from its consumer.This is because the name that the supplier of the service uses to register the service is the only thing that the consumer needs to know. Another reason to use a naming service is that it can provide an application with a single repository of information in which it can find all of its required resources. When you use a naming service, you have a consistent way of publishing services that is independent of any particular platform and, therefore, is portable. In addition, you are free to migrate a service from one host to another. All that you would need to do is update the entry in the naming service to point to the new location of the service.The beauty of this is that the client needs to know nothing about the fact that the service has moved. If you did not use JNDI to access a naming service, life would be a lot more difficult when you have to provide services such as those that are implemented using J2EE objects such as message queues, EJBs, and data sources. Every vendor would have to implement a proprietary mechanism that defined how client code gains access to J2EE objects. For example, one vendor might use TCP/IP broadcast network packets, whereas another could use textual configuration files.
JSP Related Interview Questions
|J2EE Interview Questions||Core Java Interview Questions|
|JDBC Interview Questions||Java Servlets Interview Questions|
|Hibernate Interview Questions||JavaServer Faces (JSF) Interview Questions|
|JSTL(JSP Standard Tag Library) Interview Questions||JBOSS Interview Questions|
|Log4j Interview Questions||NHibernate Interview Questions|
|Apache Struts 2 Interview Questions|
All rights reserved © 2020 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.