Understanding Naming and Directory Services

To use JNDI, you need to have a basic understanding of what naming and directory services are. A naming service is a repository to store the bindings between a name and an object.

Note

The association of a name to an object in a naming or directory service is called a binding .

A directory service extends this capability by allowing the bindings to also contain a list of attributes. JNDI provides the ability to lookup the name of a bound object or search for bound objects by matching attributes that are stored with the object.

Note

WebLogic Server is strictly used as a naming service to lookup names that are bound to an object in the JNDI tree; no directory service attributes are used.

A computer file system can be thought of as a naming service. You provide the filename, and it returns the data stored with that file. This is directly analogous to what is offered by a naming service. For J2EE applications, the unique JNDI name is bound to the interface for the remote object. The administration of the naming service is performed through the JNDI API or tools provided by the J2EE server implementing the naming service. For example, WebLogic Server provides access to its naming service through the Administrator Console.

The following sections describe the naming and directory services supported by WebLogic Server through the provided SPIs.

LDAP Server

LDAP stands for the Lightweight Directory Access Protocol which provides both a naming and a directory service. LDAP evolved from the X.500 Directory Access Protocol, where it originally only provided the TCP/IP front end for DAP. The X.500 DAP is based on the OSI model for networking. LDAP provided the interface to TCP/IP clients . Gradually, LDAP and DAP merged into the standalone entity now known simply as LDAP which is considered a "lightweight" implementation of the Directory Access Protocol.

LDAP now runs as a standalone service. It must be configured with a back-end database that is used for persistent storage of the bindings and attributes. The schema of the database is organized as a hierarchical tree structure, also commonly referred to as the Directory Information Tree ( DIT ). Each element in the tree has a unique name, called its distinguished name . The distinguished name is constructed by concatenating the name of each element up to the root of the tree. An example of the LDAP tree structure is shown in Figure 14.2.

Figure 14.2. The LDAP tree structure is a graphical representation of the distinguished names.

From the elements in Figure 14.2, you can see that the LDAP distinguished name for the RemoteObject is "cn=RemoteObject,dc=weblogic,dc=com" . Each element of the distinguished name is a node in the tree. This example contains three elements separated by commas which follows the syntax of an LDAP distinguished name. Each element must match an attribute type that is defined in a schema that the LDAP server was configured to install.

The syntax for an individual element in the distinguished name is:

 <  attribute  >=<  name  > 

The <attribute> must match an attribute from the schema. The <name> is any name of your choosing to uniquely identify the entry.

Note

The specification for the LDAP schema used by Java can be found at http://www.ietf.org in RFC 2713 Schema for Representing Java Objects in an LDAP Directory. V. Ryan, S. Seligman, R. Lee. October 1999.

The configuration of the LDAP server specifies a base distinguished name in the hierarchical tree for each back-end database that it is configured to use. All elements below the base are physically stored in the corresponding back-end database. The LDAP server configuration also defines a root distinguished name which is used to control access to the server. The root distinguished name is password protected.

Note

An example of how access is controlled by the root distinguished name is provided in the "LDAP Security Considerations" section later in this chapter.

Because LDAP is a directory service, each element in the tree may have a list of attributes. Again, the attributes must match the schema that is defined for the LDAP server. In the case of J2EE applications, the JNDI name is bound to a serialized Java object that represents the remote interface; no directory attributes are used.

Note

LDAP has become the standard for network directory services.

WebLogic Server is compatible with any LDAP server that is LDAP v2 compliant. For example, the following LDAP servers have been tested with WebLogic:

• Sun's iPlanet version 4.1.3

• Microsoft Active Directory as shipped with Windows 2000

• Open LDAP version 2.0.7

• Novell NDS version 8.5.1

RMI Registry

The RMI registry is the naming service used by Java Remote Method Invocation. It maintains the bindings between a name and the object that implements the remote interface. The RMI registry is accessed from RMI clients using the JNDI API or the java.rmi.Naming class.

Note

Refer to the section "Using the RMI SPI" later in this chapter for further information on accessing the RMI registry through JNDI.

