1.4 The Components of JNDI

JNDI provides both an API for almost all software developers and a Service Provider Interface (SPI) for the underlying service providers. Java applications sit on top of the JNDI API framework, providing access to the Service Provider Interface (SPI) and JNDI classes. The Service Providers then provide access to the naming systems in a 1-to-1 relationship.

The JNDI framework API is contained in three interface packages:

1.4.1 Naming Interface

The naming interface organizes information hierarchically and maps human-friendly names to addresses or objects that are machine-friendly. It allows access to named objects through multiple namespaces. There are many interfaces and classes defined in JNDI; however, the core interface in the javax.naming package is Context, a context without attributes. It contains the heart of the JNDI features, and it is extended or implemented by several other classes and interfaces in the system.

The defined methods in the Context interface allow you to perform basic operations on named objects, such as adding a name-to-object binding, looking up the object bound to a specified name, listing the bindings, removing a name-to-object binding, creating and destroying subcontexts, and so forth. Each method is a one-to-one mapping to behaviors of the context.

Because all contexts are abstracted behind the Context interface, you can access all contexts through the Context interface methods. This makes all contexts have a uniform interface.

Methods in the Context interface that will be commonly used include the following:

  • lookup( ) returns the name of an object of whatever class is required by the Java application.
  • list( ) returns an enumeration of the names and the class names of their bound objects in the named context.
  • listBindings( ) returns an enumeration of the names and their bound objects in the named context. Calling listBindings( ) on a directory returns the name of objects bound to that specified directory.

Other key classes and interfaces in the javax.naming package include:

  • Binding, which represents a name-to-object binding found in a context.
  • CompositeName, which represents a composite name that is a sequence of component names spanning multiple namespaces.
  • CompoundName, which represents a name from a hierarchical namespace.
  • InitialContext, which is the starting context for performing naming operations. A client obtains an initial context to provide a starting point for name resolution.
  • Name, which represents a generic human-friendly name. Every name is relative to a context and every naming operation is performed on a context.
  • NameParser, which is used to manipulate a name in a namespace.
  • Reference, which represents a reference to an object found outside the naming/directory system.

1.4.2 Directory Interface

JNDI includes a directory service interface that provides access to directory objects, which can contain attributes, thereby providing attribute-based searching and schema support. The major interfaces in this package are DirContext, Attribute, and Attributes.

The DirContext interface defines methods for examining and updating attributes associated with directory objects. The DirContext interface extends the javax.naming.Context interface, and is a context containing zero or more attributes. Usually a DirContext represents a named object such as a file, a directory, or an NDS object, each of which has attributes that you can access and modify. The main difference between a DirContext and a Context is that a DirContext allows you to retrieve and modify attributes and schema data, whereas a Context does not.

DirContext methods allow you to perform operations on named objects with attributes. Each directory object contains a set of zero or more objects of the class Attribute. An Attribute represents an attribute associated with a named object and is denoted by a string identifier; and it can have zero or more values of any type.

Further, since a DirContext is also an instance of Context, it inherits all the methods in the Context interface, and thus you can perform all Context methods on a DirContext. Additional DirContext methods allow you to get, set, and modify attributes, as well as access the schema and the schema class definition of an object. Each method is a one-to-one mapping to operations you can perform on attributes of the context.

Most of the contexts in the Novell services implement the DirContext interface. However, some contexts, which represent logical objects that have no attributes, implement the Context interface (such as Trees, Servers, File System, NCPExtensions, and Bindery). All NDS objects and the files and directories of the NetWare file system are implemented as DirContexts.

Methods in the DirContext interface that will be commonly used include the following:

  • search( ) supports context-based searching, and returns the matching directory objects along with the requested attributes.
  • createSubcontext( ) creates a new subcontext with a name that you pass into the method as a parameter, binds the subcontext in the target context you specify, and associates attributes you pass in as a parameter.
  • getAttribute( ) returns a NamingEnumeration of the Attributes associated with the named object that you pass into the method as a parameter.
  • getSchema( ) retrieves the schema root of the DirContext you specify.

Other key classes and interfaces in the javax.naming.directory package include the following:

  • Attribute, which is an actual attribute associated with a named object of a context. An attribute consists of an identifier (attrID) and a set of zero or more values. Each value in the set is typed as a java.lang.Object that you narrow to the appropriate class or interface.The definition of the attribute and the syntax of its value(s) are contained in the schema if the underlying directory service supports schemas.
  • Attributes, which represent a collection or set of individual instances of attributes that are associated with a DirContext object, and attributes that use java.util.Enumeration methods to access attribute objects in the attributes set. The Attributes of a DirContext represent attributes of a context in the service provider.
  • InitialDirContext, which is the starting context for performing directory operations. It represents the programmatic entry point to a service provider.
  • SearchControls, which encapsulates factors that determine the scope of search and what gets returned as a result of the search.
  • SearchResult, which represents an item returned as a result of the DirContext.search( ) method.

1.4.3 Service Provider Interface

JNDI does not include service providers; however, JavaSoft does provide a Service Provider Interface (SPI), which third parties such as Novell use to implement service providers. The SPI provides a way for service providers to develop and hook up their naming and directory implementations to the JNDI. The JNDI allows specification of names that span multiple namespaces. Thus, the SPI provider methods allow different provider implementations to cooperate so as to complete client JNDI operations.

The JNDI SPI is not for application developers, and you do not need to use the SPI unless you are writing a provider for JNDI. The SPI is for developers who write a service provider implementation for a naming system, such as Novell Directory Services (NDS). Novell ships service providers for JNDI that enable you to access NetWare and a host of NetWare services, including NDS. This means that programmers can have access to NetWare services without worrying about the SPI.

A JNDI service provider is actually a context implementation, which provides a class that implements the Context or DirContext interface in the JNDI API. By implementing the interface and providing the actual methods of the interface, the vendor of different naming and directory service providers can expose their services to JNDI-enabled applications.

JNDI has a concept of federation, which means a context in one naming system can be bound to a context in another naming system. It is the decision of the service provider vendor to determine if federation is supported. If it is supported, name resolution across multiple namespaces is handled in the service provider and is completely transparent to the application programmer. The implementation of federation enables a single application to access data across multiple namespaces seamlessly because different service providers cooperate with each other to complete JNDI operations. The NJCL fully supports context federation and provides multiple service providers for different NetWare namespaces. This enables NetWare application programmers to navigate through the global Novell namespace to access different NetWare services. For a more detailed explanation of federation, see Context Federation.

Context interfaces from different naming systems implement the JNDI Service Provider Interfaces differently depending on the semantics of the naming system. Novell Services (including JNDI Providers) describes how each context implements these interfaces.