| 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()` and `Context.lookup()` as described in the Storing Objects in the Directory lesson and the Reading Objects from the Directory 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 lesson, service providers are encouraged to support storing the following types of objects:
> - `Referenceable` objects
> - `Reference` objects
> - `java.io.Serializable` objects
> - `DirContext` 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("")` 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` object is represented in the directory by its reference ( `Referenceable.getReference()`). A `Reference` 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()`
> `javaFactoryName` | `Reference.getFactoryClassName()`
> `javaCodebase` | `Reference.getFactoryClassLocation()`
> `javaReferenceAddress` | `Reference.get()`

> `"javaReferenceAddress"` is a multivalued attribute consisting of one or more values. Each value represents a `RefAddr`. Details of how a `RefAddr` is encoded are given in RFC 2713. See the Tips for LDAP Users 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.

| Representation in the Directory