RFC 2713 (rfc2713) - Page 2 of 21

Schema for Representing Java(tm) Objects in an LDAP Directory

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