Mastering Enterprise JavaBeans™ and the Java 2 Platform, Enterprise Edition - Roman E

564 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Person 1

People

Person 2

Printers

Computer 1

Network

Computers

Services

Computer 2

Fax Machines

Fax Machine 1

Figure B.1 A hierarchical directory structure.

are accessed differently than those based on the Network Information System

(NIS) or Novell’s Network Directory System (NDS).

This means that if you want to switch directory vendors, you need to rewrite all of your client code that accesses the directory. It also means you need to download a new library, learn a new API, and test new code each time you use a different directory.

Initially, LDAP was meant to resolve this problem by becoming the ubiquitous protocol for directories. LDAP is very straightforward and is being adopted quickly by the industry—IBM’s Lotus Notes and Microsoft’s Active Directory both are LDAP-based. However, not all directory products are LDAP-based.

Go back to the first page for a quick link to buy this book online!

Understanding the Java Naming And Directory Interface (JNDI) 565

Enter JNDI

The Java Naming and Directory Interface (JNDI) is a system for Java-based clients to interact with naming and directory systems. JNDI is a bridge over naming and directory services—a beast that provides one common interface to disparate directories. Users who need to access an LDAP directory use the same API as users who want to access an NIS directory or Novell’s directory. All directory operations are done through the JNDI interface, providing a common framework.

If you use the JNDI, you have to download only one package and learn only one interface to access directories. And JNDI is a standard Java extension, which means it is officially endorsed and supported by Sun Microsystems.

In theory, by using the JNDI you should be able to replace the underlying directory without affecting the client code very much. This is useful if your company one day decides to switch directories, such as from an LDAP directory to an NDS directory. Rather than rewriting all of your directory-based applications, JNDI allows your code to be portable between directory services. This minimizes overhead headaches.

Benefits of JNDI

The following surveys the advantages that JNDI has to offer:

■■JNDI is a unified system to access all sorts of directory service information, such as security credentials, phone numbers, electronic and postal mail addresses, application preferences, network addresses, machine configurations, and more.

■■JNDI is a single API to access different directories with different protocols.

■■JNDI insulates the application from protocol and implementation details.

■■JNDI is extensible. Future providers of directories can plug in their particular directory services to JNDI without affecting your client code.

■■Using JNDI, you can read and write whole Java objects from directories. This is a very powerful idea, which we’ll illustrate in the discussion that follows.

■■You can link different types of directories, such as an LDAP directory with an NDS directory, and have the combination appear to be one large, federated directory. The federated directory appears to be one contiguous directory to the client.

Go back to the first page for a quick link to buy this book online!

566 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

■■JNDI is supported by Sun Microsystems, and it is a standard Java extension. Standard Java extensions can be automatically downloaded from a URL if they aren’t present in a particular Java 2 platform installation.

JNDI Overview

Now that you’ve seen the motivation for the JNDI, let’s look at the architecture and API details.

JNDI Architecture

JNDI is made up of two halves: the client API and the Service Provider Interface

(SPI). The client API allows Java code to perform directory operations. This API is uniform for all types of directories. The client API is probably what you will be spending the most time using.

The JNDI SPI is an interface to which naming and directory service vendors can plug in. The SPI is the converse of the API: While the API allows clients to code to a single, unified interface, the SPI allows naming and directory service vendors to fit their particular proprietary protocols into the system, as shown in Figure B.2. This allows for client code to leverage proprietary naming and directory services in Java while maintaining a high level of code portability.

Client code

Figure B.2 JNDI architecture.

Go back to the first page for a quick link to buy this book online!

Understanding the Java Naming And Directory Interface (JNDI) 567

JNDI’s architecture is somewhat like the Java Database Connectivity package (JDBC):

■■In JDBC, there is one uniform client API for performing database operations. In JNDI, naming and directory service clients invoke a unified API for performing naming and directory operations.

■■In JDBC, relational database vendors provide JDBC drivers to access their particular databases. In JNDI, directory vendors provide service providers to access their specific directories. These providers are aware of specific directory protocols, and they plug in to the JNDI SPI.

For example, Sun Microsystems gives away an LDAP service provider for free. The LDAP service provider knows how to map a JNDI client API operation into an LDAP operation. It then executes the LDAP operation on an LDAP directory, using the specific LDAP protocol.

Available Service Providers

At the time of this writing, there are nine service providers for JNDI. Anyone can write a service provider—and new ones will probably have emerged by the time you read this.

Note that a service provider may not support every operation JNDI’s client API exposes. Each service provider ships with documentation that details the JNDI supported functions, as well as any specifics about the service provider. When you choose your service provider, see the included documentation for further details.

LDAP

The Lightweight Directory Access Protocol (LDAP), invented at the University of Michigan, was originally intended to be a ubiquitous protocol for accessing directory services. Indeed, many directory services use LDAP as their standard protocol. JNDI’s value-add over basic LDAP is as follows:

