J2EE Naming and Directory Services
- Naming and Directory Services
- Using JNDI with J2EE RI
- Using JNDI Outside J2EE
- Using JNDI Functionality
- Directory Services
- JNDI Security
- Summary
- Q&A
- Exercise
This chapter is from the book
This chapter is from the book
This chapter is from the book
Days 1 and 2 introduced you to enterprise computing concepts and J2EE technologies such as EJBs and Servlets. This chapter will show how the Java Naming and Directory Interface (JNDI) supports the use of many of the J2EE components.
In its simplest form, JNDI is used to find the resources (such as EJBs) that you have registered via the J2EE server. Advanced use of JNDI supports sophisticated storage and retrieval of Java objects and other information.
This day's work will include
-
Using Naming and Directory Services
-
JNDI and X.500 names
-
Obtaining a JNDI Initial Context
-
Binding and looking up names
-
Name attributes
-
Objects and References
-
JNDI events and security
Naming and Directory Services
A Naming Service provides a mechanism for giving names to objects so you can retrieve and use those objects without knowing the location of the object. Objects can be located on any machine accessible from your network, not necessarily the local workstation.
A real-world example is a phone directory. It stores telephone numbers against names and addresses. To find people's phone numbers is simply a matter of using their name (and possibly address) to identify an entry in the phone book and obtaining the stored phone number. There are a few complications, such as finding the right phone book to look in, but it is essentially a simple process.
Incidentally, naming services have a similar problem to that of finding the right phone book. This is known as obtaining a context. A name can only be found if you examine the right context (phone book).
A Directory Service also associates names with objects but provides additional information by associating attributes with the objects.
The yellow pages phone directory is a simple form of a directory service. Here, businesses often include advertisements with additional information such as a list of products sold, professional qualifications, affiliated organizations, and even maps to their premises. These attributes add value to the name entry. A directory service will normally provide the ability to find entries that have particular attributes or values for attributes. This is similar to searching the yellow pages for all plumbers running a 24-hour emergency service within a certain area.
Yellow page style phone books also store names under categories—for example, hairdressers or lawyers. Categorizing entries can simplify searching for a particular type of entry. These categorized entries are a form of sub-context within the directory context of the local phone book.
Why Use a Naming or Directory Service?
Naming Services provide an indispensable mechanism for de-coupling the provider of a service from the consumer of the service. Naming services allow a supplier of a service to register their service against a name. Users, or clients, of the service need only know the name of the service to use it.
Think of the phone book once more, and how difficult it would be to find someone's phone number without it. Obtaining your friend's phone number would mean going to their home and asking, or waiting until you meet up with them again—which may be difficult to organize because you can't phone them to arrange the meeting.
At the end of the day, it is very difficult to imagine a world without naming services.
What Is JNDI?
JNDI is a Java API that defines an interface to Naming and Directory Services for Java programs. JNDI is just an API and not, in itself, a Naming and Directory Service. To use JNDI, an implementation of a Naming and Directory service must be available. JNDI provides a service-independent interface to the underlying Service Provider implementation.
Figure 3.1 shows how the JNDI layer interfaces between the Java program and the underlying naming services. Additional naming services can be plugged into the JNDI layer by implementing the Service Provider Interface (SPI) for JNDI.
)
Figure
3.1 JNDI Architecture.
JNDI has been a standard component of J2SE since version 1.3. JNDI is available as a standard Java extension for JDK 1.2 and earlier. JNDI has always been a required component of J2EE.
Common Naming Services
Figure 3.1 shows that JNDI supports plug-in Service Providers for several well-known naming services, including the following:
Lightweight Directory Access Protocol (LDAP) is the approved standard for an Internet naming service. LDAP is a true directory service and supports attributes as well as names for objects. LDAP is fast becoming the de facto directory service for the enterprise.
Domain Name System (DNS) is the Internet naming service for identifying machines on a network.
Novell Directory Services (NDS) from Novell provides information about network services, such as files and printers. NDS is found primarily in environments where the main networking software is Novell.
Network Information Service (NIS) from Sun Microsystems provides system-wide information about machines, files, users, printers, and networks. NIS is primarily found on Solaris systems, but Linux and some other Unix platforms also support it.
JNDI also supports some more specialized naming systems. For example, CORBA for distributed component programming and RMI for distributed Java programming.
Although there is no named Service Provider for Windows Active Directory within JNDI, it is supported. Windows Active Directory supports an LDAP interface, and you can access it via the JNDI LDAP Service Provider Interface.
Naming Conventions
Each naming service has its own mechanism for supplying a name. Perhaps the most familiar naming convention is DNS, where every machine connected to the Internet has a unique name and address. Most readers will recognize the following as a host name used by DNS:
http://www.samspublishing.com
In contrast, LDAP names are based on the X.500 standard and use distinguished names that look like the following fictitious example:
cn=Martin Bond, ou=Authors, o=SAMS, c=us
This format will also be familiar to users of Microsoft's Active Directory service, whose naming system is also based on X.500 but uses a forward slash to separate the various name components:
cn=Martin Bond/ou=Authors/o=SAMS/c=us
These last two naming conventions have similarities in that they are both hierarchically structured with the more specific names (such as cn=Martin Bond) being qualified by a general name (such as o=SAMS).
JNDI applies minimal interpretation to names specified as String objects. JNDI uses the forward slash character (/) as a name separator to provide a simple name hierarchy called a Composite Name. It is conventional for these composite names to be used to group related names (such as plumbers in the phone book). As an example, JDBC data sources take names of jdbc/XXX and EJBs the form ejb/XXX. While this is only a convention, it does help separate different sorts of named objects within the JNDI name space.
Composite names can span different naming systems. An LDAP name can combine with a file system name to get a composite name:
cn=Martin Bond, ou=Authors, o=SAMS, c=us/agency/agency.ldif
Here a filename (agency/agency.ldif) is appended to an LDAP name. How JNDI interprets this is up to the individual Service Provider.
Incidentally, JNDI calls structured names like the DNS and LDAP names Compound Names. JNDI does not interpret compound names, but simply passes them through to the Service Provider.
In addition to forward slash (/), JNDI also treats backslash (\), single quote ('), and double quote (") characters as special. If a compound name or a component of a name contains any of these characters, they must be escaped using the backslash character (\). Remember that backslash and double quotes are also special characters in Java string literals and must be escaped. Therefore to insert a double quote into a JNDI name you must place \\\" into the string literal. For example the following is how to insert the name jdbc/"Agency"—avoid this if you can.
"jdbc/\\\"Agency\\\""
If the underlying Service Provider uses the forward slash as a name separator (as does the CORBA name service for example), there appears to be a conflict between JNDI and the Service Provider. In practice, this is unlikely to be a problem because JNDI recognizes two sorts of name separation—weak and strong. JNDI always passes the entire name to the Service Provider. A strong name separation implementation (such as LDAP or DNS) simply processes the first part of the composite name and returns the remainder to the JNDI Naming Manager to pass on to other name services. A weak name separation implementation will process the entire composite name. This is not something you need to worry about unless you are writing a Service Provider.
For those programmers who need to do more than use names to look up and bind objects, JNDI provides several classes for manipulating and parsing composite and compound names. The JNDI name support classes in the javax.naming package are Name, CompositeName, and CompoundName.