1 2 3 4 5 6 7Network Working Group V. Ryan 8Request for Comments: 2713 S. Seligman 9Category: Informational R. Lee 10 Sun Microsystems, Inc. 11 October 1999 12 13 14 Schema for Representing Java(tm) Objects in an LDAP Directory 15 16Status of this Memo 17 18 This memo provides information for the Internet community. It does 19 not specify an Internet standard of any kind. Distribution of this 20 memo is unlimited. 21 22Copyright Notice 23 24 Copyright (C) The Internet Society (1999). All Rights Reserved. 25 26Abstract 27 28 This document defines the schema for representing Java(tm) objects in 29 an LDAP directory [LDAPv3]. It defines schema elements to represent 30 a Java serialized object [Serial], a Java marshalled object [RMI], a 31 Java remote object [RMI], and a JNDI reference [JNDI]. 32 331. Introduction 34 35 This document assumes that the reader has a general knowledge of the 36 Java programming language [Java]. For brevity we use the term "Java 37 object" in place of "object in the Java programming language" 38 throughout this text. 39 40 Traditionally, LDAP directories have been used to store data. Users 41 and programmers think of the directory as a hierarchy of directory 42 entries, each containing a set of attributes. You look up an entry 43 from the directory and extract the attribute(s) of interest. For 44 example, you can look up a person's telephone number from the 45 directory. Alternatively, you can search the directory for entries 46 with a particular set of attributes. For example, you can search for 47 all persons in the directory with the surname "Smith". 48 49 For applications written in the Java programming language, a kind of 50 data that is typically shared are Java objects themselves. For such 51 applications, it makes sense to be able to use the directory as a 52 repository for Java objects. The directory provides a centrally 53 administered, and possibly replicated, service for use by Java 54 applications distributed across the network. 55 56 57 58Ryan, et al. Informational [Page 1] 59 60RFC 2713 Schema for Java Objects October 1999 61 62 63 For example, an application server might use the directory for 64 "registering" objects representing the services that it manages, so 65 that a client can later search the directory to locate those services 66 as it needs. 67 68 The motivation for this document is to define a common way for 69 applications to store and retrieve Java objects from the directory. 70 Using this common schema, any Java application that needs to read or 71 store Java objects in the directory can do so in an interoperable 72 way. 73 742 Representation of Java Objects 75 76 This document defines schema elements to represent three types of 77 Java objects: a Java serialized object, a Java marshalled object, 78 and a JNDI reference. A Java remote object is stored as either a Java 79 marshalled object or a JNDI reference. 80 812.1 Common Representations 82 83 A Java object is stored in the LDAP directory by using the object 84 class javaObject. This is the base class from which other Java object 85 related classes derive: javaSerializedObject, javaMarshalledObject, 86 and javaNamingReference. javaObject is an abstract object class, 87 which means that a javaObject cannot exist by itself in the 88 directory; only auxiliary or structural subclasses of it can exist in 89 the directory. 90 91 The object class javaContainer represents a directory entry dedicated 92 to storing a Java object. It is a structural object class. In cases 93 where a subclass of javaObject is mixed in with another structural 94 object class, javaContainer is not required. 95 96 The definitions for the object classes javaObject and javaContainer 97 are presented in Section 4. 98 99 The javaObject class has one mandatory attribute (javaClassName) and 100 four optional attributes (javaClassNames, javaCodebase, javaDoc, 101 description). javaClassName is a single valued attribute that is 102 used to store the fully qualified name of the object's Java class 103 (for example, "java.lang.String"). This may be the object's most 104 derived class's name, but does not have to be; that of a superclass 105 or interface in some cases might be most appropriate. This attribute 106 is intended for storing the name of the object's "distinguished" 107 class, that is, the class or interface with which the object should 108 be identified. 109 110 111 112 113 114Ryan, et al. Informational [Page 2] 115 116RFC 2713 Schema for Java Objects October 1999 117 118 119 javaClassNames is a multivalued attribute that is used to store the 120 fully qualified names of the object's Java classes and interfaces 121 (for example, "java.lang.Byte"). Like all multivalued attributes, the 122 javaClassNames attribute's values are unordered and so no one value 123 is more "distinguished" than the others. This attribute is intended 124 for storing an object's class and interface names and those of its 125 ancestor classes and interfaces, although the list of values does not 126 have to be complete. If the javaClassNames attribute is present, it 127 should include the value of javaClassName. 128 129 For example, suppose an object is stored in the directory with a 130 javaClassName attribute of "java.io.FilePermission", and a 131 javaClassNames attribute of {"java.security.Permission", 132 "java.io.FilePermission", "java.security.Guard", 133 "java.io.Serializable"}. An application searching a directory for 134 Java objects might use javaClassName to produce a summary of the 135 names and types of Java objects in that directory. Another 136 application might use the javaClassNames attribute to find, for 137 example, all java.security.Permission objects. 138 139 javaCodebase is a multivalued attribute that is used to store the 140 location(s) of the object's class definition. javaDoc is used to 141 store a pointer (URL) to the Java documentation for the class. 142 description is used to store a textual description of a Java object 143 and is defined in [v3Schema]. The definitions of these attributes are 144 presented in Section 3. 145 1462.2 Serialized Objects 147 148 To "serialize" an object means to convert its state into a byte 149 stream in such a way that the byte stream can be converted back into 150 a copy of the object. A Java object is "serializable" if its class 151 or any of its superclasses implements either the java.io.Serializable 152 interface or its subinterface java.io.Externalizable. 153 "Deserialization" is the process of converting the serialized form of 154 an object back into a copy of the object. When an object is 155 serialized, the entire tree of objects rooted at the object is also 156 serialized. When it is deserialized, the tree is reconstructed. For 157 example, suppose a serializable Book object contains (a serializable 158 field of) an array of Page objects. When a Book object is 159 serialized, so is the array of Page objects. 160 161 The Java platform specifies a default algorithm by which serializable 162 objects are serialized. A Java class can also override this default 163 serialization with its own algorithm. [Serial] describes object 164 serialization in detail. 165 166 167 168 169 170Ryan, et al. Informational [Page 3] 171 172RFC 2713 Schema for Java Objects October 1999 173 174 175 When an object is serialized, information that identifies its class 176 is recorded in the serialized stream. However, the class's definition 177 ("class file") itself is not recorded. It is the responsibility of 178 the system that is deserializing the object to determine the 179 mechanism to use for locating and loading the associated class 180 definitions. For example, the Java application might include in its 181 classpath a JAR file containing the class definitions of the 182 serialized object, or load the class definitions using information 183 from the directory, as explained below. 184 1852.2.1 Representation in the Directory 186 187 A serialized object is represented in the directory by the attributes 188 javaClassName, javaClassNames, javaCodebase, and javaSerializedData, 189 as defined in Section 3. The mandatory attribute, 190 javaSerializedData, contains the serialized form of the object. 191 Although the serialized form already contains the class name, the 192 mandatory javaClassName attribute also records the class name of the 193 serialized object so that applications can determined class 194 information without having to first deserialize the object. The 195 optional javaClassNames attribute is used to record additional class 196 information about the serialized object. The optional javaCodebase 197 attribute is used to record the locations of the class definitions 198 needed to deserialize the serialized object. 199 200 A directory entry that contains a serialized object is represented by 201 the object class javaSerializedObject, which is a subclass of 202 javaObject. javaSerializedObject is an auxiliary object class, which 203 means that it needs to be mixed in with a structural object class. 204 javaSerializedObject's definition is given in Section 4. 205 2062.3 Marshalled Objects 207 208 To "marshal" an object means to record its state and codebase(s) in 209 such a way that when the marshalled object is "unmarshalled," a copy 210 of the original object is obtained, possibly by automatically loading 211 the class definitions of the object. You can marshal any object that 212 is serializable or remote (that is, implements the java.rmi.Remote 213 interface). Marshalling is like serialization, except marshalling 214 also records codebases. Marshalling is different from serialization 215 in that marshalling treats remote objects specially. If an object is 216 a java.rmi.Remote object, marshalling records the remote object's 217 "stub" (see Section 2.5), instead of the remote object itself. Like 218 serialization, when an object is marshalled, the entire tree of 219 objects rooted at the object is marshalled. When it is unmarshalled, 220 the tree is reconstructed. 221 222 223 224 225 226Ryan, et al. Informational [Page 4] 227 228RFC 2713 Schema for Java Objects October 1999 229 230 231 A "marshalled" object is the represented by the 232 java.rmi.MarshalledObject class. Here's an example of how to create 233 MarshalledObjects for serializable and remote objects: 234 235 java.io.Serializable sobj = ...; 236 java.rmi.MarshalledObject mobj1 = 237 new java.rmi.MarshalledObject(sobj); 238 239 java.rmi.Remote robj = ...; 240 java.rmi.MarshalledObject mobj2 = 241 new java.rmi.MarshalledObject(robj); 242 243 Then, to retrieve the original objects from the MarshalledObjects, do 244 as follows: 245 246 java.io.Serializable sobj = (java.io.Serializable) mobj1.get(); 247 java.io.Remote rstub = (java.io.Remote) mobj2.get(); 248 249 MarshalledObject is available only on the Java 2 Platform, Standard 250 Edition, v1.2, and higher releases. 251 2522.3.1 Representation in the Directory 253 254 A marshalled object is represented in the directory by the attributes 255 javaClassName, javaClassNames, and javaSerializedData, as defined in 256 Section 3. The mandatory attribute, javaSerializedData, contains the 257 serialized form of the marshalled object (that is, the serialized 258 form of a MarshalledObject instance). The mandatory javaClassName 259 attribute records the distinguished class name of the object before 260 it has been marshalled. The optional javaClassNames attribute is 261 used to record additional class information about the object before 262 it has been marshalled. 263 264 A directory entry that contains a marshalled object is represented by 265 the object class javaMarshalledObject, which is a subclass of 266 javaObject. javaMarshalledObject is an auxiliary object class, which 267 means that it needs to be mixed in with a structural object class. 268 javaMarshalledObject's definition is given in Section 4. 269 270 As evident in this description, a javaMarshalledObject differs from a 271 javaSerializedObject only in the interpretation of the javaClassName 272 and javaClassNames attributes. 273 274 275 276 277 278 279 280 281 282Ryan, et al. Informational [Page 5] 283 284RFC 2713 Schema for Java Objects October 1999 285 286 2872.4 JNDI References 288 289 Java Naming and Directory Interface(tm) (JNDI) is a directory access 290 API specified in the Java programming language [JNDI]. It provides 291 an object-oriented view of the directory, allowing Java objects to be 292 added to and retrieved from the directory without requiring the 293 client to manage data representation issues. 294 295 JNDI defines the notion of a "reference" for use when an object 296 cannot be stored in the directory directly, or when it is 297 inappropriate or undesirable to do so. An object with an associated 298 reference is stored in the directory indirectly, by storing its 299 reference instead. 300 3012.4.1 Contents of a Reference 302 303 A JNDI reference is a Java object of class javax.naming.Reference. 304 It consists of class information about the object being referenced 305 and an ordered list of addresses. An address is a Java object of 306 class javax.naming.RefAddr. Each address contains information on how 307 to construct the object. 308 309 A common use for JNDI references is to represent connections to a 310 network service such as a database, directory, or file system. Each 311 address may then identify a "communications endpoint" for that 312 service, containing information on how to contact the service. 313 Multiple addresses may arise for various reasons, such as replication 314 or the object offering interfaces over more than one communication 315 mechanism. 316 317 A reference also contains information to assist in the creation of an 318 instance of the object to which the reference refers. It contains 319 the Java class name of that object, and the class name and location 320 of the object factory to be used to create the object. The 321 procedures for creating an object given its reference and the reverse 322 are described in [JNDI]. 323 3242.4.2 Representation in the Directory 325 326 A JNDI reference is stored in the directory by using the attributes 327 javaClassName, javaClassNames, javaCodebase, javaReferenceAddress, 328 and javaFactory, defined in Section 3. These attributes store 329 information corresponding to the contents of a reference described 330 above. javaReferenceAddress is a multivalued optional attribute for 331 storing reference addresses. javaFactory is the optional attribute 332 for storing the object factory's fully qualified class name. The 333 mandatory javaClassName attribute is used to store the name of the 334 distinguished class of the object. The optional javaClassNames 335 336 337 338Ryan, et al. Informational [Page 6] 339 340RFC 2713 Schema for Java Objects October 1999 341 342 343 attribute is used to record additional class and interface names. 344 The optional javaCodebase attribute is used to store the locations of 345 the object factory's and the object's class definitions. 346 347 A directory entry containing a JNDI reference is represented by the 348 object class javaNamingReference, which is a subclass of javaObject. 349 javaNamingReference is an auxiliary object class, which means that it 350 needs to be mixed in with a structural object class. 351 javaNamingReference's definition is given in Section 4. 352 3532.5 Remote Objects 354 355 The Java Remote Method Invocation (RMI) system [RMI] is a mechanism 356 that enables an object on one Java virtual machine to invoke methods 357 on an object in another Java virtual machine. Any object whose 358 methods can be invoked in this way must implement the java.rmi.Remote 359 interface. When such an object is invoked, its arguments are 360 marshalled and sent from the local virtual machine to the remote one, 361 where the arguments are unmarshalled and used. When the method 362 terminates, the results are marshalled from the remote machine and 363 sent to the caller's virtual machine. 364 365 To make a remote object accessible to other virtual machines, a 366 program typically registers it with the RMI registry. The program 367 supplies to the RMI registry the string name of the remote object and 368 the remote object itself. When a program wants to access a remote 369 object, it supplies the object's string name to the RMI registry on 370 the same machine as the remote object. The RMI registry returns to 371 the caller a reference (called "stub") to the remote object. When 372 the program receives the stub for the remote object, it can invoke 373 methods on the remote object (through the stub). A program can also 374 obtain references to remote objects as a result of remote calls to 375 other remote objects or from other naming services. For example, the 376 program can look up a reference to a remote object from an LDAP 377 server that supports the schema defined in this document. 378 379 The string name accepted by the RMI registry has the syntax 380 "rmi://hostname:port/remoteObjectName", where "hostname" and "port" 381 identify the machine and port on which the RMI registry is running, 382 respectively, and "remoteObjectName" is the string name of the remote 383 object. "hostname", "port", and the prefix, "rmi:", are optional. If 384 "hostname" is not specified, it defaults to the local host. If 385 "port" is not specified, it defaults to 1099. If "remoteObjectName" 386 is not specified, then the object being named is the RMI registry 387 itself. See [RMI] for details. 388 389 390 391 392 393 394Ryan, et al. Informational [Page 7] 395 396RFC 2713 Schema for Java Objects October 1999 397 398 399 RMI can be supported using different protocols: the Java Remote 400 Method Protocol (JRMP) and the Internet Inter-ORB Protocol (IIOP). 401 The JRMP is a specialized protocol designed for RMI; the IIOP is the 402 standard protocol for communication between CORBA objects [CORBA]. 403 RMI over IIOP allows Java remote objects to communicate with CORBA 404 objects which might be written in a non-Java programming language 405 [RMI-IIOP]. 406 4072.5.1 Representation in the Directory 408 409 Remote objects that use the IIOP are represented in the directory as 410 CORBA object references [CORBA-LDAP]. Remote objects that use the 411 JRMP are represented in the directory in one of two ways: as a 412 marshalled object, or as a JNDI reference. 413 414 A marshalled object records the codebases of the remote object's stub 415 and any serializable or remote objects that it references, and 416 replaces remote objects with their stubs. To store a Remote object 417 as a marshalled object (java.rmi.MarshalledObject), you first create 418 a java.rmi.MarshalledObject instance for it. 419 420 java.rmi.Remote robj = ...; 421 java.rmi.MarshalledObject mobj = 422 new java.rmi.MarshalledObject(robj); 423 424 You can then store the MarshalledObject instance as a 425 javaMarshalledObject. The javaClassName attribute should contain the 426 fully qualified name of the distinguished class of the remote object. 427 The javaClassNames attribute should contain the names of the classes 428 and interfaces of the remote object. To read the remote object back 429 from the directory, first deserialize the contents of the 430 javaSerializedData to get a MarshalledObject (mobj), then retrieve it 431 from the MarshalledObject as follows: 432 433 java.rmi.Remote robj = (java.rmi.Remote)mobj.get(); 434 435 This returns the remote stub, which you can then use to invoke remote 436 methods. 437 438 MarshalledObject is available only on the Java 2 Platform, Standard 439 Edition, v1.2 and higher releases. Therefore, a remote object stored 440 as a MarshalledObject can only be read by clients using the the Java 441 2 Platform, Standard Edition, v1.2 or higher releases. 442 443 444 445 446 447 448 449 450Ryan, et al. Informational [Page 8] 451 452RFC 2713 Schema for Java Objects October 1999 453 454 455 To store a remote object as a JNDI reference, you first create a 456 javax.naming.Reference object instance for it using the remote 457 object's string name as it has been, or will be, recorded with the 458 RMI registry, with the additional restriction that the "rmi:" prefix 459 must be present. Here's an example: 460 461 javax.naming.Reference ref = new javax.naming.Reference( 462 obj.getClass().getName(), 463 new javax.naming.StringRefAddr("URL", 464 "rmi://rserver/AppRemoteObjectX")); 465 466 You then store the javax.naming.Reference instance as a 467 javaNamingReference. The advantage of using a JNDI reference is that 468 this can be done without a reference to the remote object. In fact, 469 the remote object does not have to exist at the time that this 470 recording in the directory is made. The remote object needs to exist 471 and be bound with the RMI registry when the object is looked up from 472 the directory. 473 4742.6 Serialized Objects Vs. Marshalled Objects Vs. References 475 476 The object classes defined in this document store different aspects 477 of the Java objects. 478 479 A javaSerializedObject or a serializable object stored as a 480 javaMarshalledObject represents the object itself, while a 481 javaNamingReference or a remote object stored as a 482 javaMarshalledObject represents a "pointer" to the object. 483 484 When storing a serializable object in the directory, you have a 485 choice of storing it as a javaSerializedObject or a 486 javaMarshalledObject. The javaSerializedObject object class provides 487 the basic way in which to store serializable objects. When you create 488 an LDAP entry using the javaSerializableObject object class, you must 489 explicitly set the javaCodebase attribute if you want readers of that 490 entry to know where to load the class definitions of the object. When 491 you create an LDAP entry using the javaMarshalledObject object class, 492 you use the MarshalledObject class. The MarshalledObject class uses 493 the RMI infrastructure available on the Java platform to automate how 494 codebase information is gathered and recorded, thus freeing you from 495 having to set the javaCodebase attribute. On the other hand, the 496 javaCodebase attribute is human-readable and can be updated easily by 497 using text-based tools without having to change other parts of the 498 entry. This allows you, for instance, to move the class definitions 499 to another location and then update the javaCodebase attribute to 500 reflect the move without having to update the serialized object 501 itself. 502 503 504 505 506Ryan, et al. Informational [Page 9] 507 508RFC 2713 Schema for Java Objects October 1999 509 510 511 A javaNamingReference provides a way of recording address information 512 about an object which itself is not directly stored in the directory. 513 A remote object stored as a javaMarshalledObject also records address 514 information (the object's "stub") of an object which itself is not 515 directory stored in the directory. In other words, you can think of 516 these as compact representations of the information required to 517 access the object. 518 519 A javaNamingReference typically consists of a small number of human- 520 readable strings. Standard text-based tools for directory 521 administration may therefore be used to add, read, or modify 522 reference entries -- if so desired -- quite easily. Serialized and 523 marshalled objects are not intended to be read or manipulated 524 directly by humans. 525 5263 Attribute Type Definitions 527 528 The following attribute types are defined in this document: 529 530 javaClassName 531 javaClassNames 532 javaCodebase 533 javaSerializedData 534 javaFactory 535 javaReferenceAddress 536 javaDoc 537 5383.1 javaClassName 539 540 This attribute stores the fully qualified name of the Java object's 541 "distinguished" class or interface (for example, "java.lang.String"). 542 It is a single-valued attribute. This attribute's syntax is ' 543 Directory String' and its case is significant. 544 545 ( 1.3.6.1.4.1.42.2.27.4.1.6 546 NAME 'javaClassName' 547 DESC 'Fully qualified name of distinguished Java class or 548 interface' 549 EQUALITY caseExactMatch 550 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 551 SINGLE-VALUE 552 ) 553 554 555 556 557 558 559 560 561 562Ryan, et al. Informational [Page 10] 563 564RFC 2713 Schema for Java Objects October 1999 565 566 5673.2 javaCodebase 568 569 This attribute stores the Java class definition's locations. It 570 specifies the locations from which to load the class definition for 571 the class specified by the javaClassName attribute. Each value of 572 the attribute contains an ordered list of URLs, separated by spaces. 573 For example, a value of "url1 url2 url3" means that the three 574 (possibly interdependent) URLs (url1, url2, and url3) form the 575 codebase for loading in the Java class definition. 576 577 If the javaCodebase attribute contains more than one value, each 578 value is an independent codebase. That is, there is no relationship 579 between the URLs in one value and those in another; each value can be 580 viewed as an alternate source for loading the Java class definition. 581 See [Java] for information regarding class loading. 582 583 This attribute's syntax is 'IA5 String' and its case is significant. 584 585 ( 1.3.6.1.4.1.42.2.27.4.1.7 586 NAME 'javaCodebase' 587 DESC 'URL(s) specifying the location of class definition' 588 EQUALITY caseExactIA5Match 589 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 590 ) 591 5923.3 javaClassNames 593 594 This attribute stores the Java object's fully qualified class or 595 interface names (for example, "java.lang.String"). It is a 596 multivalued attribute. When more than one value is present, each is 597 the name of a class or interface, or ancestor class or interface, of 598 this object. 599 600 This attribute's syntax is 'Directory String' and its case is 601 significant. 602 603 ( 1.3.6.1.4.1.42.2.27.4.1.13 604 NAME 'javaClassNames' 605 DESC 'Fully qualified Java class or interface name' 606 EQUALITY caseExactMatch 607 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 608 ) 609 610 611 612 613 614 615 616 617 618Ryan, et al. Informational [Page 11] 619 620RFC 2713 Schema for Java Objects October 1999 621 622 6233.4 javaSerializedData 624 625 This attribute stores the serialized form of a Java object. The 626 serialized form is described in [Serial]. 627 628 This attribute's syntax is 'Octet String'. 629 630 ( 1.3.6.1.4.1.42.2.27.4.1.8 631 NAME 'javaSerializedData 632 DESC 'Serialized form of a Java object' 633 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 634 SINGLE-VALUE 635 ) 636 6373.5 javaFactory 638 639 This attribute stores the fully qualified class name of the object 640 factory (for example, "com.wiz.jndi.WizObjectFactory") that can be 641 used to create an instance of the object identified by the 642 javaClassName attribute. 643 644 This attribute's syntax is 'Directory String' and its case is 645 significant. 646 647 ( 1.3.6.1.4.1.42.2.27.4.1.10 648 NAME 'javaFactory' 649 DESC 'Fully qualified Java class name of a JNDI object factory' 650 EQUALITY caseExactMatch 651 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 652 SINGLE-VALUE 653 ) 654 6553.6 javaReferenceAddress 656 657 This attribute represents the sequence of addresses of a JNDI 658 reference. Each of its values represents one address, a Java object 659 of type javax.naming.RefAddr. Its value is a concatenation of the 660 address type and address contents, preceded by a sequence number (the 661 order of addresses in a JNDI reference is significant). For example: 662 663 #0#TypeA#ValA 664 #1#TypeB#ValB 665 #2#TypeC##rO0ABXNyABpq... 666 667 In more detail, the value is encoded as follows: 668 669 670 671 672 673 674Ryan, et al. Informational [Page 12] 675 676RFC 2713 Schema for Java Objects October 1999 677 678 679 The delimiter is the first character of the value. For readability 680 the character '#' is recommended when it is not otherwise used 681 anywhere in the value, but any character may be used subject to 682 restrictions given below. 683 684 The first delimiter is followed by the sequence number. The sequence 685 number of an address is its position in the JNDI reference, with the 686 first address being numbered 0. It is represented by its shortest 687 string form, in decimal notation. 688 689 The sequence number is followed by a delimiter, then by the address 690 type, and then by another delimiter. If the address is of Java class 691 javax.naming.StringRefAddr, then this delimiter is followed by the 692 value of the address contents (which is a string). Otherwise, this 693 delimiter is followed immediately by another delimiter, and then by 694 the Base64 encoding of the serialized form of the entire address. 695 696 The delimiter may be any character other than a digit or a character 697 contained in the address type. In addition, if the address contents 698 is a string, the delimiter may not be the first character of that 699 string. 700 701 This attribute's syntax is 'Directory String' and its case is 702 significant. It can contain multiple values. 703 704 ( 1.3.6.1.4.1.42.2.27.4.1.11 705 NAME 'javaReferenceAddress' 706 DESC 'Addresses associated with a JNDI Reference' 707 EQUALITY caseExactMatch 708 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 709 ) 710 7113.7 javaDoc 712 713 This attribute stores a pointer to the Java documentation for the 714 class. It's value is a URL. For example, the following URL points to 715 the specification of the java.lang.String class: 716 http://java.sun.com/products/jdk/1.2/docs/api/java/lang/String.html 717 718 This attribute's syntax is 'IA5 String' and its case is significant. 719 720 ( 1.3.6.1.4.1.42.2.27.4.1.12 721 NAME 'javaDoc' 722 DESC 'The Java documentation for the class' 723 EQUALITY caseExactIA5Match 724 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 725 ) 726 727 728 729 730Ryan, et al. Informational [Page 13] 731 732RFC 2713 Schema for Java Objects October 1999 733 734 7354 Object Class Definitions 736 737 The following object classes are defined in this document: 738 739 javaContainer 740 javaObject 741 javaSerializedObject 742 javaMarshalledObject 743 javaNamingReference 744 7454.1 javaContainer 746 747 This structural object class represents a container for a Java 748 object. 749 750 ( 1.3.6.1.4.1.42.2.27.4.2.1 751 NAME 'javaContainer' 752 DESC 'Container for a Java object' 753 SUP top 754 STRUCTURAL 755 MUST ( cn ) 756 ) 757 7584.2 javaObject 759 760 This abstract object class represents a Java object. A javaObject 761 cannot exist in the directory; only auxiliary or structural 762 subclasses of it can exist in the directory. 763 764 ( 1.3.6.1.4.1.42.2.27.4.2.4 765 NAME 'javaObject' 766 DESC 'Java object representation' 767 SUP top 768 ABSTRACT 769 MUST ( javaClassName ) 770 MAY ( javaClassNames $ 771 javaCodebase $ 772 javaDoc $ 773 description ) 774 ) 775 776 777 778 779 780 781 782 783 784 785 786Ryan, et al. Informational [Page 14] 787 788RFC 2713 Schema for Java Objects October 1999 789 790 7914.3 javaSerializedObject 792 793 This auxiliary object class represents a Java serialized object. It 794 must be mixed in with a structural object class. 795 796 ( 1.3.6.1.4.1.42.2.27.4.2.5 797 NAME 'javaSerializedObject' 798 DESC 'Java serialized object' 799 SUP javaObject 800 AUXILIARY 801 MUST ( javaSerializedData ) 802 ) 803 8044.4 javaMarshalledObject 805 806 This auxiliary object class represents a Java marshalled object. It 807 must be mixed in with a structural object class. 808 809 ( 1.3.6.1.4.1.42.2.27.4.2.8 810 NAME 'javaMarshalledObject' 811 DESC 'Java marshalled object' 812 SUP javaObject 813 AUXILIARY 814 MUST ( javaSerializedData ) 815 ) 816 8174.5 javaNamingReference 818 819 This auxiliary object class represents a JNDI reference. It must be 820 mixed in with a structural object class. 821 822 ( 1.3.6.1.4.1.42.2.27.4.2.7 823 NAME 'javaNamingReference' 824 DESC 'JNDI reference' 825 SUP javaObject 826 AUXILIARY 827 MAY ( javaReferenceAddress $ 828 javaFactory ) 829 ) 830 831 832 833 834 835 836 837 838 839 840 841 842Ryan, et al. Informational [Page 15] 843 844RFC 2713 Schema for Java Objects October 1999 845 846 8475. Security Considerations 848 849 Serializing an object and storing it into the directory enables (a 850 copy of) the object to be examined and used outside the environment 851 in which it was originally created. The directory entry containing 852 the serialized object could be read and modified within the 853 constraints imposed by the access control mechanisms of the 854 directory. If an object contains sensitive information or 855 information that could be misused outside of the context in which it 856 was created, the object should not be stored in the directory. For 857 more details on security issues relating to serialization in general, 858 see [Serial]. 859 8606. Acknowledgements 861 862 We would like to thank Joseph Fialli, Peter Jones, Roger Riggs, Bob 863 Scheifler, and Ann Wollrath of Sun Microsystems for their comments 864 and suggestions. 865 8667. References 867 868 [CORBA] The Object Management Group, "Common Object Request 869 Broker Architecture Specification 2.0," 870 http://www.omg.org 871 872 [CORBA-LDAP] Ryan, V., Lee, R. and S. Seligman, "Schema for 873 Representing CORBA Object References in an LDAP 874 Directory", RFC 2714, October 1999. 875 876 [Java] Ken Arnold and James Gosling, "The Java(tm) Programming 877 Language," Second Edition, ISBN 0-201-31006-6. 878 879 [JNDI] Java Software, Sun Microsystems, Inc., "The Java(tm) 880 Naming and Directory Interface (tm) Specification," 881 February 1998. http://java.sun.com/products/jndi/ 882 883 [LDAPv3] Wahl, M., Howes, T. and S. Kille, "Lightweight 884 Directory Access Protocol (v3)", RFC 2251, December 885 1997. 886 887 [RMI] Java Software, Sun Microsystems, Inc., "Remote Method 888 Invocation," November 1998. 889 http://java.sun.com/products/jdk/1.2/docs/guide/rmi 890 891 892 893 894 895 896 897 898Ryan, et al. Informational [Page 16] 899 900RFC 2713 Schema for Java Objects October 1999 901 902 903 [RMI-IIOP] IBM and Java Software, Sun Microsystems, Inc., "RMI over 904 IIOP", June 1999. 905 http://java.sun.com/products/rmi-iiop/ 906 907 [Serial] Java Software, Sun Microsystems, Inc., "Object 908 Serialization Specification," November 1998. 909 http://java.sun.com/products/jdk/1.2/docs/guide/ 910 serialization 911 912 [v3Schema] Wahl, M., "A Summary of the X.500(96) User Schema for 913 use with LDAPv3", RFC 2256, December 1997. 914 9158. Authors' Addresses 916 917 Vincent Ryan 918 Sun Microsystems, Inc. 919 Mail Stop EDUB03 920 901 San Antonio Road 921 Palo Alto, CA 94303 922 USA 923 924 Phone: +353 1 819 9151 925 EMail: vincent.ryan@ireland.sun.com 926 927 928 Scott Seligman 929 Sun Microsystems, Inc. 930 Mail Stop UCUP02-209 931 901 San Antonio Road 932 Palo Alto, CA 94303 933 USA 934 935 Phone: +1 408 863 3222 936 EMail: scott.seligman@eng.sun.com 937 938 939 Rosanna Lee 940 Sun Microsystems, Inc. 941 Mail Stop UCUP02-206 942 901 San Antonio Road 943 Palo Alto, CA 94303 944 USA 945 946 Phone: +1 408 863 3221 947 EMail: rosanna.lee@eng.sun.com 948 949 950 951 952 953 954Ryan, et al. Informational [Page 17] 955 956RFC 2713 Schema for Java Objects October 1999 957 958 959Appendix - LDAP Schema 960 961 -- Attribute types -- 962 963 ( 1.3.6.1.4.1.42.2.27.4.1.6 964 NAME 'javaClassName' 965 DESC 'Fully qualified name of distinguished Java class or interface' 966 EQUALITY caseExactMatch 967 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 968 SINGLE-VALUE 969 ) 970 971 ( 1.3.6.1.4.1.42.2.27.4.1.7 972 NAME 'javaCodebase' 973 DESC 'URL(s) specifying the location of class definition' 974 EQUALITY caseExactIA5Match 975 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 976 ) 977 978 ( 1.3.6.1.4.1.42.2.27.4.1.8 979 NAME 'javaSerializedData' 980 DESC 'Serialized form of a Java object' 981 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 982 SINGLE-VALUE 983 ) 984 985 ( 1.3.6.1.4.1.42.2.27.4.1.10 986 NAME 'javaFactory' 987 DESC 'Fully qualified Java class name of a JNDI object factory' 988 EQUALITY caseExactMatch 989 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 990 SINGLE-VALUE 991 ) 992 993 ( 1.3.6.1.4.1.42.2.27.4.1.11 994 NAME 'javaReferenceAddress' 995 DESC 'Addresses associated with a JNDI Reference' 996 EQUALITY caseExactMatch 997 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 998 ) 999 1000 ( 1.3.6.1.4.1.42.2.27.4.1.12 1001 NAME 'javaDoc' 1002 DESC 'The Java documentation for the class' 1003 EQUALITY caseExactIA5Match 1004 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 1005 ) 1006 1007 1008 1009 1010Ryan, et al. Informational [Page 18] 1011 1012RFC 2713 Schema for Java Objects October 1999 1013 1014 1015 ( 1.3.6.1.4.1.42.2.27.4.1.13 1016 NAME 'javaClassNames' 1017 DESC 'Fully qualified Java class or interface name' 1018 EQUALITY caseExactMatch 1019 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1020 ) 1021 1022 -- from RFC-2256 -- 1023 1024 ( 2.5.4.13 1025 NAME 'description' 1026 EQUALITY caseIgnoreMatch 1027 SUBSTR caseIgnoreSubstringsMatch 1028 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} 1029 ) 1030 1031 -- Object classes -- 1032 1033 ( 1.3.6.1.4.1.42.2.27.4.2.1 1034 NAME 'javaContainer' 1035 DESC 'Container for a Java object' 1036 SUP top 1037 STRUCTURAL 1038 MUST ( cn ) 1039 ) 1040 1041 ( 1.3.6.1.4.1.42.2.27.4.2.4 1042 NAME 'javaObject' 1043 DESC 'Java object representation' 1044 SUP top 1045 ABSTRACT 1046 MUST ( javaClassName ) 1047 MAY ( javaClassNames $ javaCodebase $ javaDoc $ description ) 1048 ) 1049 1050 ( 1.3.6.1.4.1.42.2.27.4.2.5 1051 NAME 'javaSerializedObject' 1052 DESC 'Java serialized object' 1053 SUP javaObject 1054 AUXILIARY 1055 MUST ( javaSerializedData ) 1056 ) 1057 1058 1059 1060 1061 1062 1063 1064 1065 1066Ryan, et al. Informational [Page 19] 1067 1068RFC 2713 Schema for Java Objects October 1999 1069 1070 1071 ( 1.3.6.1.4.1.42.2.27.4.2.7 1072 NAME 'javaNamingReference' 1073 DESC 'JNDI reference' 1074 SUP javaObject 1075 AUXILIARY 1076 MAY ( javaReferenceAddress $ javaFactory ) 1077 ) 1078 1079 ( 1.3.6.1.4.1.42.2.27.4.2.8 1080 NAME 'javaMarshalledObject' 1081 DESC 'Java marshalled object' 1082 SUP javaObject 1083 AUXILIARY 1084 MUST ( javaSerializedData ) 1085 ) 1086 1087 -- Matching rule from ISO X.520 -- 1088 1089 ( 2.5.13.5 1090 NAME 'caseExactMatch' 1091 SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 1092 ) 1093 1094 1095 1096 1097 1098 1099 1100 1101 1102 1103 1104 1105 1106 1107 1108 1109 1110 1111 1112 1113 1114 1115 1116 1117 1118 1119 1120 1121 1122Ryan, et al. Informational [Page 20] 1123 1124RFC 2713 Schema for Java Objects October 1999 1125 1126 1127Full Copyright Statement 1128 1129 Copyright (C) The Internet Society (1999). All Rights Reserved. 1130 1131 This document and translations of it may be copied and furnished to 1132 others, and derivative works that comment on or otherwise explain it 1133 or assist in its implementation may be prepared, copied, published 1134 and distributed, in whole or in part, without restriction of any 1135 kind, provided that the above copyright notice and this paragraph are 1136 included on all such copies and derivative works. However, this 1137 document itself may not be modified in any way, such as by removing 1138 the copyright notice or references to the Internet Society or other 1139 Internet organizations, except as needed for the purpose of 1140 developing Internet standards in which case the procedures for 1141 copyrights defined in the Internet Standards process must be 1142 followed, or as required to translate it into languages other than 1143 English. 1144 1145 The limited permissions granted above are perpetual and will not be 1146 revoked by the Internet Society or its successors or assigns. 1147 1148 This document and the information contained herein is provided on an 1149 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1150 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1151 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1152 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1153 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1154 1155Acknowledgement 1156 1157 Funding for the RFC Editor function is currently provided by the 1158 Internet Society. 1159 1160 1161 1162 1163 1164 1165 1166 1167 1168 1169 1170 1171 1172 1173 1174 1175 1176 1177 1178Ryan, et al. Informational [Page 21] 1179 1180