4th International Conference on Principles and Practices ... - MADOC

missing object references in the decoding process, a Java source
interpreter can be applied. In fact, the interpreters of any scripting
language that can interact with Java virtual machine are suitable for
this task. The BeanShell Scripting Language [3], DynamicJava
pure Java source interpreter [8] and Jython [13] are examples.
Note that if a script-embedded XML text is used for argument
passing of Web services or remote procedure calls, classes defined
in the script do not need to be compiled and deployed in the
classpath at both the client side and the server side. This makes
applications more dynamic and flexible at runtime.
Every object written by the XMLEncoder uses a standard XML
schema. According to the schema, when an object graph contains
cycles or multiple references to the same object, a name, i.e., an
identifier is given to the object so that it can be referred to later. An
identifier is created using the id attribute, which binds a name to an
object instance. A reference is made to a named instance by using
an idref attribute in an element with the tag. In other
words, the XMLEncoder has its own name space.
However, users cannot know which identifier will be assigned to a
given object instance before the object instance is written by the
writeObject() method of the XMLEncoder. Hence, users cannot
write scripts to access the object instance in advance. Moreover, a
Java source interpreter has its own name space to maintain its object
pool. So, our mechanism provides a name mapping table to link the
two name spaces.
For example, when an object instance of the javax.swing.JFrame
class is written, our mechanism first looks for the name of the
instance in the name spaces of the XMLEncoder and the Java
interpreter and appends a Hashtable to map the two name spaces. It
then writes the script for the XML text, as shown in Figure 1. In this
way, users may write the following Java codes to persist a
javax.swing.JFrame instance referred by the variable f0:
… f0 = new JFrame(); …
encoder.getInterpreter().defineVariable
("frame1", f0);
encoder.writeObject(f0, script); ….
Thus, users do not need to know the assigned identifier of an object
instance before they write scripts.
3.2 Provision of a script-running capability for
the XMLDecoder
The standard XMLDecoder class is used in the same way as the
ObjectInputStream. When being instantiated, the XMLDecoder
simply reads the XML documents created by the XMLEncoder, and
parses the XML text to reconstruct the whole object tree. The API
document of the XMLDecoder describes that the readObject()
method can be used to read the next object from the underlying
input stream; however the description is not very precise. After
carefully reviewing the source code of the XMLDecoder class
provided in J2SE 1.4 or 1.5, we found that the readObject() method
just dequeues an object for a method call. Therefore, after the
constructor of the XMLDecoder class has been called and returned,
all object instances of the whole object tree have already been
created and initialized. That is, if users write the Java code
Object f = decoder.readObject();
to read an object, this method just returns a created object instance
from the front of the queue.
Note that, in the decoding process, a PersistenceDelegate cannot be
used because it is designed to control all aspects of an object’s
persistence for the XMLEncoder in the encoding process. In
addition, since the XMLDecoder parses the whole XML text
immediately after its constructor has been called, all additional
embedded methods, such as the linkLocalPool and runScript
methods depicted in Figure 1, will be executed during the
constructor’s running time. This, however, may cause a problem in
that, when a user wants to read an object instance from the
XMLDecoder, the decoding process actually runs the
corresponding script for the object beforehand.
To deal with this problem, our mechanism prohibits script-running
during decoding and records the object-script map in a hash table
for the Java source interpreter to enable script-running. Therefore,
the corresponding script is only executed when an object instance is
read by the user. In addition, the proposed mechanism also
establishes and maintains an object pool when decoding. As shown
in Figure 1, this is done when the linkLocalPool method is
executed.
…
…
frame1
//<SCRIPT LANGUAGE="Java">
//<!---------------------------------
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
frame1.addWindowListener(new WindowAdapter(){
public void windowIconified(WindowEvent e){
// do something
} });
//---------------------------------->
//</SCRIPT>
….
Figure 1. Linking object pool.
Mapping of
Name Spaces
3.3 Provision of a cache pool for the
XMLDecoder
The decoding process may take too long to instantiate certain
heavyweight objects, but providing a caching system for Java
applications is usually a feasible way to speed up the process. In
addition, for some special applications, a certain class may be
implemented as a Singleton design pattern. Nevertheless, the
current XMLEncoder/XMLDecoder paradigm cannot ensure that
an object will remain a true Singleton, i.e., two or more distinct
objects will not be allowed during the decoding process. To deal
with these problems, our mechanism supports an optional cache
pool to allow the XMLDecoder not to instantiate a new object, but
96