RFC 2713 (rfc2713) - Page 2 of 21
Schema for Representing Java(tm) Objects in an LDAP Directory
Alternative Format: Original Text Document
RFC 2713 Schema for Java Objects October 1999
For example, an application server might use the directory for
"registering" objects representing the services that it manages, so
that a client can later search the directory to locate those services
as it needs.
The motivation for this document is to define a common way for
applications to store and retrieve Java objects from the directory.
Using this common schema, any Java application that needs to read or
store Java objects in the directory can do so in an interoperable
way.
2 Representation of Java Objects
This document defines schema elements to represent three types of
Java objects: a Java serialized object, a Java marshalled object,
and a JNDI reference. A Java remote object is stored as either a Java
marshalled object or a JNDI reference.
2.1 Common Representations
A Java object is stored in the LDAP directory by using the object
class javaObject. This is the base class from which other Java object
related classes derive: javaSerializedObject, javaMarshalledObject,
and javaNamingReference. javaObject is an abstract object class,
which means that a javaObject cannot exist by itself in the
directory; only auxiliary or structural subclasses of it can exist in
the directory.
The object class javaContainer represents a directory entry dedicated
to storing a Java object. It is a structural object class. In cases
where a subclass of javaObject is mixed in with another structural
object class, javaContainer is not required.
The definitions for the object classes javaObject and javaContainer
are presented in Section 4.
The javaObject class has one mandatory attribute (javaClassName) and
four optional attributes (javaClassNames, javaCodebase, javaDoc,
description). javaClassName is a single valued attribute that is
used to store the fully qualified name of the object's Java class
(for example, "java.lang.String"). This may be the object's most
derived class's name, but does not have to be; that of a superclass
or interface in some cases might be most appropriate. This attribute
is intended for storing the name of the object's "distinguished"
class, that is, the class or interface with which the object should
be identified.
Ryan, et al. Informational