The entries in the RMI registry are created by the RMI remote object which binds the name to the remote object that it is implementing. The RMI client looks up the name in the RMI registry to retrieve the remote interface. The Java 2 Standard Edition includes the executable "rmiregistry" that implements the registry for RMI.

For further information on RMI, see Chapter 12, "Distributed Processing Using RMI," p. 385 .

COS Name Server

The Common Object Services (COS) Name Server is the naming service for CORBA. It maintains the bindings between a name and a CORBA server. The COS Name Server is accessed using the JNDI API or the classes in the org.omg . CosNaming.NamingContext package. Listing 14.1 shows an example of locating a CORBA server named "Hello" using the classes in the org.omg.CosNaming and org.omg.CosNaming.NamingContextPackage packages.

Listing 14.1 The Hello CORBA Server Is Located Using the COS Naming Context Classes

 import org.omg.CosNaming.*; import org.omg.CosNaming.NamingContextPackage.*; // get a reference to the Hello server from CORBA public void findHelloServer() { org.omg.CORBA.Object objRef = orb.resolve_initial_references("NameService"); NamingContext ncRef = NamingContextHelper.narrow(objRef); // resolve the Object Reference in Naming NameComponent nc = new NameComponent("Hello", ""); NameComponent path[] = {nc}; Hello helloRef = helloHelper.narrow(ncRef.resolve( path )); } 

The COS naming service can also be accessed using JNDI. The advantage of using JNDI is to better achieve portability. Rather than being locked into CORBA, writing the code using JNDI provides the flexibility to attach to a different naming service without significant modification to the code.

Note

Refer to the section "Using the COS SPI" later in this chapter for further information on accessing the COS name server using the JNDI API.

The WebLogic Naming Service

WebLogic Server's implementation of a JNDI naming service serves as an in-memory repository and lookup service for all hosted J2EE objects and services, such as:

• EJB Home stubs

• JDBC DataSources and Connection Pools

• JMS Destinations and Connection Factories, Queues and Topics

• RMI Stubs

For example, in a J2EE application, a JavaServer Page (JSP) or servlet is typically the client of the Enterprise Java Bean (EJB); thus, it performs the lookup operation using JNDI to retrieve the client-side interface to the EJB. An entity EJB also uses JNDI to lookup the DataSource and UserTransaction objects to communicate with a database.

However, since the JNDI objects are stored in-memory, the JNDI service should not be used as a database. The objective of JNDI is to store Java objects to support repetitive lookups only. Storing large objects, such as a file, using JNDI would not only require a large amount of memory, but would also be a burden on the network.

Note

Refer to the section "Examples of Using JNDI in J2EE Applications" later in this chapter to see specific examples of accessing the WebLogic Naming Service using JNDI.

The Structure of the WebLogic Naming ServiceThe JNDI Tree

In order to bind and lookup objects using JNDI in WebLogic Server, you must understand the internal structure of WebLogic Server's naming service, also referred to as the JNDI tree .

The structure of the WebLogic JNDI tree is illustrated in Figure 14.3, where:

Figure 14.3. The Internal Structure of the WebLogic Server's JNDI Tree.

• A Context ( C ) represents a node in the tree and is bound to other contexts or objects. A context bound to another context is known as a subcontext . For example, given a DNS domain Bea.COM, the DNS domain Bea is a subcontext of COM.

• Objects ( O ) are bound to a context and represent the leaves in a JNDI tree. Examples of objects include EJB Home interface objects, DataSource objects and factory objects for creating connections to JMS topics. A binding associates an object with a name with its relative context. Hence, each Context can be asked to find an object within its branch of the tree by giving the object's name relative to its context.

• The Root Context ( RC ) is the uppermost context of the JNDI tree.

• The Initial Context ( IC ) serves as the starting point for all future JNDI tree searches (object lookups), similar to when you select your current directory on a file system.

The WebLogic Server binds J2EE services into the JNDI tree as part of the installation. In addition, the WebLogic container binds the local and remote home interfaces of EJBs into the JNDI tree when enterprise applications are deployed. The installed J2EE services can be viewed on the WebLogic Administrator Console using the following steps:

