rfc2713.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,180 行 · 第 1/3 页

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
   is more "distinguished" than the others. This attribute is intended
   for storing an object's class and interface names and those of its
   ancestor classes and interfaces, although the list of values does not
   have to be complete.  If the javaClassNames attribute is present, it
   should include the value of javaClassName.

   For example, suppose an object is stored in the directory with a
   javaClassName attribute of "java.io.FilePermission", and a
   javaClassNames attribute of {"java.security.Permission",
   "java.io.FilePermission", "java.security.Guard",
   "java.io.Serializable"}. An application searching a directory for
   Java objects might use javaClassName to produce a summary of the
   names and types of Java objects in that directory.  Another
   application might use the javaClassNames attribute to find, for
   example, all java.security.Permission objects.

   javaCodebase is a multivalued attribute that is used to store the
   location(s) of the object's class definition.  javaDoc is used to
   store a pointer (URL) to the Java documentation for the class.
   description is used to store a textual description of a Java object
   and is defined in [v3Schema]. The definitions of these attributes are
   presented in Section 3.

2.2 Serialized Objects

   To "serialize" an object means to convert its state into a byte
   stream in such a way that the byte stream can be converted back into
   a copy of the object.  A Java object is "serializable" if its class
   or any of its superclasses implements either the java.io.Serializable
   interface or its subinterface java.io.Externalizable.
   "Deserialization" is the process of converting the serialized form of
   an object back into a copy of the object.  When an object is
   serialized, the entire tree of objects rooted at the object is also
   serialized. When it is deserialized, the tree is reconstructed. For
   example, suppose a serializable Book object contains (a serializable
   field of) an array of Page objects.  When a Book object is
   serialized, so is the array of Page objects.

   The Java platform specifies a default algorithm by which serializable
   objects are serialized. A Java class can also override this default
   serialization with its own algorithm.  [Serial] describes object
   serialization in detail.





Ryan, et al.                 Informational                      [Page 3]

RFC 2713                Schema for Java Objects             October 1999


   When an object is serialized, information that identifies its class
   is recorded in the serialized stream. However, the class's definition
   ("class file") itself is not recorded. It is the responsibility of
   the system that is deserializing the object to determine the
   mechanism to use for locating and loading the associated class
   definitions. For example, the Java application might include in its
   classpath a JAR file containing the class definitions of the
   serialized object, or load the class definitions using information
   from the directory, as explained below.

2.2.1 Representation in the Directory

   A serialized object is represented in the directory by the attributes
   javaClassName, javaClassNames, javaCodebase, and javaSerializedData,
   as defined in Section 3.  The mandatory attribute,
   javaSerializedData, contains the serialized form of the object.
   Although the serialized form already contains the class name, the
   mandatory javaClassName attribute also records the class name of the
   serialized object so that applications can determined class
   information without having to first deserialize the object.  The
   optional javaClassNames attribute is used to record additional class
   information about the serialized object.  The optional javaCodebase
   attribute is used to record the locations of the class definitions
   needed to deserialize the serialized object.

   A directory entry that contains a serialized object is represented by
   the object class javaSerializedObject, which is a subclass of
   javaObject.  javaSerializedObject is an auxiliary object class, which
   means that it needs to be mixed in with a structural object class.
   javaSerializedObject's definition is given in Section 4.

2.3 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 marshalling
   also records codebases. Marshalling is different from serialization
   in that marshalling treats remote objects specially. If an object is
   a java.rmi.Remote object, marshalling records the remote object's
   "stub" (see Section 2.5), instead of the remote object itself.  Like
   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.





Ryan, et al.                 Informational                      [Page 4]

RFC 2713                Schema for Java Objects             October 1999


   A "marshalled" object is the represented by the
   java.rmi.MarshalledObject class. Here's an example of how to create
   MarshalledObjects for serializable and remote objects:

       java.io.Serializable sobj = ...;
       java.rmi.MarshalledObject mobj1 =
           new java.rmi.MarshalledObject(sobj);

       java.rmi.Remote robj = ...;
       java.rmi.MarshalledObject mobj2 =
           new java.rmi.MarshalledObject(robj);

   Then, to retrieve the original objects from the MarshalledObjects, do
   as follows:

       java.io.Serializable sobj = (java.io.Serializable) mobj1.get();
       java.io.Remote rstub = (java.io.Remote) mobj2.get();

   MarshalledObject is available only on the Java 2 Platform, Standard
   Edition, v1.2, and higher releases.

