1.5.1 JNDI Context

As a central concept in JNDI, context is used in a variety of ways to refer to different aspects of JNDI programming. First, it is an object whose state is a set of bindings with distinct atomic names. A context has an associated naming convention and it provides naming operations. Examples of contexts are files, directories, servers, and anything else that can have bindings.

An object is a context if something can be bound to the object, or if the object has subordinates that could be described as bindings. A context that is bound to another as a subordinate is known as a subcontext. A directory is a context, since files and other directories can be bound to it. There is no hard and fast rule that excludes an object from being a context; however, items that have no container abilities cannot be contexts. The naming system decides which nodes will be terminal, or leaf nodes.

Sometimes we refer to context as a named object; however, this is not exactly accurate, since a printer can have a name and not be a context. Since nearly all of the named objects you will work with are contexts, we refer to named objects and contexts interchangeably.

1.5.2 Initial Context

An initial context is a programmatic entry or starting point to a service provider for resolution of names within a namespace. The only time you must work directly with an initial context is when first accessing a service provider. You must set the system properties to reflect the service provider with which you want to work. Then once the properties are set, you create an initial context for that service provider.

Creating an initial context requires that you specify the appropriate initial context factory. You can learn which are the appropriate initial context factories for the naming systems by viewing the documentation for an individual service provider in Novell Services (including JNDI Providers). The following initial contexts are defined:

Usually the appropriate provider to work with is the Section 2.7, NetWare Provider, which was designed to federate to all service providers, and acts as an effective root to all other providers.

1.5.3 Context Binding

The association between an object and its atomic name or some other property is known as context binding. A name-to-object binding contains the name of the bound object, the name of the object's class, and the object itself. A binding can be associated with a NULL object, and a context can contain zero bindings.

When you create a subordinate context, or bind in an object reference to an existing context, you are creating an association between two objects-the existing context and the new subordinate. This association is a binding, which must be given a name. When you list the subordinates of a context, and then look up one of them, you are performing the opposite of binding. You are resolving a context by name, thus you are looking at the object that was bound using the given name.

1.5.4 Context Interface

The most concrete use of the term is in the javax.naming.Context interface. This is the primary JNDI interface, which defines the naming methods: list, lookup, search, bind, unbind, and so forth.

Subclasses of the javax.naming.Context interfaces include the javax.naming.InitialContext class, the javax.naming.directory.DirContext interface, and the javax.naming.directory.InitialDirContext class. These subclasses are also often referred to generically as contexts to emphasize their commonality.

Classes that implement the javax.naming.Context interface (directly or using a derivative subclass) are also referred to as contexts. Thus, a file context actually refers to the file class or object that represents a file while also implementing the Context interface as its naming method. Again, it may also be referred to generically as a context to emphasize its commonality with the rest of the naming systems.

1.5.5 Implementor of Context

A component of a service provider that implements part of the behavior of a naming system is also referred to as a context. In this sense, a context is the implementation of a volume, a directory, a file, and so forth, and is closely associated with the service provider interface.

A context’s implementation resides in the bytecode for the service provider to which it belongs. This implementation is often private so that you are insulated from the details of how a particular context works. Because JNDI is the public interface for the underlying NetWare naming systems, you need learn only how to use JNDI, not the many different interfaces.

Sometimes you need to know the class of a particular context, usually when making a decision about which non-JNDI interfaces or attribute IDs you need to work with. You can find out what kind of class the context is through the instanceof operator in Java. Even though the implementation details may be private, you can find out what implementation you are working with, then look up the attribute IDs in the naming system.

1.5.6 DirContext Interface

An extension of the JNDI Context interface that includes attributes is the DirContext interface. Any DirContext can also act as a naming context, allowing you to perform context operations on a DirContext.

A DirContext has overloaded methods that allow you to perform certain naming and directory operations automatically. Usually, these methods have the same name as the equivalent Context methods, only with an overloaded signature that requires you to pass in an AttributeSet.

A DirContext can also return schema information. For example, the method getSchema( ) returns the root of the schema of the DirContext, whereas the method getSchemaClassDefinition( ) returns the definition of the DirContext. These schema objects are each in turn a DirContext, so you can call standard DirContext methods to work with a DirContext schema in addition to its own attributes. The schema objects provide descriptive information about the DirContext that returned them.

1.5.7 Context Federation

Federation is a context in one naming system referring to a context, or object, in another naming system. It is actually a binding between a context in one name system and an object in another name system. The following graphic shows some examples of federation in the NDS naming system.

Figure 1-7 NJCL Federation in NDS Naming System

Another example of federation occurs when you are in the NDS naming system, and you encounter an NDS object that is a container for a NetWare volume, and you want to list the subordinates of the volume container. When you perform the list operation, you have federated into the file system naming system and are no longer in the NDS naming system.

Novell’s JNDI service providers use two types of federation: explicit and implicit.

Explicit federation occurs when you explicitly bind a referencable object from one naming system into another. The application will see explicit bindings/federations when list( ) is called. Novell’s service providers use the following names for explicit federation:

As an example, the following name uses explicit federation:

   Servers/MY_SERVER/FileSystem/SYS/MyFile
   

If the current service provider for the application was the NetWare service provider, federation would occur at the following points in the name:

Implicit federation is implemented by the service provider, which decides how to federate. This happens when you have a context at the terminal of a naming system, and you call the list( ) method with the context’s name followed by a trailing slash (/). The trailing slash (/) is the key to the implicit federation.

For example:

   Trees/MY_TREE/MY_SERVER.MY_OU.MY_ORG
   

would take you to the MY_SERVER object in the NDS directory.

   Trees/MY_TREE/MY_SERVER.MY_OU.MY_ORG/
   

would take you to the actual server.

In this case, the NDS service provider federates into the Server service provider because MY_SERVER is a server object. Notice that the Server key word was not used.

1.5.8 NDS Context

This term denotes a logical position in a hierarchical NDS tree or an identifier for the current position in a tree. This concept should not be confused with a JNDI context.

The Full Distinguished Name (FDN) of an NDS object shows the context of the object. For example, the name joe.engineering.novell refers to a user object in the context of engineering.novell.