RFC2713 日本語訳
2713 Schema for Representing Java(tm) Objects in an LDAP Directory. V.Ryan, S. Seligman, R. Lee. October 1999. (Format: TXT=40745 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group V. Ryan
Request for Comments: 2713 S. Seligman
Category: Informational R. Lee
Sun Microsystems, Inc.
October 1999
コメントを求めるワーキンググループV.ライアン要求をネットワークでつないでください: 2713秒間セリグマンCategory: 情報のR.リーサン・マイクロシステムズ・インク1999年10月
Schema for Representing Java(tm) Objects in an LDAP Directory
LDAPディレクトリでJava(tm)オブジェクトを表すための図式
Status of this Memo
この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.
Copyright(C)インターネット協会(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].
このドキュメントは、LDAPディレクトリ[LDAPv3]にJava(tm)オブジェクトを表すために図式を定義します。 それは、Javaの連載されたオブジェクト[連続の]、Javaの整理されたオブジェクト[RMI]、Javaリモート・オブジェクト[RMI]、およびJNDI参照[JNDI]を表すために図式要素を定義します。
1. Introduction
1. 序論
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.
このドキュメントは、読者にはJavaプログラミング言語[Java]に関する一般知識があると仮定します。 簡潔さのために、私たちは本稿中の「Javaプログラミング言語によるオブジェクト」に代わって「Javaオブジェクト」という用語を使用します。
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".
伝統的に、LDAPディレクトリは、データを保存するのに使用されました。 それぞれ1セットの属性を含んで、ユーザとプログラマはディレクトリエントリーの階層構造としてディレクトリを考えます。 あなたは、ディレクトリからエントリーを見上げて、興味がある属性を抽出します。 例えば、あなたはディレクトリから人の電話番号を調べることができます。 あるいはまた、あなたは特定のセットの属性でエントリーのためのディレクトリを捜すことができます。 例えば、あなたは「スミス」という姓があるディレクトリのすべての人々を捜し求めることができます。
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.
Javaプログラミング言語で書かれたアプリケーションのために、通常共有される一種のデータがJavaオブジェクト自体です。 そのようなアプリケーションのために、それはJavaオブジェクトに倉庫としてディレクトリを使用できる意味になります。 ディレクトリはネットワークの向こう側に配布されたJavaアプリケーションで使用のための中心で管理されて、ことによると模写されたサービスを提供します。
Ryan, et al. Informational [Page 1] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[1ページ]のRFC2713図式
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.
このドキュメントに関する動機はアプリケーションがディレクトリからJavaオブジェクトを保存して、検索する一般的な方法を定義することです。 この一般的な図式を使用して、ディレクトリにJavaオブジェクトを読むか、または保存する必要があるどんなJavaアプリケーションも、そう共同利用できる方法でできます。
2 Representation of Java Objects
2 Javaオブジェクトの表現
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.
このドキュメントは3つのタイプのJavaオブジェクトを表すために図式要素を定義します: Javaはオブジェクト、Javaの整理されたオブジェクト、およびJNDI参照を連載しました。 Javaリモート・オブジェクトはJavaの整理されたオブジェクトかJNDI参照のどちらかとして保存されます。
2.1 Common Representations
2.1 一般的な表現
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.
Javaオブジェクトは、LDAPディレクトリにオブジェクトのクラスjavaObjectを使用することによって、保存されます。 これは関連するクラスがそれの他のJavaオブジェクトから以下を引き出す基底クラスです。 javaSerializedObject、javaMarshalledObject、およびjavaNamingReference. javaObjectは抽象的なオブジェクトのクラスです。(それは、javaObjectがディレクトリでそれ自体を生きさせることができないことを意味します)。 それの補助の、または、構造的なサブクラスしかディレクトリに存在できません。
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.
オブジェクトのクラスjavaContainerはJavaオブジェクトを保存するのに捧げられたディレクトリエントリを表します。 それは構造的なオブジェクトのクラスです。 javaObjectのサブクラスがもう1人の構造的なオブジェクトのクラスに複雑である場合では、javaContainerは必要ではありません。
The definitions for the object classes javaObject and javaContainer are presented in Section 4.
オブジェクトのクラスのjavaObjectとjavaContainerのための定義はセクション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.
javaObjectのクラスには、1つの義務的な属性(javaClassName)と4つの任意の属性(javaClassNames、javaCodebase、javaDoc、記述)があります。javaClassNameはオブジェクトのJavaのクラス(例えば、"java.lang.String")の完全に修飾された名前を保存するのに使用されるただ一つの評価された属性です。 これは大部分が命名しますが、sが持っていないクラスのものを引き出したオブジェクトのものであるかもしれません。 いくつかの場合、「スーパー-クラス」かインタフェースのものは最も適切であるかもしれません。 この属性はオブジェクトが同一視されるべきであるすなわち、オブジェクトの「顕著な」クラス、クラスの名前を保存するか、インタフェースに意図します。
Ryan, et al. Informational [Page 2] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[2ページ]のRFC2713図式
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.
javaClassNamesはオブジェクトのJavaのクラスとインタフェース(例えば、"java.lang.Byte")の完全に修飾された名前を保存するのに使用される多値の属性です。 すべての多値の属性のように、javaClassNames属性の値が順不同のである、いいえ1、値は他のものより「顕著です」。 この属性はその先祖のクラスとインタフェースのオブジェクトのクラス、インタフェース名、およびものを保存するために意図します、値のリストは完全である必要はありませんが。 javaClassNames属性が存在しているなら、それは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.
例えば、オブジェクトが"java.io.FilePermission"のjavaClassName属性、および"java.security.Permission"、"java.io.FilePermission"、"java.security.Guard""java.io.Serializable"のjavaClassNames属性があるディレクトリに保存されると仮定してください。 Javaオブジェクトのためのディレクトリを捜すアプリケーションは、そのディレクトリのJavaオブジェクトの名前とタイプの概要を製作するのにjavaClassNameを使用するかもしれません。 別のアプリケーションは見つけるjavaClassNames属性を使用するかもしれません、例えば、すべてのjava.security.Permissionが反対します。
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.
javaCodebaseはオブジェクトのクラス定義の位置を保存するのに使用される多値の属性です。javaDocは、クラスのために指針(URL)をJavaドキュメンテーションとして保存するのに使用されます。記述は、Javaオブジェクトの原文の記述を保存するのに使用されて、[v3Schema]で定義されます。 これらの属性の定義はセクション3に提示されます。
2.2 Serialized Objects
2.2 連載されたオブジェクト
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.
オブジェクトを「連載すること」は、オブジェクトのコピーにバイト・ストリームを変換し返すことができるような方法で状態をバイト・ストリームに変換することを意味します。 クラスか「スーパー-クラス」のどれかがjava.io.Serializableインタフェースかそのsubinterface java.io.Externalizableのどちらかを実装するなら、Javaオブジェクトは「直列化可能」です。 「デシリアライゼーション」はオブジェクトの連載されたフォームをオブジェクトのコピーに変換して戻すプロセスです。 また、オブジェクトが連載されるとき、オブジェクトに根づいているオブジェクトの全体の木は連載されます。 それがデシリアライズされるとき、木は再建されます。 例えば、直列化可能Bookオブジェクトが含むと仮定してください、(直列化可能分野、)、ページオブジェクトの配列。 Bookオブジェクトが連載されるとき、ページオブジェクトの配列もそうです。
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.
Javaプラットホームは直列化可能オブジェクトが連載されるデフォルトアルゴリズムを指定します。 また、Javaのクラスはそれ自身のアルゴリズムでこのデフォルト連載をくつがえすことができます。 [シリーズ]は詳細にオブジェクト連載について説明します。
Ryan, et al. Informational [Page 3] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[3ページ]のRFC2713図式
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.
オブジェクトが連載されるとき、クラスを特定する情報が連載されたストリームに記録されます。 しかしながら、クラスsの定義(「クラスファイル」)自体は記録されていません。 それはメカニズムが関連クラス定義を場所を見つけて、ロードするのに使用することを決定するオブジェクトをデシリアライズしているシステムの責任です。 例えば、Javaアプリケーションがclasspathに連載されたオブジェクトのクラス定義を含むJARファイルを含むかもしれませんか、またはディレクトリからの情報を使用することでクラス定義をロードしてください、以下で説明されるように。
2.2.1 Representation in the Directory
2.2.1 ディレクトリにおける表現
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.
連載されたオブジェクトは属性のjavaClassName、javaClassNames、javaCodebase、およびjavaSerializedDataによるディレクトリに表されます、セクション3で定義されるように。 義務的な属性(javaSerializedData)はオブジェクトの連載されたフォームを含んでいます。 連載されたフォームは既にクラス名を含んでいますが、また、義務的なjavaClassName属性は、アプリケーションは決定しているクラス情報を最初にオブジェクトをデシリアライズする必要はなくて記録できるように連載されたオブジェクトのクラス名を記録します。 任意のjavaClassNames属性は、連載されたオブジェクトの追加クラス情報を記録するのに使用されます。 任意のjavaCodebase属性は、連載されたオブジェクトをデシリアライズするのに必要であるクラス定義の位置を記録するのに使用されます。
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.
連載されたオブジェクトを含むディレクトリエントリはオブジェクトのクラスjavaSerializedObjectによって表されて、どれがjavaObject. javaSerializedObjectのサブクラスであるかは補助のオブジェクトのクラスです。(それは、構造的なオブジェクトのクラスに混入されるのが必要であることを意味します)。セクション4でjavaSerializedObjectの定義を与えます。
2.3 Marshalled Objects
2.3 整理されたオブジェクト
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.
オブジェクトを「整理すること」は、整理されたオブジェクトが"非整理"であることのときに、謄本オブジェクトを入手するような方法でその状態とcodebase(s)を記録することを意味します、ことによると自動的にオブジェクトのクラス定義をロードすることによって。 あなたはどんな直列化可能の、または、リモートな(すなわち、java.rmi.Remoteインタフェースを実装します)オブジェクトも整列させることができます。 また、連載、記録codebasesを整理するのを除いて、整理があります。 整理は連載と特に、整理がリモート・オブジェクトを扱うという点において異なっています。 オブジェクトがjava.rmi.Remoteオブジェクトであるなら、整理はリモート・オブジェクトの「スタッブ」を記録します(セクション2.5を見てください)、リモート・オブジェクト自体の代わりに。 オブジェクトが整理されるときの連載のように、オブジェクトに根づいているオブジェクトの全体の木は整理されます。 それが非整理されるとき、木は再建されます。
Ryan, et al. Informational [Page 4] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[4ページ]のRFC2713図式
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.rmi.MarshalledObjectのクラスで表すことでした。 ここに、どう直列化可能とリモート・オブジェクトのためのMarshalledObjectsを作成するかに関する例があります:
java.io.Serializable sobj = ...;
java.rmi.MarshalledObject mobj1 =
new java.rmi.MarshalledObject(sobj);
java.io.Serializable sobj=…; java.rmi.MarshalledObject mobj1は新しいjava.rmi.MarshalledObject(sobj)と等しいです。
java.rmi.Remote robj = ...;
java.rmi.MarshalledObject mobj2 =
new java.rmi.MarshalledObject(robj);
java.rmi.Remote robj=…; java.rmi.MarshalledObject mobj2は新しいjava.rmi.MarshalledObject(robj)と等しいです。
Then, to retrieve the original objects from the MarshalledObjects, do as follows:
そして、以下の通り以下をして、MarshalledObjectsからオリジナルのオブジェクトを検索してください。
java.io.Serializable sobj = (java.io.Serializable) mobj1.get();
java.io.Remote rstub = (java.io.Remote) mobj2.get();
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.
MarshalledObjectは単にJava 2Platform、スタンダードエディション、v1.2、および、より高いリリースのときに利用可能です。
2.3.1 Representation in the Directory
2.3.1 ディレクトリにおける表現
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.
整理されたオブジェクトはセクション3で定義されるように属性のjavaClassName、javaClassNames、およびjavaSerializedDataによるディレクトリに表されます。 義務的な属性(javaSerializedData)は整理されたオブジェクト(すなわち、MarshalledObjectインスタンスの連載されたフォーム)の連載されたフォームを含んでいます。 それが整理される前に義務的なjavaClassName属性はオブジェクトの顕著なクラス名を記録します。 任意のjavaClassNames属性は、それが整理される前にオブジェクトの追加クラス情報を記録するのに使用されます。
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.
整理されたオブジェクトを含むディレクトリエントリはオブジェクトのクラスjavaMarshalledObjectによって表されて、どれがjavaObject. javaMarshalledObjectのサブクラスであるかは補助のオブジェクトのクラスです。(それは、構造的なオブジェクトのクラスに混入されるのが必要であることを意味します)。セクション4でjavaMarshalledObjectの定義を与えます。
As evident in this description, a javaMarshalledObject differs from a javaSerializedObject only in the interpretation of the javaClassName and javaClassNames attributes.
この記述で明白であるとして、javaMarshalledObjectはjavaClassNameとjavaClassNames属性の解釈だけにおいてjavaSerializedObjectと異なっています。
Ryan, et al. Informational [Page 5] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[5ページ]のRFC2713図式
2.4 JNDI References
2.4 JNDI参照
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.
Java NamingとディレクトリInterface(tm)(JNDI)はJavaプログラミング言語[JNDI]で指定されたディレクトリアクセスAPIです。 それはディレクトリのオブジェクト指向意見を提供します、Javaオブジェクトはデータ表現問題を加えられて、クライアントが管理するのが必要であることのないディレクトリから検索されるのを許容して。
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.
そうするのがディレクトリに直接オブジェクトを保存できないか、不適当であるか、または望ましくないときに、JNDIは使用の「参照」の概念を定義します。 関連参照があるオブジェクトは、ディレクトリに代わりに参照を保存することによって、間接的に保存されます。
2.4.1 Contents of a Reference
2.4.1 参照のコンテンツ
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.
JNDI参照はクラスjavax.naming.ReferenceのJavaオブジェクトです。 それはオブジェクトの参照をつけられたクラス情報と規則正しい住所録から成ります。 アドレスはクラスjavax.naming.RefAddrのJavaオブジェクトです。 各アドレスはどうオブジェクトを組み立てるかの情報を含んでいます。
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.
JNDI参照の一般の使用はデータベース、ディレクトリ、またはファイルシステムなどのネットワーク・サービスに接続の代理をすることです。 そして、どうサービスに連絡するかの情報を含んでいて、各アドレスはそのサービスのために「コミュニケーション終点」を特定するかもしれません。 複数のアドレスが様々な理由で起こるかもしれません、1つ以上のコミュニケーションメカニズムの上にインタフェースを提供する模写やオブジェクトのように。
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].
また、参照は参照が参照されるオブジェクトのインスタンスの作成を助ける情報を含んでいます。 それはオブジェクトを作成するのに使用されるべきオブジェクト工場のそのオブジェクトのJavaクラス名、クラス名、および位置を含んでいます。 参照と逆を考えて、オブジェクトを作成するための手順は[JNDI]で説明されます。
2.4.2 Representation in the Directory
2.4.2 ディレクトリにおける表現
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
JNDI参照は、ディレクトリにjavaClassName、javaClassNames、javaCodebase、javaReferenceAddress、およびjavaFactoryがセクション3で定義した属性を使用することによって、保存されます。 これらの属性は上で説明された参照のコンテンツに対応する情報を保存します。javaReferenceAddressは、基準アドレスを保存するための多値の任意の属性です。javaFactoryは、オブジェクト工場の完全に適切なクラス名を保存するための任意の属性です。 義務的なjavaClassName属性は、オブジェクトの顕著なクラスの名前を保存するのに使用されます。 任意のjavaClassNames
Ryan, et al. Informational [Page 6] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[6ページ]のRFC2713図式
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.
属性は、追加クラスとインタフェース名を記録するのに使用されます。 任意のjavaCodebase属性は、オブジェクト工場とオブジェクトのクラス定義の位置を保存するのに使用されます。
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.
JNDI参照を含むディレクトリエントリはオブジェクトのクラスjavaNamingReferenceによって表されて、どれがjavaObject. javaNamingReferenceのサブクラスであるかは補助のオブジェクトのクラスです。(それは、構造的なオブジェクトのクラスに混入されるのが必要であることを意味します)。セクション4でjavaNamingReferenceの定義を与えます。
2.5 Remote Objects
2.5 リモート・オブジェクト
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.
Java Remote Method Invocation(RMI)システム[RMI]は1つのJava仮想マシンのオブジェクトがオブジェクトの上に別のJava仮想マシンでメソッドを呼び出すのを可能にするメカニズムです。 このようにメソッドを呼び出すことができるどんなオブジェクトもjava.rmi.Remoteインタフェースを実装しなければなりません。 そのようなオブジェクトを呼び出すとき、地方の仮想計算機からリモートものに議論を整理して、送ります、議論が非整理されて、使用されるところで。 メソッドが終わるとき、結果をリモートマシンから整理して、訪問者の仮想計算機に送ります。
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.
リモート・オブジェクトを他の仮想計算機にアクセスしやすくするように、プログラムはRMI登録にそれを通常登録します。 プログラムはリモート・オブジェクトとリモート・オブジェクト自体のストリング名前をRMI登録に提供します。 プログラムがリモート・オブジェクトにアクセスしたがっているとき、それはリモート・オブジェクトと同じマシンの上のRMI登録にオブジェクトのストリング名を供給します。 RMI登録はリモート・オブジェクトの参照(「スタッブ」と呼ばれる)を訪問者に返します。 プログラムがリモート・オブジェクトのためにスタッブを受けるとき、それはリモート・オブジェクト(スタッブを通した)にメソッドを呼び出すことができます。 また、プログラムは他のリモート・オブジェクトか他の名前付けサービスからのリモート呼び出しの結果、リモート・オブジェクトの参照を得ることができます。 例えば、プログラムは本書では定義された図式をサポートするLDAPサーバからリモート・オブジェクトの参照を調べることができます。
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.
RMI登録によって受け入れられたストリング名は構文「rmi://ホスト名: ポート/remoteObjectName」を持っています。そこでは、「ホスト名」と「ポート」がRMI登録がそれぞれ稼働する予定であり、"remoteObjectName"がリモート・オブジェクトのストリング名であるマシンとポートを特定します。 「ホスト名」、「ポート」、および接頭語は、「以下をrmiし」て、任意です。 「ホスト名」が指定されないなら、それはローカル・ホストをデフォルトとします。 「ポート」が指定されないなら、それは1099をデフォルトとします。 "remoteObjectName"が指定されないなら、命名されるオブジェクトはRMI登録自体です。 詳細に関して[RMI]を見てください。
Ryan, et al. Informational [Page 7] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[7ページ]のRFC2713図式
RMI can be supported using different protocols: the Java Remote Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP). The JRMP is a specialized protocol designed for RMI; the IIOP is the standard protocol for communication between CORBA objects [CORBA]. RMI over IIOP allows Java remote objects to communicate with CORBA objects which might be written in a non-Java programming language [RMI-IIOP].
異なったプロトコルを使用することでRMIをサポートすることができます: Javaのリモートメソッドプロトコル(JRMP)とインターネット相互球は(IIOP)について議定書の中で述べます。 JRMPはRMIのために設計された専門化しているプロトコルです。 IIOPはCORBAオブジェクト[CORBA]のコミュニケーションのための標準プロトコルです。 IIOPの上のRMIは非Javaプログラミング言語[RMI-IIOP]でどれが書かれているかもしれないかをCORBAオブジェクトとJavaリモート・オブジェクトを伝えさせます。
2.5.1 Representation in the Directory
2.5.1 ディレクトリにおける表現
Remote objects that use the IIOP are represented in the directory as CORBA object references [CORBA-LDAP]. Remote objects that use the JRMP are represented in the directory in one of two ways: as a marshalled object, or as a JNDI reference.
IIOPを使用するリモート・オブジェクトがCORBAオブジェクト参照[CORBA-LDAP]としてディレクトリに表されます。 JRMPを使用するリモート・オブジェクトがディレクトリに2つの方法の1つで表されます: 整理されたオブジェクトとして、または、JNDI参照として。
A marshalled object records the codebases of the remote object's stub and any serializable or remote objects that it references, and replaces remote objects with their stubs. To store a Remote object as a marshalled object (java.rmi.MarshalledObject), you first create a java.rmi.MarshalledObject instance for it.
整理されたオブジェクトは、それが参照をつけるどんなリモート・オブジェクトのスタッブのcodebasesと直列化可能やリモート・オブジェクトも記録して、リモート・オブジェクトを彼らのスタッブに取り替えます。 整理されたオブジェクト(java.rmi.MarshalledObject)としてRemoteオブジェクトを保存するために、あなたは最初に、それのためにjava.rmi.MarshalledObjectインスタンスを作成します。
java.rmi.Remote robj = ...;
java.rmi.MarshalledObject mobj =
new java.rmi.MarshalledObject(robj);
java.rmi.Remote robj=…; java.rmi.MarshalledObject mobjは新しいjava.rmi.MarshalledObject(robj)と等しいです。
You can then store the MarshalledObject instance as a javaMarshalledObject. The javaClassName attribute should contain the fully qualified name of the distinguished class of the remote object. The javaClassNames attribute should contain the names of the classes and interfaces of the remote object. To read the remote object back from the directory, first deserialize the contents of the javaSerializedData to get a MarshalledObject (mobj), then retrieve it from the MarshalledObject as follows:
そして、あなたはjavaMarshalledObjectとしてMarshalledObjectインスタンスを保存できます。 javaClassName属性はリモート・オブジェクトの顕著なクラスの完全に修飾された名前を含むべきです。 javaClassNames属性はクラスの名前とリモート・オブジェクトのインタフェースを含むべきです。 ディレクトリからリモート・オブジェクトを読み返すために、最初に、javaSerializedDataのコンテンツをデシリアライズして、MarshalledObject(mobj)を手に入れてくださいといって、次に、以下のMarshalledObjectからそれを検索してください:
java.rmi.Remote robj = (java.rmi.Remote)mobj.get();
java.rmi.Remote robjは(java.rmi.Remote)mobj.get()と等しいです。
This returns the remote stub, which you can then use to invoke remote methods.
これはリモートスタッブを返します。(次に、あなたは、リモートメソッドを呼び出すのにそれを使用できます)。
MarshalledObject is available only on the Java 2 Platform, Standard Edition, v1.2 and higher releases. Therefore, a remote object stored as a MarshalledObject can only be read by clients using the the Java 2 Platform, Standard Edition, v1.2 or higher releases.
MarshalledObjectは単にJava 2Platform、スタンダードエディション、v1.2、および、より高いリリースのときに利用可能です。 したがって、クライアントは、Java 2Platform、スタンダードエディション、v1.2または、より高いリリースを使用することでMarshalledObjectとして保存されたリモート・オブジェクトを読むことができるだけです。
Ryan, et al. Informational [Page 8] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[8ページ]のRFC2713図式
To store a remote object as a JNDI reference, you first create a javax.naming.Reference object instance for it using the remote object's string name as it has been, or will be, recorded with the RMI registry, with the additional restriction that the "rmi:" prefix must be present. Here's an example:
JNDI参照、あなた1第人がjavax.naming.Referenceオブジェクトインスタンスを作成するときそれのためにリモート・オブジェクトのストリングを使用することでリモート・オブジェクトを保存するために、あるか、またはあるために望んでいて、RMI登録で記録した追加で制限をそれと命名してください、「rmi:」 接頭語は存在していなければなりません。 ここに、例があります:
javax.naming.Reference ref = new javax.naming.Reference(
obj.getClass().getName(),
new javax.naming.StringRefAddr("URL",
"rmi://rserver/AppRemoteObjectX"));
javax.naming.Reference審判は新しいjavax.naming.Reference(obj.getClass().getName()、新しいjavax.naming.StringRefAddr(「URL」、「rmi://rserver/AppRemoteObjectX」))と等しいです。
You then store the javax.naming.Reference instance as a javaNamingReference. The advantage of using a JNDI reference is that this can be done without a reference to the remote object. In fact, the remote object does not have to exist at the time that this recording in the directory is made. The remote object needs to exist and be bound with the RMI registry when the object is looked up from the directory.
そして、あなたはjavaNamingReferenceとしてjavax.naming.Referenceインスタンスを保存します。 JNDI参照を使用する利点はリモート・オブジェクトの参照なしでこれができるということです。 事実上、リモート・オブジェクトはディレクトリにおけるこの録音をする時に存在する必要はありません。 リモート・オブジェクトは存在して、オブジェクトがディレクトリから見上げられるときRMI登録で制限されている必要があります。
2.6 Serialized Objects Vs. Marshalled Objects Vs. References
2.6はオブジェクトを連載しました。 オブジェクトを整理します。 参照
The object classes defined in this document store different aspects of the Java objects.
本書では定義されたオブジェクトのクラスはJavaオブジェクトの異なった局面を保存します。
A javaSerializedObject or a serializable object stored as a javaMarshalledObject represents the object itself, while a javaNamingReference or a remote object stored as a javaMarshalledObject represents a "pointer" to the object.
javaMarshalledObjectとして保存されたjavaSerializedObjectか直列化可能オブジェクトがオブジェクトと称します、javaMarshalledObjectとして保存されたjavaNamingReferenceかリモート・オブジェクトが「指針」をオブジェクトに表しますが。
When storing a serializable object in the directory, you have a choice of storing it as a javaSerializedObject or a javaMarshalledObject. The javaSerializedObject object class provides the basic way in which to store serializable objects. When you create an LDAP entry using the javaSerializableObject object class, you must explicitly set the javaCodebase attribute if you want readers of that entry to know where to load the class definitions of the object. When you create an LDAP entry using the javaMarshalledObject object class, you use the MarshalledObject class. The MarshalledObject class uses the RMI infrastructure available on the Java platform to automate how codebase information is gathered and recorded, thus freeing you from having to set the javaCodebase attribute. On the other hand, the javaCodebase attribute is human-readable and can be updated easily by using text-based tools without having to change other parts of the entry. This allows you, for instance, to move the class definitions to another location and then update the javaCodebase attribute to reflect the move without having to update the serialized object itself.
ディレクトリに直列化可能オブジェクトを保存するとき、あなたには、javaSerializedObjectかjavaMarshalledObjectとしてそれを保存することの選択があります。 javaSerializedObjectオブジェクトのクラスは直列化可能オブジェクトを保存する基本的な方法を提供します。 javaSerializableObjectオブジェクトのクラスを使用することでLDAPエントリーを作成するとき、そのエントリーの読者に、どこでオブジェクトのクラス定義をロードするかを知って欲しいなら、あなたは明らかにjavaCodebase属性を設定しなければなりません。 javaMarshalledObjectオブジェクトのクラスを使用することでLDAPエントリーを作成するとき、あなたはMarshalledObjectのクラスを使用します。 MarshalledObjectのクラスはcodebase情報がどう集められて、記録されるかを自動化するのにJavaプラットホームで利用可能なRMIインフラストラクチャを使用します、その結果、javaCodebase属性を設定しなければならないのからあなたを解放します。 他方では、javaCodebase属性を人間読み込み可能であり、エントリーの他の部品を変える必要はなくてテキストベースのツールを使用することによって、容易にアップデートできます。 例えば、これは、連載されたオブジェクト自体をアップデートする必要はなくて移動を反映するためにクラス定義をもう1つの位置に動かして、次に、javaCodebase属性をアップデートするためにあなたを許容します。
Ryan, et al. Informational [Page 9] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[9ページ]のRFC2713図式
A javaNamingReference provides a way of recording address information about an object which itself is not directly stored in the directory. A remote object stored as a javaMarshalledObject also records address information (the object's "stub") of an object which itself is not directory stored in the directory. In other words, you can think of these as compact representations of the information required to access the object.
javaNamingReferenceはディレクトリにそれ自体で直接保存されないオブジェクトに関するアドレス情報を記録する方法に提供します。 リモート・オブジェクトはjavaMarshalledObjectとしてもそれ自体でディレクトリに保存されたディレクトリでないオブジェクトに関する記録アドレス情報(オブジェクトの「スタッブ」)を保存しました。 言い換えれば、あなたは、情報の表現がオブジェクトにアクセスするのが必要であるとコンパクトであるとしてのこれらが考えることができます。
A javaNamingReference typically consists of a small number of human- readable strings. Standard text-based tools for directory administration may therefore be used to add, read, or modify reference entries -- if so desired -- quite easily. Serialized and marshalled objects are not intended to be read or manipulated directly by humans.
javaNamingReferenceは少ない数の人間の読み込み可能なストリングから通常成ります。 したがって、ディレクトリ管理のための標準のテキストベースのツールが加えるのに使用されるかもしれませんか、読むか、またはそう望まれているなら、全く容易に参照エントリーを変更してください。 連載されて整理されたオブジェクトは直接人間によって読まれるか、または操られることを意図しません。
3 Attribute Type Definitions
3 属性型定義
The following attribute types are defined in this document:
以下の属性タイプは本書では定義されます:
javaClassName
javaClassNames
javaCodebase
javaSerializedData
javaFactory
javaReferenceAddress
javaDoc
javaClassName javaClassNames javaCodebase javaSerializedData javaFactory javaReferenceAddress javaDoc
3.1 javaClassName
3.1 javaClassName
This attribute stores the fully qualified name of the Java object's "distinguished" class or interface (for example, "java.lang.String"). It is a single-valued attribute. This attribute's syntax is ' Directory String' and its case is significant.
この属性はJavaオブジェクトの「顕著な」クラスかインタフェース(例えば、"java.lang.String")の完全に修飾された名前を保存します。 それは単一に評価された属性です。 この属性の構文は'ディレクトリString'です、そして、ケースは重要です。
( 1.3.6.1.4.1.42.2.27.4.1.6
NAME 'javaClassName'
DESC 'Fully qualified name of distinguished Java class or
interface'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
(1.3.6.1.4.1.42.2.27.4.1.6NAME'javaClassName'DESC'顕著なJavaのクラスかインタフェースの完全に修飾された名前'EQUALITY caseExactMatch SYNTAX1.3.6.1.4.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
Ryan, et al. Informational [Page 10] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[10ページ]のRFC2713図式
3.2 javaCodebase
3.2 javaCodebase
This attribute stores the Java class definition's locations. It specifies the locations from which to load the class definition for the class specified by the javaClassName attribute. Each value of the attribute contains an ordered list of URLs, separated by spaces. For example, a value of "url1 url2 url3" means that the three (possibly interdependent) URLs (url1, url2, and url3) form the codebase for loading in the Java class definition.
この属性はJavaクラス定義の位置を保存します。 それはjavaClassName属性によって指定されたクラスのためにクラス定義をロードする位置を指定します。 属性の各値は空間によって切り離されたURLの規則正しいリストを含んでいます。 例えば、「url1 url2 url3"は、3つの(ことによると互いに依存しる)のURL(url1、url2、およびurl3)がJavaクラス定義でロードするためにcodebaseを形成することを意味する」値。
If the javaCodebase attribute contains more than one value, each value is an independent codebase. That is, there is no relationship between the URLs in one value and those in another; each value can be viewed as an alternate source for loading the Java class definition. See [Java] for information regarding class loading.
javaCodebase属性が1つ以上の値を含んでいるなら、各値は独立しているcodebaseです。 すなわち、1つの値におけるURLと別のもののそれらとの関係が全くありません。 Javaクラス定義をロードするための代替のソースとして各値を見なすことができます。 クラス荷重の情報に関して[Java]を見てください。
This attribute's syntax is 'IA5 String' and its case is significant.
この属性の構文は'IA5 String'です、そして、ケースは重要です。
( 1.3.6.1.4.1.42.2.27.4.1.7
NAME 'javaCodebase'
DESC 'URL(s) specifying the location of class definition'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)
(1.3.6.1.4.1.42.2.27.4.1.7NAME'クラス定義の位置を指定するjavaCodebase'DESC'URL'EQUALITY caseExactIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26)
3.3 javaClassNames
3.3 javaClassNames
This attribute stores the Java object's fully qualified class or interface names (for example, "java.lang.String"). It is a multivalued attribute. When more than one value is present, each is the name of a class or interface, or ancestor class or interface, of this object.
この属性はJavaオブジェクトの完全に適切なクラスかインタフェース名(例えば、"java.lang.String")を保存します。 それは多値の属性です。 1つ以上の値が存在しているとき、それぞれが、このオブジェクトのクラスかインタフェースの名前、先祖のクラスまたはインタフェースです。
This attribute's syntax is 'Directory String' and its case is significant.
この属性の構文は'ディレクトリString'です、そして、ケースは重要です。
( 1.3.6.1.4.1.42.2.27.4.1.13
NAME 'javaClassNames'
DESC 'Fully qualified Java class or interface name'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
(1.3.6.1.4.1.42.2.27.4.1.13NAME'javaClassNames'DESC'完全に適切なJavaクラスかインタフェース名前'EQUALITY caseExactMatch SYNTAX1.3.6.1.4.1.1466.115、.121、.1、.15)
Ryan, et al. Informational [Page 11] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[11ページ]のRFC2713図式
3.4 javaSerializedData
3.4 javaSerializedData
This attribute stores the serialized form of a Java object. The serialized form is described in [Serial].
この属性はJavaオブジェクトの連載されたフォームを保存します。 連載されたフォームは[シリーズ]で説明されます。
This attribute's syntax is 'Octet String'.
この属性の構文は'八重奏String'です。
( 1.3.6.1.4.1.42.2.27.4.1.8
NAME 'javaSerializedData
DESC 'Serialized form of a Java object'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE
)
(.8NAME'javaSerializedData DESC'という.1の1.3の.27の.4の.1の連載されたa Javaオブジェクト'SYNTAX1.3.6.1.4.6.1.4.1.42.2フォーム、.1466、.115、.121、.1、.40SINGLE-VALUE)、'
3.5 javaFactory
3.5 javaFactory
This attribute stores the fully qualified class name of the object factory (for example, "com.wiz.jndi.WizObjectFactory") that can be used to create an instance of the object identified by the javaClassName attribute.
この属性はjavaClassName属性によって特定されたオブジェクトのインスタンスを作成するのに使用できるオブジェクト工場(例えば、"com.wiz.jndi.WizObjectFactory")の完全に適切なクラス名を保存します。
This attribute's syntax is 'Directory String' and its case is significant.
この属性の構文は'ディレクトリString'です、そして、ケースは重要です。
( 1.3.6.1.4.1.42.2.27.4.1.10
NAME 'javaFactory'
DESC 'Fully qualified Java class name of a JNDI object factory'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
(1.3.6.1.4.1.42.2.27.4.1.10NAME'javaFactory'DESC'JNDIオブジェクト工場の完全に適切なJavaクラス名'EQUALITY caseExactMatch SYNTAX1.3.6.1.4、.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
3.6 javaReferenceAddress
3.6 javaReferenceAddress
This attribute represents the sequence of addresses of a JNDI reference. Each of its values represents one address, a Java object of type javax.naming.RefAddr. Its value is a concatenation of the address type and address contents, preceded by a sequence number (the order of addresses in a JNDI reference is significant). For example:
この属性はJNDI参照のアドレスの系列を表します。 それぞれの値は1つのアドレス、タイプjavax.naming.RefAddrのJavaオブジェクトを表します。 値は一連番号が先行したアドレスタイプとアドレスコンテンツの連結(JNDI参照における、アドレスの注文は重要である)です。 例えば:
#0#TypeA#ValA
#1#TypeB#ValB
#2#TypeC##rO0ABXNyABpq...
#0#TypeA#ValA#1#TypeB#ValB#2#TypeC##rO0ABXNyABpq…
In more detail, the value is encoded as follows:
さらに詳細に、値は以下の通りコード化されます:
Ryan, et al. Informational [Page 12] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[12ページ]のRFC2713図式
The delimiter is the first character of the value. For readability the character '#' is recommended when it is not otherwise used anywhere in the value, but any character may be used subject to restrictions given below.
デリミタは価値の最初のキャラクタです。 それが別の方法で値でどこでも使用されるのではなく、いくらか使用されるときキャラクタ'#'が推薦される読み易さのために、キャラクタは以下に与えられた制限を条件として使用されるかもしれません。
The first delimiter is followed by the sequence number. The sequence number of an address is its position in the JNDI reference, with the first address being numbered 0. It is represented by its shortest string form, in decimal notation.
一連番号は最初のデリミタのあとに続いています。 アドレスの一連番号は番号付の0である最初のアドレスでのJNDI参照でその位置です。 それは10進法で最も短いストリングフォームによって表されます。
The sequence number is followed by a delimiter, then by the address type, and then by another delimiter. If the address is of Java class javax.naming.StringRefAddr, then this delimiter is followed by the value of the address contents (which is a string). Otherwise, this delimiter is followed immediately by another delimiter, and then by the Base64 encoding of the serialized form of the entire address.
デリミタ、そして、アドレスタイプ、およびそして、別のデリミタは一連番号のあとに続いています。 アドレスがJavaのクラスjavax.naming.StringRefAddrのものであるなら、アドレスコンテンツ(ストリングである)の値はこのデリミタのあとに続いています。 さもなければ、すぐ別のデリミタ、およびそして、全体のアドレスの連載されたフォームのBase64コード化はこのデリミタのあとに続いています。
The delimiter may be any character other than a digit or a character contained in the address type. In addition, if the address contents is a string, the delimiter may not be the first character of that string.
デリミタは、ケタ以外のどんなキャラクタかアドレスタイプで含まれたキャラクタであるかもしれません。 さらに、アドレスコンテンツがストリングであるなら、デリミタはそのストリングの最初のキャラクタでないかもしれません。
This attribute's syntax is 'Directory String' and its case is significant. It can contain multiple values.
この属性の構文は'ディレクトリString'です、そして、ケースは重要です。 それは複数の値を含むことができます。
( 1.3.6.1.4.1.42.2.27.4.1.11
NAME 'javaReferenceAddress'
DESC 'Addresses associated with a JNDI Reference'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
(1.3.6.1.4.1.42.2.27.4.1.11NAME DESC'アドレスがJNDI Reference'EQUALITY caseExactMatch SYNTAX1.3.6.1に関連づけた'javaReferenceAddress'.4.1、.1466、.115、.121、.1、.15)
3.7 javaDoc
3.7 javaDoc
This attribute stores a pointer to the Java documentation for the class. It's value is a URL. For example, the following URL points to the specification of the java.lang.String class: http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html
この属性はクラスのためにJavaドキュメンテーションとして指針を保存します。 値がURLであるということです。 例えば、以下のURLはjava.lang.Stringのクラスの仕様を示します: http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html
This attribute's syntax is 'IA5 String' and its case is significant.
この属性の構文は'IA5 String'です、そして、ケースは重要です。
( 1.3.6.1.4.1.42.2.27.4.1.12
NAME 'javaDoc'
DESC 'The Java documentation for the class'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)
(1.3.6.1.4.1.42.2.27.4.1.12NAME'javaDoc'DESC'クラスのためのJavaドキュメンテーション'EQUALITY caseExactIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26)
Ryan, et al. Informational [Page 13] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[13ページ]のRFC2713図式
4 Object Class Definitions
4 オブジェクトクラス定義
The following object classes are defined in this document:
以下のオブジェクトのクラスは本書では定義されます:
javaContainer
javaObject
javaSerializedObject
javaMarshalledObject
javaNamingReference
javaContainer javaObject javaSerializedObject javaMarshalledObject javaNamingReference
4.1 javaContainer
4.1 javaContainer
This structural object class represents a container for a Java object.
この構造的なオブジェクトのクラスはJavaオブジェクトのためにコンテナを表します。
( 1.3.6.1.4.1.42.2.27.4.2.1
NAME 'javaContainer'
DESC 'Container for a Java object'
SUP top
STRUCTURAL
MUST ( cn )
)
(1.3の.42の.2の.27の.4の.2.1NAME'javaContainer'DESC'Javaオブジェクトのためのコンテナ'SUP最高な.6.1.4.1STRUCTURAL MUST(cn))
4.2 javaObject
4.2 javaObject
This abstract object class represents a Java object. A javaObject cannot exist in the directory; only auxiliary or structural subclasses of it can exist in the directory.
この抽象的なオブジェクトのクラスはJavaオブジェクトを表します。 javaObjectはディレクトリに存在できません。 それの補助の、または、構造的なサブクラスしかディレクトリに存在できません。
( 1.3.6.1.4.1.42.2.27.4.2.4
NAME 'javaObject'
DESC 'Java object representation'
SUP top
ABSTRACT
MUST ( javaClassName )
MAY ( javaClassNames $
javaCodebase $
javaDoc $
description )
)
(SUPの最高要約がそうしなければならない1.3.6.1.4.1.42.2.27.4.2.4NAME'javaObject'DESC'Javaオブジェクト表現'(javaClassName)5月(javaClassNames$javaCodebase$javaDoc$記述))
Ryan, et al. Informational [Page 14] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[14ページ]のRFC2713図式
4.3 javaSerializedObject
4.3 javaSerializedObject
This auxiliary object class represents a Java serialized object. It must be mixed in with a structural object class.
この補助のオブジェクトのクラスはJavaの連載されたオブジェクトを表します。 それでは、構造的なオブジェクトのクラスに混入しなければなりません。
( 1.3.6.1.4.1.42.2.27.4.2.5
NAME 'javaSerializedObject'
DESC 'Java serialized object'
SUP javaObject
AUXILIARY
MUST ( javaSerializedData )
)
('SUP javaObject AUXILIARYがそうしなければならない1.3の.4の.2の.5NAME'javaSerializedObject'DESC'Javaの連載された.6.1.4.1.42.2.27オブジェクト(javaSerializedData))
4.4 javaMarshalledObject
4.4 javaMarshalledObject
This auxiliary object class represents a Java marshalled object. It must be mixed in with a structural object class.
この補助のオブジェクトのクラスはJavaの整理されたオブジェクトを表します。 それでは、構造的なオブジェクトのクラスに混入しなければなりません。
( 1.3.6.1.4.1.42.2.27.4.2.8
NAME 'javaMarshalledObject'
DESC 'Java marshalled object'
SUP javaObject
AUXILIARY
MUST ( javaSerializedData )
)
('SUP javaObject AUXILIARYがそうしなければならない1.3の.4の.2の.8NAME'javaMarshalledObject'DESC'Javaの整理された.6.1.4.1.42.2.27オブジェクト(javaSerializedData))
4.5 javaNamingReference
4.5 javaNamingReference
This auxiliary object class represents a JNDI reference. It must be mixed in with a structural object class.
この補助のオブジェクトのクラスはJNDI参照を表します。 それでは、構造的なオブジェクトのクラスに混入しなければなりません。
( 1.3.6.1.4.1.42.2.27.4.2.7
NAME 'javaNamingReference'
DESC 'JNDI reference'
SUP javaObject
AUXILIARY
MAY ( javaReferenceAddress $
javaFactory )
)
(1.3.6.1.4.1.42.2.27.4.2.7NAME'javaNamingReference'DESC'JNDI参照'SUP javaObject AUXILIARY5月(javaReferenceAddress$javaFactory))
Ryan, et al. Informational [Page 15] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[15ページ]のRFC2713図式
5. Security Considerations
5. セキュリティ問題
Serializing an object and storing it into the directory enables (a copy of) the object to be examined and used outside the environment in which it was originally created. The directory entry containing the serialized object could be read and modified within the constraints imposed by the access control mechanisms of the directory. If an object contains sensitive information or information that could be misused outside of the context in which it was created, the object should not be stored in the directory. For more details on security issues relating to serialization in general, see [Serial].
オブジェクトを連載して、ディレクトリとしてそれを保存するのが可能にする、(aがコピーする、)、調べられた、環境で外それが元々作成された使用されるべきオブジェクト。 ディレクトリのアクセス管理機構によって課された規制の中で連載されたオブジェクトを含むディレクトリエントリは、読んで、変更できました。 オブジェクトがそれが作成された文脈の外で誤用できた機密情報か情報を含んでいるなら、ディレクトリにオブジェクトを保存するべきではありません。 一般に、連載に関連する安全保障問題に関するその他の詳細に関しては、見てください[連続の]。
6. Acknowledgements
6. 承認
We would like to thank Joseph Fialli, Peter Jones, Roger Riggs, Bob Scheifler, and Ann Wollrath of Sun Microsystems for their comments and suggestions.
彼らのコメントと提案についてサン・マイクロシステムズのジョゼフFialli、ピーター・ジョーンズ、ロジャー・リッグス、ボブScheifler、およびアンWollrathに感謝申し上げます。
7. References
7. 参照
[CORBA] The Object Management Group, "Common Object Request
Broker Architecture Specification 2.0,"
http://www.omg.org
[CORBA] オブジェクト・マネジメント・グループ、「共通オブジェクト・リクエスト・ブローカー・アーキテクチャ仕様2.0」、 http://www.omg.org
[CORBA-LDAP] Ryan, V., Lee, R. and S. Seligman, "Schema for
Representing CORBA Object References in an LDAP
Directory", RFC 2714, October 1999.
[CORBA-LDAP]ライアンとV.とリー、R.とS.セリグマン、「LDAPディレクトリにおけるCORBAオブジェクト参照を表すための図式」RFC2714(1999年10月)。
[Java] Ken Arnold and James Gosling, "The Java(tm) Programming
Language," Second Edition, ISBN 0-201-31006-6.
[Java]のケン・アーノルドとジェームスGosling、「Java(tm)プログラミング言語」、第2版、ISBN0-201-31006-6。
[JNDI] Java Software, Sun Microsystems, Inc., "The Java(tm)
Naming and Directory Interface (tm) Specification,"
February 1998. http://java.sun.com/products/jndi/
[JNDI] Javaソフトウェア、サン・マイクロシステムズ・インク、「Java(tm)命名とディレクトリインタフェース(tm)仕様」、1998年2月の http://java.sun.com/products/jndi/
[LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight
Directory Access Protocol (v3)", RFC 2251, December
1997.
[LDAPv3]ウォールとM.とハウズとT.とS.Kille、「ライトウェイト・ディレクトリ・アクセス・プロトコル(v3)」、RFC2251 1997年12月。
[RMI] Java Software, Sun Microsystems, Inc., "Remote Method
Invocation," November 1998.
http://java.sun.com/products/jdk/1.2/docs/guide/rmi
[RMI] Javaソフトウェア、サン・マイクロシステムズ・インク、「リモートメソッド実施」、1998年11月の http://java.sun.com/products/jdk/1.2/docs/guide/rmi
Ryan, et al. Informational [Page 16] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[16ページ]のRFC2713図式
[RMI-IIOP] IBM and Java Software, Sun Microsystems, Inc., "RMI over
IIOP", June 1999.
http://java.sun.com/products/rmi-iiop/
[RMI-IIOP]IBMとJavaソフトウェア、サン・マイクロシステムズ・インク、「IIOPの上のRMI」6月1999日の http://java.sun.com/products/rmi-iiop/
[Serial] Java Software, Sun Microsystems, Inc., "Object
Serialization Specification," November 1998.
http://java.sun.com/products/jdk/1.2/docs/guide/
serialization
[連続の] Java Software、サン・マイクロシステムズ・インク、「オブジェクト連載仕様」、11月1998日の http://java.sun.com/products/jdk/1.2/docs/guide/ 連載
[v3Schema] Wahl, M., "A Summary of the X.500(96) User Schema for
use with LDAPv3", RFC 2256, December 1997.
[v3Schema] ウォール、M.、「LDAPv3"、RFC2256、1997年12月との使用のためのX.500(96)ユーザSchemaのSummary。」
8. Authors' Addresses
8. 作者のアドレス
Vincent Ryan Sun Microsystems, Inc. Mail Stop EDUB03 901 San Antonio Road Palo Alto, CA 94303 USA
ヴィンセントライアンサン・マイクロシステムズ・インクメール停止EDUB03 901サンアントニオRoadカリフォルニア94303パロアルト(米国)
Phone: +353 1 819 9151 EMail: vincent.ryan@ireland.sun.com
以下に電話をしてください。 +353 1 819 9151はメールされます: vincent.ryan@ireland.sun.com
Scott Seligman Sun Microsystems, Inc. Mail Stop UCUP02-209 901 San Antonio Road Palo Alto, CA 94303 USA
スコットセリグマンサン・マイクロシステムズ・インクMail停止UCUP02-209 901サンアントニオRoadパロアルト、カリフォルニア94303米国
Phone: +1 408 863 3222 EMail: scott.seligman@eng.sun.com
以下に電話をしてください。 +1 3222年の408 863メール: scott.seligman@eng.sun.com
Rosanna Lee Sun Microsystems, Inc. Mail Stop UCUP02-206 901 San Antonio Road Palo Alto, CA 94303 USA
ロザンナ・サン・マイクロシステムズ・インクのMail停止UCUP02-206 901サンアントニオRoadパロアルト、カリフォルニア94303米国のリー
Phone: +1 408 863 3221 EMail: rosanna.lee@eng.sun.com
以下に電話をしてください。 +1 3221年の408 863メール: rosanna.lee@eng.sun.com
Ryan, et al. Informational [Page 17] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[17ページ]のRFC2713図式
Appendix - LDAP Schema
付録--LDAP図式
-- Attribute types --
-- タイプを結果と考えてください--
( 1.3.6.1.4.1.42.2.27.4.1.6
NAME 'javaClassName'
DESC 'Fully qualified name of distinguished Java class or interface'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
(1.3.6.1.4.1.42.2.27.4.1.6NAME'javaClassName'DESC'顕著なJavaのクラスかインタフェースの完全に修飾された名前'EQUALITY caseExactMatch SYNTAX1.3.6.1.4.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
( 1.3.6.1.4.1.42.2.27.4.1.7
NAME 'javaCodebase'
DESC 'URL(s) specifying the location of class definition'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)
(1.3.6.1.4.1.42.2.27.4.1.7NAME'クラス定義の位置を指定するjavaCodebase'DESC'URL'EQUALITY caseExactIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26)
( 1.3.6.1.4.1.42.2.27.4.1.8
NAME 'javaSerializedData'
DESC 'Serialized form of a Java object'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40
SINGLE-VALUE
)
(.8NAME'javaSerializedData'DESC'という.1の1.3の.27の.4の.1の連載されたa Javaオブジェクト'SYNTAX1.3.6.1.4.6.1.4.1.42.2フォーム、.1466、.115、.121、.1、.40SINGLE-VALUE)
( 1.3.6.1.4.1.42.2.27.4.1.10
NAME 'javaFactory'
DESC 'Fully qualified Java class name of a JNDI object factory'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
SINGLE-VALUE
)
(1.3.6.1.4.1.42.2.27.4.1.10NAME'javaFactory'DESC'JNDIオブジェクト工場の完全に適切なJavaクラス名'EQUALITY caseExactMatch SYNTAX1.3.6.1.4、.1、.1466、.115、.121、.1、.15SINGLE-VALUE)
( 1.3.6.1.4.1.42.2.27.4.1.11
NAME 'javaReferenceAddress'
DESC 'Addresses associated with a JNDI Reference'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
(1.3.6.1.4.1.42.2.27.4.1.11NAME DESC'アドレスがJNDI Reference'EQUALITY caseExactMatch SYNTAX1.3.6.1に関連づけた'javaReferenceAddress'.4.1、.1466、.115、.121、.1、.15)
( 1.3.6.1.4.1.42.2.27.4.1.12
NAME 'javaDoc'
DESC 'The Java documentation for the class'
EQUALITY caseExactIA5Match
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26
)
(1.3.6.1.4.1.42.2.27.4.1.12NAME'javaDoc'DESC'クラスのためのJavaドキュメンテーション'EQUALITY caseExactIA5Match SYNTAX1.3.6、.1、.4、.1、.1466、.115、.121、.1、.26)
Ryan, et al. Informational [Page 18] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[18ページ]のRFC2713図式
( 1.3.6.1.4.1.42.2.27.4.1.13
NAME 'javaClassNames'
DESC 'Fully qualified Java class or interface name'
EQUALITY caseExactMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
(1.3.6.1.4.1.42.2.27.4.1.13NAME'javaClassNames'DESC'完全に適切なJavaクラスかインタフェース名前'EQUALITY caseExactMatch SYNTAX1.3.6.1.4.1.1466.115、.121、.1、.15)
-- from RFC-2256 --
-- RFC-2256から--
( 2.5.4.13
NAME 'description'
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}
)
(2.5.4.13名'記述'平等caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch構文1.3.6.1.4.1の.1466、.115、.121、.1、.15、1024)
-- Object classes --
-- クラスは反対します--
( 1.3.6.1.4.1.42.2.27.4.2.1
NAME 'javaContainer'
DESC 'Container for a Java object'
SUP top
STRUCTURAL
MUST ( cn )
)
(1.3の.42の.2の.27の.4の.2.1NAME'javaContainer'DESC'Javaオブジェクトのためのコンテナ'SUP最高な.6.1.4.1STRUCTURAL MUST(cn))
( 1.3.6.1.4.1.42.2.27.4.2.4
NAME 'javaObject'
DESC 'Java object representation'
SUP top
ABSTRACT
MUST ( javaClassName )
MAY ( javaClassNames $ javaCodebase $ javaDoc $ description )
)
(SUPの最高要約がそうしなければならない1.3.6.1.4.1.42.2.27.4.2.4NAME'javaObject'DESC'Javaオブジェクト表現'(javaClassName)5月(javaClassNames$javaCodebase$javaDoc$記述))
( 1.3.6.1.4.1.42.2.27.4.2.5
NAME 'javaSerializedObject'
DESC 'Java serialized object'
SUP javaObject
AUXILIARY
MUST ( javaSerializedData )
)
('SUP javaObject AUXILIARYがそうしなければならない1.3の.4の.2の.5NAME'javaSerializedObject'DESC'Javaの連載された.6.1.4.1.42.2.27オブジェクト(javaSerializedData))
Ryan, et al. Informational [Page 19] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[19ページ]のRFC2713図式
( 1.3.6.1.4.1.42.2.27.4.2.7
NAME 'javaNamingReference'
DESC 'JNDI reference'
SUP javaObject
AUXILIARY
MAY ( javaReferenceAddress $ javaFactory )
)
(1.3.6.1.4.1.42.2.27.4.2.7NAME'javaNamingReference'DESC'JNDI参照'SUP javaObject AUXILIARY5月(javaReferenceAddress$javaFactory))
( 1.3.6.1.4.1.42.2.27.4.2.8
NAME 'javaMarshalledObject'
DESC 'Java marshalled object'
SUP javaObject
AUXILIARY
MUST ( javaSerializedData )
)
('SUP javaObject AUXILIARYがそうしなければならない1.3の.4の.2の.8NAME'javaMarshalledObject'DESC'Javaの整理された.6.1.4.1.42.2.27オブジェクト(javaSerializedData))
-- Matching rule from ISO X.520 --
-- マッチングはISO X.520から統治されます--
( 2.5.13.5
NAME 'caseExactMatch'
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15
)
(2.5.13.5名'caseExactMatch'構文1.3.6.1の.4、.1、.1466、.115、.121、.1、.15)
Ryan, et al. Informational [Page 20] RFC 2713 Schema for Java Objects October 1999
ライアン、他 Javaオブジェクト1999年10月のための情報[20ページ]のRFC2713図式
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1999). All Rights Reserved.
Copyright(C)インターネット協会(1999)。 All rights reserved。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Ryan, et al. Informational [Page 21]
ライアン、他 情報[21ページ]
一覧
スポンサーリンク