2.3.1 Representation in the Directory

   A marshalled object is represented in the directory by the attributes
   javaClassName, javaClassNames, and javaSerializedData, as defined in
   Section 3.  The mandatory attribute, javaSerializedData, contains the
   serialized form of the marshalled object (that is, the serialized
   form of a MarshalledObject instance).  The mandatory javaClassName
   attribute records the distinguished class name of the object before
   it has been marshalled.  The optional javaClassNames attribute is
   used to record additional class information about the object before
   it has been marshalled.

   A directory entry that contains a marshalled object is represented by
   the object class javaMarshalledObject, which is a subclass of
   javaObject.  javaMarshalledObject is an auxiliary object class, which
   means that it needs to be mixed in with a structural object class.
   javaMarshalledObject's definition is given in Section 4.

   As evident in this description, a javaMarshalledObject differs from a
   javaSerializedObject only in the interpretation of the javaClassName
   and javaClassNames attributes.









Ryan, et al.                 Informational                      [Page 5]

RFC 2713                Schema for Java Objects             October 1999


2.4 JNDI References

   Java Naming and Directory Interface(tm) (JNDI) is a directory access
   API specified in the Java programming language [JNDI].  It provides
   an object-oriented view of the directory, allowing Java objects to be
   added to and retrieved from the directory without requiring the
   client to manage data representation issues.

   JNDI defines the notion of a "reference" for use when an object
   cannot be stored in the directory directly, or when it is
   inappropriate or undesirable to do so.  An object with an associated
   reference is stored in the directory indirectly, by storing its
   reference instead.

2.4.1 Contents of a Reference

   A JNDI reference is a Java object of class javax.naming.Reference.
   It consists of class information about the object being referenced
   and an ordered list of addresses.  An address is a Java object of
   class javax.naming.RefAddr.  Each address contains information on how
   to construct the object.

   A common use for JNDI references is to represent connections to a
   network service such as a database, directory, or file system.  Each
   address may then identify a "communications endpoint" for that
   service, containing information on how to contact the service.
   Multiple addresses may arise for various reasons, such as replication
   or the object offering interfaces over more than one communication
   mechanism.

   A reference also contains information to assist in the creation of an
   instance of the object to which the reference refers.  It contains
   the Java class name of that object, and the class name and location
   of the object factory to be used to create the object.  The
   procedures for creating an object given its reference and the reverse
   are described in [JNDI].

2.4.2 Representation in the Directory

   A JNDI reference is stored in the directory by using the attributes
   javaClassName, javaClassNames, javaCodebase, javaReferenceAddress,
   and javaFactory, defined in Section 3.  These attributes store
   information corresponding to the contents of a reference described
   above.  javaReferenceAddress is a multivalued optional attribute for
   storing reference addresses.  javaFactory is the optional attribute
   for storing the object factory's fully qualified class name.  The
   mandatory javaClassName attribute is used to store the name of the
   distinguished class of the object.  The optional javaClassNames



Ryan, et al.                 Informational                      [Page 6]

RFC 2713                Schema for Java Objects             October 1999


   attribute is used to record additional class and interface names.
   The optional javaCodebase attribute is used to store the locations of
   the object factory's and the object's class definitions.

   A directory entry containing a JNDI reference is represented by the
   object class javaNamingReference, which is a subclass of javaObject.
   javaNamingReference is an auxiliary object class, which means that it
   needs to be mixed in with a structural object class.
   javaNamingReference's definition is given in Section 4.

2.5 Remote Objects

   The Java Remote Method Invocation (RMI) system [RMI] is a mechanism
   that enables an object on one Java virtual machine to invoke methods
   on an object in another Java virtual machine. Any object whose
   methods can be invoked in this way must implement the java.rmi.Remote
   interface.  When such an object is invoked, its arguments are
   marshalled and sent from the local virtual machine to the remote one,
   where the arguments are unmarshalled and used.  When the method
   terminates, the results are marshalled from the remote machine and
   sent to the caller's virtual machine.

   To make a remote object accessible to other virtual machines, a
   program typically registers it with the RMI registry.  The program
   supplies to the RMI registry the string name of the remote object and
   the remote object itself.  When a program wants to access a remote
   object, it supplies the object's string name to the RMI registry on
   the same machine as the remote object.  The RMI registry returns to
   the caller a reference (called "stub") to the remote object.  When
   the program receives the stub for the remote object, it can invoke
   methods on the remote object (through the stub).  A program can also
   obtain references to remote objects as a result of remote calls to
   other remote objects or from other naming services.  For example, the
   program can look up a reference to a remote object from an LDAP
   server that supports the schema defined in this document.

   The string name accepted by the RMI registry has the syntax
   "rmi://hostname:port/remoteObjectName", where "hostname" and "port"
   identify the machine and port on which the RMI registry is running,
   respectively, and "remoteObjectName" is the string name of the remote
   object.  "hostname", "port", and the prefix, "rmi:", are optional. If
   "hostname" is not specified, it defaults to the local host.  If
   "port" is not specified, it defaults to 1099.  If "remoteObjectName"
   is not specified, then the object being named is the RMI registry
   itself.  See [RMI] for details.






Ryan, et al.                 Informational                      [Page 7]