Previous | Next | Trail Map | Java Objects and the Directory | Representation in the Directory

LDAP Directories

The details of how LDAP attributes are used to store data about Java objects are described in the Internet-draft draft-ryan-java-schema-01.rev.txt. The discussion here is a quick summary of that description. It is intended primarily for developers of LDAP service providers. API users will generally not need this information. Service providers implement the details here so that API users can simply use methods such as Context.bind()(in the API reference documentation) and Context.lookup()(in the API reference documentation) as described in the Storing Objects in the Directory (in the Java Objects and the Directory trail) and Reading Objects from the Directory (in the Java Objects and the Directory trail) lessons.

In addition to reading this section, developers of LDAP service providers and those needing to add the Java schema to servers should consult the Internet-draft draft-ryan-java-schema-01.rev.txt.

Types of Objects

As indicated in the Object Factories (in the Java Objects and the Directory trail) lesson, service providers are encouraged to support storing the following types of objects: In addition to these types, Sun's LDAP provider also supports storing java.rmi.Remote objects.

These types of objects are represented in the LDAP as subclasses of the "javaObject" abstract object class. The "javaObject" object class defines the mandatory attribute "javaClassName", for recording the name of the Java class, and the optional attribute "javaCodebase", for recording the location of the Java class's class files.

DirContext

A DirContext object is stored straightforwardly in the directory as an LDAP entry with attributes. In other words, an LDAP service provider extracts the attributes using DirContext.getAttributes("")(in the API reference documentation) and stores them into the directory. When such an entry is read from the directory, it is returned as a DirContext.

Referenceable Objects

A Referenceable(in the API reference documentation) object is represented in the directory by its reference ( Referenceable.getReference()(in the API reference documentation)). A Reference(in the API reference documentation) is represented in the directory by its fields, which are stored as attributes of an LDAP entry as follows:

LDAP Attribute Name Content
javaClassName Reference.getClassName()(in the API reference documentation)
javaFactoryName Reference.getFactoryClassName()(in the API reference documentation)
javaCodebase Reference.getFactoryClassLocation()(in the API reference documentation)
javaReferenceAddress Reference.get()(in the API reference documentation)

"javaReferenceAddress" is a multivalued attribute consisting of one or more values. Each value represents a RefAddr(in the API reference documentation). Details of how a RefAddr is encoded are described in the Internet-draft draft-ryan-java-schema-01.rev.txt.

An LDAP entry that has these attributes must include "javaObject" and "javaNamingReference" in its list of object classes.

When these attributes are read from an LDAP entry, they are used to construct a Reference, which is then used to construct an object represented by the information in the reference.

Serializable Objects

A java.io.Serializable object is represented in the directory as follows:

LDAP Attribute Name Content
javaClassName Object.getClass().getName()
javaSerializedData serialized form of object
javaCodebase URL of codebase or JAR file to load classes for serialized object

An LDAP entry that has these attributes must include "javaObject" and "javaSerializedObject" in its list of object classes.

When these attributes are read from an LDAP entry, they are used to reconstruct a copy of the serialized object. The contents of the "javaSerializedData" attribute is deserialized into an java.lang.Object. If the "javaCodebase" attribute is available, the classes needed for the deserialization are loaded from the supplied URL.

Remote Objects

A java.rmi.Remote object is stored in the directory as an RMI URL. This is the same URL that any RMI application would use when using the RMI registry directly.

LDAP Attribute Name Content
javaClassName Object.getClass().getName()
javaRemoteLocation RMI URL of remote object.

An LDAP entry that has these attributes must include "javaObject" and "javaRemoteObject" in its list of object classes.

When these attributes are read from an LDAP entry, they are used to look up the remote object from the RMI registry identified in the "javaRemoteLocation" attribute. This requires that the application have access to the JNDI/RMI registry service provider. If this provider is not available, the RMI URL itself is returned.

Schema

The object class and attribute definitions to be added to the schema of your directory are included with this tutorial.

If you are adding an LDAP entry that consists just of attributes that represent a Java object, you need to also include the object class "javaContainer", which is a structural object class that allows the entry to exist in the LDAP directory. See the Internet-draft draft-ryan-java-schema-01.rev.txt for details.


Previous | Next | Trail Map | Java Objects and the Directory | Representation in the Directory