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

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 02

Network Working Group                                            V. Ryan
Request for Comments: 2713                                   S. Seligman
Category: Informational                                           R. Lee
                                                  Sun Microsystems, Inc.
                                                            October 1999

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

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document defines the schema for representing Java(tm) objects in
   an LDAP directory [LDAPv3].  It defines schema elements to represent
   a Java serialized object [Serial], a Java marshalled object [RMI], a
   Java remote object [RMI], and a JNDI reference [JNDI].

1. Introduction

   This document assumes that the reader has a general knowledge of the
   Java programming language [Java].  For brevity we use the term "Java
   object" in place of "object in the Java programming language"
   throughout this text.

   Traditionally, LDAP directories have been used to store data. Users
   and programmers think of the directory as a hierarchy of directory
   entries, each containing a set of attributes.  You look up an entry
   from the directory and extract the attribute(s) of interest.  For
   example, you can look up a person's telephone number from the
   directory.  Alternatively, you can search the directory for entries
   with a particular set of attributes.  For example, you can search for
   all persons in the directory with the surname "Smith".

   For applications written in the Java programming language, a kind of
   data that is typically shared are Java objects themselves.  For such
   applications, it makes sense to be able to use the directory as a
   repository for Java objects.  The directory provides a centrally
   administered, and possibly replicated, service for use by Java
   applications distributed across the network.

Ryan, et al.                 Informational                      [Page 1]
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                      [Page 2]
RFC 2713                Schema for Java Objects             October 1999

   javaClassNames is a multivalued attribute that is used to store the
   fully qualified names of the object's Java classes and interfaces
   (for example, "java.lang.Byte"). Like all multivalued attributes, the
   javaClassNames attribute's values are unordered and so no one value