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 RFC 2713. RFC 2714 describes how CORBA object references are stored in an LDAP directory. This section offers a quick summary of those documents. It is intended primarily for developers of LDAP service providers and of object/state factories for LDAP directories. API users will generally not need this information. Service providers and object/state factories 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) lesson and the Reading Objects from the Directory (in the Java Objects and the Directory trail) lesson.

Developers of LDAP service providers and object/state factories, as well as those needing to add the Java/CORBA schema to servers, should consult these documents in addition to reading this section.

Types of Objects

As indicated in the State 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 has state factories that support storing java.rmi.Remote and CORBA objects.

The Java objects are represented in the LDAP as subclasses of the "javaObject" abstract object class. This object class defines the attributes listed in the following table.

LDAP Attribute Name Content
javaClassName (mandatory) The distinguished class name of the object
javaClassNames All other names of classes and interfaces implemented by the object
javaCodebase The location of the object's class files
javaDoc The location of the object's class document
description The textual description of the object

DirContext

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

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 as a "javaNamingReference" object class. This object class defines the attributes listed in the following table.

LDAP Attribute Name Content
javaClassName (mandatory) 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 given in RFC 2713. See the Tips for LDAP Users (in the Tips for LDAP Users trail) trail for an example.

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 a "javaSerializedObject" object class. This object class defines the attributes listed in the following table.

LDAP Attribute Name Content
javaClassName (mandatory) Object.getClass().getName()
javaSerializedData (mandatory) Serialized form of object
javaClassNames Names of all interfaces and classes implemented by the object
javaCodebase Space-separated list of URLs of directories or JAR files containing classes of the 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 content of the "javaSerializedData" attribute is deserialized into a java.lang.Object. If the "javaCodebase" attribute is available, then the classes needed for the deserialization are loaded from the specified codebase.

Marshalled Objects

To marshal an object means to record its state and codebase(s) in such a way that when the marshalled object is unmarshalled, a copy of the original object is obtained, possibly by automatically loading the class definitions of the object. You can marshal any object that is serializable or remote (that is, implements the java.rmi.Remote interface).

Marshalling is like serialization, except that it also records codebases. It differs from serialization in that it treats remote objects specially. If an object is a java.rmi.Remote object, then marshalling records the remote object's stub, instead of the remote object itself. As with serialization, when an object is marshalled the entire tree of objects rooted at the object is marshalled. When it is unmarshalled, the tree is reconstructed. A marshalled object is represented by the java.rmi.MarshalledObject class. It is represented in the directory as a "javaMarshalledObject" object class. This object class defines the attributes listed in the following table.

LDAP Attribute Name Content
javaClassName (mandatory) Object.getClass().getName() (of the unmarshalled object)
javaSerializedData (mandatory) Serialized form of the marshalled object
javaClassNames Names of all interfaces and classes implemented by the (unmarshalled) object

An LDAP entry that has these attributes must include "javaObject" and "javaMarshalledObject" in its list of object classes. When these attributes are read from an LDAP entry, they are used to reconstruct a copy of the marshalled object. The content of the "javaSerializedData" attribute is deserialized into a java.rmi.MarshalledObject. An object factory responsible for marshalled objects can then unmarshal the object by invoking java.rmi.MarshalledObject.get().

CORBA Objects

The CORBA objects are represented in the LDAP as subclasses of the "corbaObject" abstract object class. This object class defines the attributes listed in the following table.

LDAP Attribute Name Content
corbaRepositoryId Ids of the interfaces implemented by the object
description Textual description of the object

A CORBA object is stored in the directory by recording its CORBA object reference. A CORBA object reference is represented in the directory as a "corbaObjectReference" object class. This object class defines the attribute listed in the following table.

LDAP Attribute Name Content
corbaObjectReference (mandatory) Stringified form of the CORBA object reference

An LDAP entry that has this attribute must include "corbaObject" and "corbaObjectReference" in its list of object classes. When this attribute is read from an LDAP entry, it is used to reconstruct the stringified object reference, which then is used by an object factory to get the corresponding "live" CORBA object.

Remote Objects

A java.rmi.Remote object that uses the JRMP protocol is stored in the directory either as a Reference that contains an RMI URL or as a marshalled object. A java.rmi.Remote object that uses the IIOP protocol is stored in the directory as a CORBA object; that is, the CORBA object reference of the object's CORBA tie is stored.

Schema

The Java schema and the CORBA schema that you need to add to your directory are included with this tutorial. See RFC 2713 and RFC 2714 for details.


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