■■JNDI is Java-based and provides Java clients with access to LDAP-based directories. Instead of using a custom LDAP package in Java, you can use Sun Microsystem’s LDAP service provider, which is available free of charge.

■■JNDI allows you to bind Java objects to directory structures (which we’ll see a bit later).

■■The JNDI vision is to allow you to use other directory protocols besides LDAP.

Because LDAP is the most popular directory protocol, we’ll use LDAP in some of the examples later in this appendix. The LDAP service provider from Sun

Go back to the first page for a quick link to buy this book online!

568 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Microsystems is very robust, and it can perform authentication of users, establish secure socket connections, and more.

NIS

The Network Information Service (NIS) is used by Sun’s Solaris operating system, as well as other UNIX operating systems, to store information about users, machines, and network services. The NIS protocol does not support all of the operations that write to a directory, so this service provider is an example of a service provider that does not completely support the JNDI client API operations.

Novell NDS

Novell Directory Services (NDS) is a distributed database that stores information about hardware and software resources on a network. NDS gives developers, users, and administrators global access to all network resources through a single login and a single point of network administration. It also provides a flexible directory database schema, network security, and a robust development environment. Novell is famous for its directory products, and it has been a major proponent of JNDI.

SLP

The Service Location Protocol (SLP) provides a scalable framework for the discovery and selection of network services, minimizing the need for static configuration within network-based applications. SLP is an Internet Standard protocol that can be used for a variety of purposes, such as discovering DHCP servers, DNS servers, Novell NDS servers, and more.

CORBA COS Naming

The CORBA standard (described in Chapter 11) contains a specification for an optional naming service in CORBA. CORBA’s naming service is called the Object Naming Service, or COS Naming. COS Naming allows CORBA client programs to look up CORBA objects over a multi-tier deployment or across enterprises.

Typically, if you are a CORBA programmer, you would access CORBA’s COS Naming facilities through a CORBA implementation that includes the COS Naming service. Sun Microsystem’s CORBA implementation, Java IDL, is an example of a CORBA implementation that provides the COS Naming service.

Sun Microsystems also provides a free service provider for JNDI that knows how to talk with CORBA’s COS Naming Service. This service provider plugs into JNDI just like any other service provider, such as the LDAP service provider. The

Go back to the first page for a quick link to buy this book online!

Understanding the Java Naming And Directory Interface (JNDI) 569

CORBA COS Naming service provider allows JNDI clients to access CORBA naming and directory services through the JNDI client API. It does this by wrapping the CORBA COS Naming package and delegating to it.

So why would you use JNDI rather than Java IDL (or some other CORBA implementation) to access CORBA’s COS Naming facilities? Well, if you’re a CORBA programmer and you use Java IDL, you restrict yourself to looking up only CORBA object references. COS Naming was intended to look up only CORBA objects, and not to serve as a general naming and directory service utility. For example, you could not use COS Naming to look up someone’s username and password in an LDAP directory structure. But by using JNDI, your client code can use the COS Naming provider for looking up CORBA objects, yet still use the same JNDI client API as a general-purpose naming and directory interface by plugging in other providers.

JNDI is the future path for looking up CORBA objects from other naming services such as LDAP. We will also be able to bind other kinds of objects to COS Naming as well. In RMI over IIOP (described in Chapter 11), JNDI can be used to bind RMI remote objects into the COS Naming Service.

File System

The File System service provider gives you access to a file system through the JNDI client API. You can use the File System service provider to browse a hard disk, for example, using JNDI operations. Clients can also store Java objects in the file system using JNDI. In a sense, when you use the File System service provider, your file system itself is acting as a naming and directory service. We will demonstrate how to use this service provider later in this appendix.

RMI Registry

The RMI Registry service provider allows you to bind a whole RMI Registry into a directory (see Appendix A for an RMI tutorial). The idea here is to bind your RMI remote objects to a local RMI registry, then bind that registry to a directory via JNDI. Clients can access your remote objects via JNDI rather than looking up objects in your RMI registry. This allows multiple server machines to publish their remote objects within a robust directory system, centralizing the location of business objects. When clients use the regular RMI bootstrapping mechanism, they are connecting to individual servers that may, in fact, be down at the time. With the centralized directory system, clients can instead use JNDI to find a list of available RMI registries. We’ll explain more about how the RMI Registry service provider works, along with a complete example, later in this chapter.

Go back to the first page for a quick link to buy this book online!

570 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

BEA’s WebLogic Naming Service

BEA Systems, Inc. is an EJB container/server vendor that bundles a proprietary directory service with their product. Their directory service is fault-tolerant, providing a high level of availability. They also supply an integrated naming service that ties together with the Enterprise Java services, such as RMI, JDBC, EJB, and event services. Finally, their product ships with tools for building custom naming and directory providers.