1. Connect to the WebLogic Administrator Console with a web browser. If the web browser is being run on the same system as the WebLogic Application Server, the URL is typically http://localhost:7001/console .

2. The frame on the left side is the navigation tree to select the available services. In the navigation tree, open the Servers folder in the domain that is installed. This folder contains the list of configured servers. Right-click on a server name and select the "View JNDI tree" menu item.

3. The JNDI tree for the selected server opens in a new browser window. An example of the JNDI tree viewer is shown in Figure 14.4, which shows the default JNDI bind names and objects under the weblogic context.

   Figure 14.4. The bind names and objects in the JNDI tree can be viewed from the WebLogic Administrator Console.

   

You can also use the WebLogic.Admin utility to view the JNDI bindings in your WebLogic Server using the following syntax:

 java weblogic.Admin [-url  URL  ] -username username -password  password  LIST  context  

where:

• URL specifies the listen address of the WebLogic Server that is the target of the command. The format for the URL is hostname:port; for example the default is localhost:7001.

• username specifies the username to access the target WebLogic Server for the command.

• password specifies the password associated with the username to access the target WebLogic Server for the command.

• LIST specifies the command to list the JNDI tree node bindings.

• context specifies the JNDI context for lookup, for example, weblogic, weblogic.ejb, or javax.

For example, in the following weblogic.Admin statement, the user wls, who has a password of einstein , requests a list of the node bindings in the context named weblogic:

 java weblogic.Admin -url localhost:7001 -username wls -password einstein LIST weblogic 

The output for this statement is shown in Figure 14.5.

Figure 14.5. Using the weblogic.Admin utility to view the WebLogic JNDI bindings.

Tip

If a JNDI lookup fails, you can use the WebLogic Administrator Console to "View the JNDI tree" and verify that the attributes of the bound object match the name you are trying to lookup.

Using JNDI in a WebLogic Server Cluster

A unique capability of the WebLogic naming service is that it can provide support for a WebLogic clustered environment. In a clustered environment, multiple WebLogic Servers work together to provide a seamless, fault-tolerant application server to the J2EE clients. Each WebLogic Server in the cluster shares information about its services with the other WebLogic Servers. From this collection of information, a clusterwide JNDI tree of services is created. A JNDI lookup operation with the WebLogic naming service can locate all the services available to the cluster, not just an individual application server. WebLogic clusters are supported by a replicated clusterwide JNDI tree that provides access to both replicated and pinned RMI and EJB objects.

The provision of the WebLogic naming service to support clustered capabilities enables it to offer services to J2EE applications that other naming services cannot support. Specifically, JNDI names are bound to objects in the WebLogic naming service that are used with the Enterprise Java Beans, RMI, JDBC, and JMS technologies. Therefore, it is important to understand the implications of binding an object to the JNDI tree in a clustered environment to use the WebLogic naming service effectively.

A WebLogic Server cluster provides multiple, cooperating WebLogic Servers that share common services. This configuration enables load-balancing and failover of the execution of J2EE services. Load-balancing spreads the execution over the available hardware resources. Failover provides robustness and fault tolerance by automatically identifying when a server is not operational, and choosing a different application server for the next instance of the remote object or the next invocation of an existing remote object. The capability to offer load-balancing and failover is possible because the objects that are bound in JNDI are automatically replicated throughout the cluster to create a common JNDI tree. The definition of replicated versus pinned objects is whether or not the object can participate in load-balancing and failover. Replicated objects are allowed to participate in load-balancing an failover because they can exist on any application server in the WebLogic cluster. Pinned objects have an application specific need to exist on only one server, and therefore cannot be replicated to another server in the cluster. Replicated objects are preferred in order to take advantage of the robustness and scalability of the WebLogic cluster.

There are, however, application-specific reasons for not allowing the replication of various J2EE services. The first issue deals with EJB session beans. If a bean is stateful, it may store client state information on the application server. To maintain state, the EJB session bean must always execute on the same application server. This concept is referred to as a pinned object meaning the object is pinned to a specific application server. The alternative is referred to as a replicated object which exists on multiple servers in the cluster. Though the terminology is not as explicit as stateful or stateless, an RMI remote object may also store state information and therefore must also be bound as a pinned object.