Previous | Next | Trail Map | Java Objects and the Directory | Storing Objects in the Directory

Serializable Objects

Definitions

To serialize an object means to convert its state into a byte stream in such a way that the byte stream can be reverted 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.

Because the java.awt.Button class implements the Serializable interface, for example, you can serialize a java.awt.Button object and store that serialized state in a file. Later, you read back the serialized state and convert it back (that is, "deserialize" it) into a java.awt.Button object.

The Java platform specifies a default way by which serializable objects are serialized. A (Java) class can also override this default serialization and define its own way of serializing objects of that class. The Object Serialization Specification describes object serialization in detail.

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 how to locate and load the necessary class files. For example, a Java application might include in its classpath a JAR file containing the class files of the serialized object(s), or load the class definitions using information stored in the directory, as explained below.

Binding a Serializable Object

You can store a serializable object in the directory if the underlying service provider supports it. Sun's LDAP service provider supports storing serialized objects.

The following example invokes the Context.bind()(in the API reference documentation) method to bind an AWT button to the name "cn=Button". You can also use the DirContext.bind()(in the API reference documentation) method if you want to associate attributes with the new binding. Context.rebind()(in the API reference documentation) and DirContext.rebind()(in the API reference documentation) can be used if you want to overwrite an existing binding. 

// Create object to be bound
Button b = new Button("Push me");

// Perform bind
ctx.bind("cn=Button", b);
You can then read it back using Context.lookup()(in the API reference documentation) as follows: 
// Check that it is bound
Button b2 = (Button)ctx.lookup("cn=Button");
System.out.println(b2);
Running this example produces the following output: 
# java SerObj
java.awt.Button[button0,0,0,0x0,invalid,label=Push me]

Specifying a Codebase
Note: The procedures described here are for binding a serializable object to a directory service that follows the schema defined in RFC 2713. These procedures might not be generally applicable to other naming and directory service that support binding a serializable object with a specified codebase.
When a serialized object is bound in the directory as shown in the previous example, applications that read the serialized object from the directory must have access to the class definitions necessary to deserialize the object. Alternatively, you can record a codebase with the serialized object in the directory, either when you bind the object, or subsequently by adding an attribute using DirContext.modifyAttributes()(in the API reference documentation) . You can use any attribute to record this codebase and have your application read that attribute from the directory and use it appropriately. Or you could use the attribute "javaCodebase" specified in RFC 2713. In the latter case, Sun's LDAP service provider will automatically use the attribute to load the class defintions as needed. "javaCodebase" should contain the URL of a codebase directory or a JAR file. (Note that JAR files only work with the Java 2 Platform). If the codebase contains more than one URL, each URL must be separated by a space character.

The following example is similar to the one for binding a java.awt.Button. The difference is that we are using a user-defined Serializable class, Flower, and supplying a "javaCodebase" attribute containing the location of Flower's class definition. Here's the code that does the binding: 

String codebase = ...;

// Create object to be bound
Flower f = new Flower("rose", "pink");

// Perform bind and specify codebase
ctx.bind("cn=Flower", f, new BasicAttributes("javaCodebase", codebase));
When you run this example, you must supply the URL of where the class file Flower.class has been installed. For example, if the Flower.class is installed at the Web server web1, in the directory example/classes, you will run this example as follows: 
#java SerObjWithCodebase http://web1/example/classes/
pink rose
Afterwards, you may remove Flower.class from your classpath, and run any program that looks up or lists this object.

Previous | Next | Trail Map | Java Objects and the Directory | Storing Objects in the Directory