To access their naming and directory service, they provide a JNDI service provider. BEA’s JNDI package actually implements the entire JNDI specification published by Sun Microsystems. BEA provides more than just a service pro- vider—WebLogic JNDI is involved in all levels of directory operations, and it is a total replacement for Sun Microsystems’s reference implementation of JNDI.

Why would you use WebLogic’s JNDI? For one, WebLogic JNDI uses WebLogic’s own custom socket implementation, which multiplexes many types of traffic (for example, JDBC traffic mixed with JNDI traffic) all on one socket. This optimization leads to enhanced performance.

More importantly, WebLogic’s implementation of the JNDI specification is a distributed implementation of JNDI. It is distributed in the sense that its JNDI implementation can delegate to a JNDI service provider that is located on a different machine across a network. This means the WebLogic service provider is acting as a proxy for the real service provider, such as an LDAP service provider or an NDS service provider. This distributed JNDI implementation is especially useful if your JNDI client is a Java applet. Java applets have security restrictions that prevent them from running native code (unless they are digitally signed). And unfortunately, JNDI service providers often contain native code, such as a service provider that may access the Windows NT registry. Because JNDI service providers may contain native code, they cannot run within the context of an unsigned Java applet. WebLogic’s delegation method allows service providers to be located on a secure machine and still be usable by clients that are not secure.

Because BEA has actually shipped a complete JNDI implementation, it is more than just a service provider. Note that this is merely an example of a JNDI implementation; the playing ground is open for other vendors to do the same.

Understanding the Concepts behind JNDI Programming

Before we embark on a JNDI example, let’s lay a foundation of the concepts behind JNDI. We begin with naming concepts.

Go back to the first page for a quick link to buy this book online!

Understanding the Java Naming And Directory Interface (JNDI) 571

Naming Concepts

As we have said, a naming service is an entity that associates names with objects. You can use these names to later find the object based on that name.

Atomic, Compound, and Composite Names

There are several kinds of names in JNDI:

■■An atomic name is a simple, basic, indivisible component of a name. For example, in the string /etc/fstab, etc and fstab are atomic names.

■■A compound name is zero or more atomic names put together. In the previous example, the entire string /etc/fstab is a compound name.

Bindings, Contexts, and Subcontexts

A binding is an association of a name with an object. For example, the filename autoexec.bat in the Windows file system has a binding to the file data on your hard disk. Your c:\windows folder is a name that is bound to a folder on your hard drive. Note that a compound name such as /usr/people/ed/.cshrc consists of multiple bindings, one to usr, one to people, one to ed, and one to .cshrc. Bindings are illustrated in Figure B.3.

A context is an object that contains zero or more bindings. Each binding has a distinct atomic name. So, for example, in the UNIX file system, let’s consider a folder named /etc that contains files named mtab and exports. In JNDI, the /etc folder is a context containing bindings with atomic names mtab and exports. Each of the mtab and exports atomic names is bound to a file on the hard disk. Figure B.4 illustrates this concept.

Binding with the name "etc"

Binding with the name "fstab"

Figure B.3 Bindings.

Go back to the first page for a quick link to buy this book online!

572 M A S T E R I N G E N T E R P R I S E J A V A B E A N S

Binding with the name "mtab"

- Binding with the name "etc".

- Also a context which contains other bindings.

Binding with the name "exports"

Figure B.4 Contexts.

To expand this further, consider a folder named /usr with subfolders /usr/people, /usr/bin, and /usr/local. Here, the /usr folder is a context that contains the people, bin, and local atomic names. Each of these atomic names is bound to a subfolder. In JNDI terms, these subfolders are called subcontexts. Each subcontext is a full-fledged context in its own right, and it can contain more name-object bindings, such as other files or other folders. Figure B.5 depicts subcontexts.

Naming Systems, Namespaces, and Composite Names

A naming system is a connected set of contexts. For example, a branch of an LDAP tree could be considered a naming system, as could a folder tree in a file system. Unfortunately, naming systems each have a different syntax for accessing contexts. For example, in an LDAP tree, a compound name is identified by a string such as “cn=Ed Roman, ou=People, o=Middleware-Company.com, c=us”, whereas a file system compound name might look like “c:\java\lib\classes.zip.” Keep this in mind, as we will revisit this issue a bit later.

Within a naming system, a namespace is all the names contained within that naming system. Your hard drive’s entire collection of filenames and directories or folders is your hard drive file system’s namespace; the set of all names in an LDAP directory’s tree is an LDAP server’s namespace. Naming systems and namespaces are shown in Figure B.6.

A composite name is a name that spans multiple naming systems. For example, on the Web, the URL http://java.sun.com/products/ejb/index.html is composed from the following namespaces:

Go back to the first page for a quick link to buy this book online!