Schema for Representing Java(tm) Objects in an LDAP Directory
RFC 2713
Document | Type |
RFC - Informational
(October 1999; No errata)
Was draft-ryan-java-schema (individual)
|
|
---|---|---|---|
Authors | Scott Seligman , Rosanna Lee , Vincent Ryan | ||
Last updated | 2013-03-02 | ||
Stream | Legacy stream | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | Legacy state | (None) | |
Consensus Boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | RFC 2713 (Informational) | |
Telechat date | |||
Responsible AD | (None) | ||
Send notices to | (None) |
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 valueShow full document text