Extending Java Beans to support a Compound Document Model: Project Verdantium

This is a paper that I wrote years ago for the OOPSLA conference as a representative of Arizona State University. It was rejected for publication mainly due to some of the comments it made about XML. My more recent comments/observations are in brackets: "[ text ]".


Extending Java Beans to support a Compound Document Model: Project Verdantium

Thornton Green
Arizona State University



ABSTRACT
Client-side visual Java Beans are poorly suited to the implementation of document-level software components such as text editors. This reduces the applicability of visually displayed Beans, limiting the client-side API primarily to a means for interchanging widgets between different integrated development environments (IDEs). By using an alternate API (Verdantium) for the embedding of beans in a visual context, clients-side code can implement a full compound document display model while leaving server-side APIs (Enterprise Java Beans) and the fundamental bean property model unchanged. Fully functional applications (i.e., word processors, illustration programs, equation editors, etc.) can be implemented as individual software components that can either run independently or be embedded in other applications using the same API. [Java Beans hasn't changed much since this was written; all of this is still true today]
Keywords
Component software, compound-documents, embedding, Java Beans.
1. INTRODUCTION
When Sun introduced the original container application for visually embedded Java Beans [5, 14, 16 18], the Bean Box, it included as sample components a couple of buttons, a molecule viewer, and some other components with a similar level of sophistication. Since then, little has changed. The APIs introduced by the Bean Box have been used as a way to build applications from simpler widgets in a development environment, but have not led to the widespread sharing of visual components between Java applications outside of the software development world. The term “widget” refers to a subclass of java.awt.Component (or its equivalent in another framework). This paper sometimes uses “widget” instead of “component” so that the term “component” can be used in the context of component software.

To understand the problem, one must first answer the question, “what is a Java Bean?” There are three different senses in which the term “Java Beans” tends to be used:









* As a programming standard for specifying “get” methods, “set” methods, property change events, etc [18]. The resulting components can be visually manipulated regardless of whether the have GUIs. For instance, a ComboBoxModel can be manipulated in Symantec Visual Café [22].

* As a server-side API for interacting with transaction environments and legacy code (Enterprise Java Beans) [16].

* As an API (on the client side) for subclasses of java.awt.Component to be read by the Bean Box (or similar program) from a jar file.


It is the latter of the three that creates problems for document embedding. Container applications that emulate the functionality of the BeanBox are difficult to write. Further, pure Java implementations of bean containers have inherent display problems. Many visual beans are “heavyweight” widgets, making it difficult for the pure Java container app. to superimpose a resize widget over the top of the bean.

Support for native or legacy file formats is lacking in the visual beans’ persistence standards. A class written for the Bean Box can serialize itself by implementing one of two interfaces, Serializable or Externalizable. Neither of which can support foreign file formats, unless they are object-based. This means that for example a text editor bean would need a second entirely separate persistence mechanism in order to load or save plain text files saved on the local disk. There is also no built-in mechanism for two beans to support the same persistence format. For instance, a PDF distiller bean can not serialize itself in such a way that the serialized format will be read by the free PDF reader bean when opened. Instead, the identity of the object’s class (in this case the PDF distiller bean) is “hard-coded” into the persistent data. When the file is loaded from persistent storage, the hard-coded class is used to read the object data. [Sun effectively deprecated Externalizable for XML object persistence, and uses a new system for XML. Nevertheless, the above is still true for non-XML formats.]

The way that beans are embedded into a container also presents a number of less fundamental problems that nevertheless present a series of practical difficulties. One of them is the use of subclassing of AWT components (i.e. widgets) to create beans. One of the original articles on the JDK 1.1 event model, [17], states “subclassing should be reserved for circumstances where [AWT] components are being extended in some functional or visual way.” Java Beans do not adhere to this principle. To make a bean that can be displayed in the Bean Box, the developer must subclass a widget regardless of whether she intends to extend the base widget in a functional or visual way. To quote this same page again, subclassing of AWT components “does not lend itself well to maintaining a clean separation between the application model and the GUI because application code must be integrated directly into the subclassed components at some level.” To be fair, the latter quote is referring more to using subclassing to handle events. However, it would also seem to apply to subclassing widgets in order to use them as visual beans. Any methods that talk to an interface implemented by the bean or to the bean’s “get/set” methods must necessarily go through the subclass of the widget, and can not be routed directly to the application code.

Because the APIs for visually displayed beans were created with the assumption that heavyweight widgets could be used, there is no unified API support for beans that are visually transparent. This makes it difficult for a text label bean to overlay (with a transparent background) the display content of a graphics bean with predictable results. Unfortunately, even the most basic presentation software requires this capability from its components. For instance, imagine how ugly a Microsoft Powerpoint presentation with a gradient-filled background would look if all the text labels had individual opaque rectangular backgrounds of a single color. As a practical matter, transparency support is necessary for getting useful results from visual components in a variety of situations.

Multi-page printing also presents a problem from a practical perspective. A Java Bean has one method, print(), with which to print itself into a graphics context. Unlike the APIs generally available to applications, the print() method does not support multi-page printing because it is a widget-level operation as opposed to a document-level operation. This gives the writer of the bean two choices: restrict the bean to something that only prints single pages, or implement a custom set of printing routines entirely separate from the Beans APIs.

The ability to read previous versions of the serialized state of a bean can be difficult to accomplish. The Serializable and Externalizable interfaces attach versioning information to the persistent state of a class based upon the bytecode information of the classes being serialized. If the bytecode of the class changes even slightly, older serialized files are no longer compatible. This can be remedied to an extent by defining the serialVersionUID field of each class. This will make the class able to read serialized information made by any other version of the class using the same serialVersionUID. However, this does not in itself solve the versioning problem. The class must still read a set of objects from a linear stream, attempt to ascertain which version of the software these objects refer to, and employ some type of filter to derive meaningful data from the object stream. Filtering data from a linear stream of objects can be difficult because in general there are no tags indicating what instance member name each object of the stream belongs to. As a result, it may be very difficult to derive the proper meaning from the object stream when two previous versions of the class had similar but not identical formats, and several instance members of the same class. [XML persistence using Serializable no longer seems to be using serialVersionUID.]

2. THE SOLUTION
Verdantium, a prototype API based on a set of software components the author developed to support his Ph. D. dissertation [10], extends client-side beans by implementing a compound-document model for visual components. The idea behind this model is to be able to construct complex documents by having a series of software components (beans) working together to represent the document’s various parts. For instance, a word processor and its equation editor can be separate beans that cooperate to allow the user to insert equations into a paper that she is editing. Instead of having very large monolithic applications as illustrated in Figure 1, a series of smaller beans cooperate to replicate the functionality typically seen in large applications. The construction of documents using components is more flexible because components for editing different parts of a document can be added and/or interchanged.


Figure 1 An example of modern software with all of its toolbars turned on. Taken from a screenshot of a 800 x 600 display. Note the amount of functionality that has been packaged in a single monolithic application.

Verdantium’s document model is implemented using the Model-View-Controller (MVC) philosophy. That is to say, the user interface for a certain kind of document is kept separate from its application logic [7]. Beans that are displayed in the Bean Box are subclasses of a view class, with no inherent support given to the underlying model. The VerdantiumComponent by contrast is a Java interface implemented by the model class, with the GUI stored in a separate object (though one may optionally integrate the two). The major design principles supporting the use of an interface are flexibility and pluggability as noted in [4]. Components based on interfaces are more flexible because they can extend any chosen base class, and they are pluggable in the sense that one implementation of an interface can be replaced by another that uses the same methods. One important aspect of the flexibility of using an interface is that the VerdantiumComponent does not need to subclass a widget. Instead, the user interface of the VerdantiumComponent is the Swing JComponent returned by the VerdantiumComponent’s getGUI() method.


package verdantium;


import javax.swing.*;
import java.awt.*;
import java.awt.datatransfer.*;

public interface VerdantiumComponent extends
EtherEventHandler
{
public JComponent getGUI();
public void handleDestroy();
public DataFlavor[]
getPersistentOutputDataFlavorsSupported( );
public void loadPersistentData( DataFlavor flavor ,
Transferable trans );
public Transferable savePersistentData(
DataFlavor flavor );
}

Figure 2 The definition of a VerdantiumComponent.


The defintion of a VerdantiumComponent is as given in Figure 2, where EtherEventHandler is a Verdantium-defined interface for handling scriptable events. The simplest Verdantium components do not need to handle any such events, and can simply provide a stub implementation of EtherEventHandler’s only method. In addition, a VerdantiumComponent capable of being used in a compound document must have a null constructor, and implement one required method not shown in the listing above. The method’s signature is as follows:

public static DataFlavor[]
getPersistentInputDataFlavorsSupported( )


This method is called at runtime using the Java Reflection API. By studying the interface definition above, one can see that every VerdantiumComponent must do three basic things. It must present a Swing GUI, it must be able to handle its own destruction, and it must be able to support a persistence architecture based on AWT’s Transferable and DataFlavor concepts. Different components implement the same interface, but provide different behaviors. In other words, the interface provides the basis for implementing a Strategy pattern with respect to multi-flavor persistence and GUI presentation [9].

The mandatory use of Swing widgets to implement Verdantium GUIs greatly simplifies the implementation of the overall framework. Heavyweight widgets make certain kinds of controls difficult to implement because the heavyweight widgets tend to display in front of any widget that does not have a peer [This has generally been true since JDK 1.1, but Sun announced during a session at JavaOne 2007 that they wanted to change this. For essentially all current JDK implementations this is still they way Java Z-Orders heavyweight instances of jaav.awt.Component]. Because Swing widgets are entirely lightweight, there are fewer problems to contend with when attempting to design controls that resize or translate the widgets. For example, Swing already provides JDesktopPane and JInternalFrame classes that implement Multiple-Document Interface (MDI) resize controls on other Swing widgets in a robust manner.

2.1 Persistence Support
To support persistent storage, a VerdantiumComponent reads and writes Transferable objects in multiple data flavors. The use of the Transferable object in the loading and storing of persistent states can be thought of as similar to the Memento pattern in [9]. The Transferable object is the Memento, the VerdantiumComponent is the originator, and the persistence system is the Caretaker. The main differences are that the VerdantiumComponent does not have to deal with a constraint solver in the same sense as the systems that served as the motivation for the Memento pattern, and that the VerdantiumComponent contains support for through data flavors for creating Transferable data in multiple formats.

The data flavors that a component can support fall into two general types. The first type is object data intended to be read from or written to a Java object stream. This allows the component to use the standard Java Beans persistence mechanism with Serializable objects. However, there is an important semantic difference between Verdantium’s object serialization and that in client-side beans. Client-side beans tend to serialize data from the widgets they inherit from, including the full view hierarchy. This has two problems. First, Swing widgets tend to store a very large amount of data to persistent storage. Much of this information is of little real use to the overall application. Second, Swing’s persistence format is still under revision as of Java 2. Verdantium components avoid these problems because they serialize the model, not the view. For instance a text editor component serializes the text of the document, not the details of the view hierarchy. There is a drawback in that the Verdantium component has to do more work to load a file than its bean counterpart. Sometimes a component written in Verdantium has to take a representation of a document and map it to an appropriate set of widgets and layout managers, or vice versa . However, the author feels that the benefits outweigh the drawbacks. [In recent versions of Verdantium the format for this has shifted from binary object streams (i.e. class ObjectOutputStream) to XML object streams. Newer versions of Verdantium also contain logic that map most implementations of Externalizable to XML. The author feels that Externalizable is much simpler, more elegant and more object-oriented than Sun's XML callback mechanism, and hence it makes sense to use the XML callback mechanism to bridge Externalizable into the XML format.]

The second general type of data flavor that Verdantium supports is raw data from a file stream. For instance, a text editor can read a standard plain text document as a set of bytes that have been loaded from an input stream. The Verdantium system has the responsibility of mapping the input file to an appropriate MIME type, and then sending this MIME type to the Verdantium component in the form of a DataFlavor object. The surrounding Verdantium system can determine if a component can read a particular file type by calling the getPersistentInputDataFlavorsSupported( ) method and then ascertaining whether the MIME type of the file is a match for one of the MIME types returned.

One drawback of this approach is that loading of persistent data fails if the Verdantium system maps a file to the wrong MIME type. This is similar to what happens in Microsoft Windows if a file extension is mapped to the wrong application. Some care must be taken to make sure that the mappings are complete and correct. Also, the particular mapping scheme that should be used seems to be highly platform-dependent. For instance Windows and Unix distinguish file types by using file extensions, while the Mac OS uses a special four-letter code stored separately from the file name [This has changed now that Mac OS X runs as a Unix variant]. How to unify the mapping schemes of all platforms under a single bytecode implementation is unclear at this time. The current version of the system runs on the Windows platform.

If a particular component is missing, Verdantium can query all other registered components and determine which component(s) can respond to an input file of a particular data flavor. To provide faster indexing, it also uses a series of hash tables to map data flavors to components, and to map file extensions to MIME types. This querying system provides an ability to interchange visual components that is not found in client-side Java Beans. One component can replace another if there is an appropriate mapping of MIME types. This gives developers greater flexibility in deploying components. Consider how Adobe Acrobat has been successful because Acrobat Reader, a free product, is able to read files of the same MIME type as the sold-for-profit Acrobat and Acrobat Distiller. Verdantium can replicate this kind of relationship more readily than client-side Java Beans.

2.2 Verdantium’s User Interface for Embedding
In order to provide appropriate support for embedded documents and take full advantage of JFC/Swing functionality, Verdantium uses a very different user interface than that exemplified by the Bean Box. One of basic problems in any compound document system is that of how the user interface distinguishes between the operations that can be performed on embedded documents. These operations fall into three basic types:


* Resizing the embedded document in the container.

* Translating the embedded document to different positions in the container.

* Editing the embedded document’s content (e.g. drawing onto an embedded paint program using the mouse).


Almost all embedding systems perform the resizing and translating of embedded documents by placing a border around the document that can be dragged with the mouse. Borders have some advantages. Large borders are easy for the user to find and drag with the mouse. They can also have distinct on-screen controls for translating as opposed to resizing. However, borders also have serious drawbacks. The display of borders moves the container document away from a WYSIWYG appearance. Borders also tend to obscure part of the document’s content. This can frustrate people attempting create complex documents because the display of borders while resizing can interfere with the user’s ability to determine whether the embedded component is the “right size” to fit neatly into its surrounding content.

Apple’s OpenDoc [1, 2, 8, 12] system uses two approaches to address this design problem: only place a border around the currently selected component, and use a really thin border. OpenDoc attempted to make resizing versus editing an embedded document as modeless as possible. That is to say, one doesn’t have to select a particular mode from a palette or a pull-down menu in order to switch from resizing to editing or vice versa. However, Apple the lack of modes also meant that there was no way to completely turn the border off. So to compensate for the fact that the selected component will always have a border (with the drawbacks that entails), OpenDoc displays a border that is about four pixels in width for translating the component. The drawbacks of this approach are that the border is very difficult for naïve users to select with the mouse, and is so small that even intermediate users who are not already familiar with OpenDoc would likely not recognize the border as a translation control.

Several container applications such as the BeanBox, Microsoft Office [13], and Symantec Visual Cafe [22] keep the concept that only the selected component has a border displayed for translating and resizing, but use a larger border with individual controls for different kinds of resize operations. The larger borders fix the selection and recognition problems, but make it more difficult to see a document in the context of the surrounding space. Also, the fact that one has to select an embedded component before resizing it creates inherent problems. Suppose the embedded component is a button. Does clicking on the button mean that a button-press event should be sent, or does it mean that the user wants to resize it? So many common components rely on single-click operations that using mouse-click selections to control the display of borders is not entirely practical outside of IDEs, which have separate “Design” and “Execute” modes that determine whether the embedded components respond to the mouse.

Verdantium takes a very different approach to the problem of how to distinguish resizing and translating from the editing of content. The Verdantium approach is based on the MDI window concept, which many users are already familiar with from their use of popular office applications. Translating a document equates to dragging the title bar of the MDI window, and resizing the document is performed by dragging the MDI’s resize control. The MDI control in the typical form found in other software is large enough that users can easily drag it and is familiar enough that users understand what to use it for, but it displays too large a border to work well in a variety of situations. To fix this problem, Verdantium requires that users accept a somewhat modal interface with the associated learning curve. The property editor palettes for the Verdantium container applications provide push-button controls for determining whether or not the MDI frames are displayed around the embedded components. The frames display differently depending on the mode of the pushbutton control (see Figures 3, 4, and 5). At the risk of sounding ridiculous, the author decided to use very simple names for each of the modes (such as “Move Mode”) to avoid names that throw too many long words at the naïve user (such as “Translate Mode”).



Figure 3 Simple components displayed in “Move Mode.”



Figure 4 Simple components displayed in “Resize Mode.”



Figure 5 Simple components displayed in “Edit Mode.”


Verdantium’s container app. MDI frames have one more important difference versus typical MDI implementations: Verdantium frames have transparent backgrounds (see Figure 6). This allows for Verdantium components to be used as semi-transparent overlays in a container application (thanks to Swing’s transparency support). There are a number of compound document scenarios where this is an extremely important capability. For example, the transparency support provides the means to lay text over graphics (see Figure 7). One drawback of this transparency implementation is that the Verdantium code tends to delve deeply into Swing’s Pluggable Look And Feel (PLAF) code in order to produce a subclass of JInternalFrame with the proper border and transparency characteristics. At least for the time being, this results in the container frame being hard-wired for a particular look-and-feel. The Java Look-And-Feel (JLF) is being used for the current implementation [this has since been extended to include Windows and Mac LAFs].



Figure 6 MDI container app. frames in Verdantium have transparent backgrounds, and take advantage of Swing’s transparency support. This allows the document creator to overlay non-rectangular shapes. A component can avoid the use of transparency by drawing an opaque background.



Figure 7 An example of why support for transparency is useful. In this illustration, a graphics component is displaying a curve, and an embedded text component that is rendering text over the top of the graphics. Note how the text is inside the curve, but the resize rectangle of the text component extends outside at the top corners.


2.3 Document-Level Printing Support
Unlike Java Beans, which only provides widget-level printing, Verdantium provides a document-level printing interface called BookPrintable. BookPrintable gives the component total control over the printing process from the time the user selects the “Print” command on the component to the time that the component decides the print operation has concluded. Verdantium also keeps the widget-level printing functionality from AWT / Java Beans. This means that there can be as many as two separate execution paths by which a Verdantium component may be printed (a document path and a widget path). The reason for this is that embedded components need to have a different printing protocol from the component that gets the original request. That is to say, there is a “master” component and there are “slave” components in the printing process, and the slaves (the ones embedded somewhere in the master’s document) do not get all of the privileges of the master. The master gets to select how many pages to print, and what will show up in each page at a document level. The slaves’ responsibility is to respond to calls to their GUIs’ print() method in a reasonable way. In most cases, the default implementations of the print() method supplied by AWT already work well enough to support the slave side of the relationship. The use of multiple paths of execution for printing allows a Verdantium component to properly support printing as either a stand-alone application or an embedded component.

2.4 Versioning
Support for persistent versioning is very important for applications software. Almost all applications have legacy file formats from previous versions of the software, and being able to interrogate these legacy formats in a useful manner helps to convince customers to spend money on regular upgrades. Versioning of serialized objects is also a tremendously difficult problem. Verdantium provides the ability for an Externalizable object to save itself in a more versionable way using an object-oriented version of a property list. The class’ implementation of the writeObject() method of the Externalizable interface creates this property list object, writes a series of objects to the property list with different property names, and then sends the property list down the stream to be serialized. The advantage of the property list is flexibility in dealing with versioning issues. For instance, an object reading persistent information from a property list can query the list to see if certain property names have objects associated with them. Also, different versions of a class can write data to different property names regardless of how or whether the schema of the class changed. The property list can then be interrogated on the read side to determine which set of property names is contained in the list. Another key advantage of the property list is that objects do not have to be read in the same order in which they are written. For instance the writeObject() may write the property for the number of items in a list after the list items because the list was read using an iterator. However, the readObject() method for the same class read the number of items first, and then loop through the property name of each list item using a simple for-next statement. The ability to arbitrarily order the reading of items from the property list greatly aides the ability to perform non-trivial versioning because the schema for the latest version of the class may not be well-suited to reading data in the order saved using previous versions of the class.

It may be useful in a future version of Verdantium to modify the existing property list system to serialize in terms of XML [20, 24]. XML would provide an ASCII representation of the object property files that could be analyzed using a standard text editor. This is a topic for future research. [This has been implemented in more recent versions. Serializing property lists to XML provides the best of both worlds. The file format is standard XML, but the object read/write system has the flexibility of object properties.]

2.5 Creating Actual Components
All of Verdantium’s capabilities would be useless if they made Verdantium components and Verdantium container applications impossible to write. In contrast to the complexity required to replicate the Bean Box, a great deal of work has been put into streamlining the number of lines of code required to construct simple Verdantium components. The Verdantium HelloWorld component currently requires 140 lines of code, including comments (not counting the optional class providing online help). The DemoContainerApp, an example class that demonstrates how to write a simple container application, currently requires 440 lines of code with comments (not counting code for an optional class devoted solely to providing online help).

3. Verdantium as a Document Model
Verdantium was created with the idea that a client-side component should be able to support all the functionality that a typical GUI application does so that the components can have wider applicability. The VerdantiumComponent revises and extends the Beans component model to support these features. Perhaps the most important of these extensions is the expanded support for persistence. Components in Verdantium can read and write files of any MIME type through a Transferable interface, or save and load Serialized objects to persistent storage. Assuming that the Verdantium system can map each file to an appropriate MIME flavor and load the raw data stream into a Transferable object, the component can support any number of file types simultaneously. Multiple components can share the same file type, allowing more flexibility in how they can be distributed. Finally, Verdantium makes it easier for Externalizable objects to be compatible with future versions of the software using alternate persistence formats.

Verdantium supports multi-page printing at the component level, allowing applications such as word processors and illustration programs to be written as components. The AWT widgets’ print() method is also supported for imaging embedded components to a particular rectangular region of the printed page. Some might argue that giving the component total control over multi-page printing makes it incompatible with use in a Java applet. However, multi-page printing can not be allowed in any form from an applet because an errant applet can request an arbitrarily large number of pages. Hence, the applet’s security manager simply would not allow a print request to be fully processed. Moreover, the browser can still perform widget-level printing of the applet through the standard interface. [This point is moot now that newer versions of IE have made it very difficult to write an HTML block that executes the Java Plug-In across all browsers (e.g. removing support for Netscape plugins). Applets are probably dead, and Verdantium is now really a framework for Java applications, and components pulled in from the network through the Verdantium Discovery system. Verdantium Discovery is probably a lot more reliable than using Applets anyway.]

Verdantium components can be used to build compound documents. Complete container applications can be written as Verdantium components in significantly less than 1000 lines of code, and structured using a robust MVC architecture. Because Verdantium code is based on Swing and the container functionality is based on JDesktopPane, the resulting GUIs are both stable and easy to use. Hopefully this will lead to a larger number of container implementations to be included with general-purpose applications such as illustration programs. Embedded components can fully utilize Swing’s support for transparency, allowing embedded components to act as transparent overlays.

One might argue that Verdantium is not compatible with many IDEs because of the techniques they use for building GUIs visually. The visual builders of many IDEs express GUI code in terms of the subclassing of java.awt.Container (or some subclass thereof), which is precisely what Verdantium was designed to avoid. In this case, there are two approaches that one might use. First, allow the model class and the view class to merge. That is to say, have the generated view class implement VerdantiumComponent. This isn’t a perfect solution, but it can work. The second is to express the entire GUI in terms of UI panes, and have each VerdantiumComponent create an instance of the appropriate IDE-generated UI pane class as a member and then return it using the getGUI() method. The disadvantage of this approach is that it may produce a series of independent pane classes where none may be necessary.

4. RELATED WORK
In many ways the environment that is architecturally the most similar to Verdantium is Apple’s now-defunct OpenDoc [1, 2, 8, 12] project. OpenDoc was a cross-platform compound-document model implemented using IBM’s System Object Model (SOM). OpenDoc components were typically written in a language such as C or C++ with a binding that allowed them to be compatible with SOM’s more sophisticated object model. The need to communicate with a separate object model through an API created extra work for the programmer and made components more difficult to write. Also, typical OpenDoc components on the Macintosh platform did not use a set of layout managers to automate GUI interactions as is often done with JFC/Swing or X-Motif widgets. For instance instead of using the equivalent of a JScrollPane to manage the GUI of a document, many OpenDoc components would have code to respond to each individual scroll bar action. This further contributed to the complexity of constructing workable OpenDoc implementations.

Among OpenDoc’s notable features were its cross-component scripting architecture, its support for embedded components, and its ability to have a component read and write files to arbitrary formats while still supporting embedding. One problem with OpenDoc was a lack of memory-protection to keep errant objects from overwriting each other. In particular, on the Mac platform there was no memory protection at all. On other platforms, components were protected from each other, but the objects that comprise a component could still compromise each other in that component’s memory space. Contrast this with the Java VM, where objects are not allowed to clobber each others’ memory. OpenDoc’s lack of memory protection meant that a single ill-behaved component could crash other components in a document, seriously affecting the robustness of the architecture. OpenDoc is no longer supported by its original vendors, and very little development of new OpenDoc components has been done in the past two years.

Java Beans [5, 14 16, 18], the standard component architecture for Java, is more robust than OpenDoc in the sense that the Java VM prevents ill-behaved objects from clobbering each other. Moreover, Java Beans are easier to write in many ways because the Beans object model is the same as that for the Java language. The use of Java layout managers automates many of the more complex tasks related to the GUI, allowing the developer to focus on those events that actually affect the domain logic of the component. The problems with client-side beans were discussed earlier in the paper. For the sake of brevity, they are not repeated here.

Object Linking and Embedding (OLE) is Microsoft’s environment for creating compound documents in the form of custom controls with a WYSIWYG appearance [11]. OLE uses Microsoft’s COM object model to provide an interface mechanism for components to communicate. Like OpenDoc’s SOM model, COM components are written in a language like C or C++ with wrappers that allow them to work in the COM model. OLE components also require a host application to support their display. Microsoft Office applications use OLE as a means to interoperate. ActiveX, a close cousin of OLE, provides an architecture for controls to be displayed on the web.

Aldus developed the Vamp environment as a compound-document implementation designed to streamline the development and maintenance of software components within the company, and to aid in the porting of code between the Macintosh and Windows platforms [6]. The architecture of Vamp was based on Model-View-Controller with the use of event-driven state machines to alter component states. Vamp allowed large programming teams at Aldus to be divided into smaller groups working on individual components. Reenskaug and Skaar [15] developed a documentation environment with a number of compound-document capabilities, and with the additional ability to collapse part of a document. Embedded components included class and method definitions. Netscape worked on a compound document extension to Java Beans two years ago [23]. However, little information has been released about this project.

Faustini’s Visual Java, an early ancestor of the Bean Box, provided a purely visual environment for building GUIs in a container application as mentioned in [21]. Not only were the GUIs visually built, but the algorithms tied to the GUI actions were also built from visual components. Visual Java used a data model based on the programming language Lucid expressed using an operator net concept. Each operator in the net was capable of running on independent threads of execution and could potentially operate in either a deterministic or nondeterministic fashion. The name “Visual Java” is now used for a different product. The closest environment to Faustini’s Visual Java today is Java Studio [19].

Improved persistence models for Java Beans have recently become a topic of much interest. One persistence standard seeing increasing use is XML [20, 24]. XML is an HTML-based language for representing object-oriented data [This sentence was one of the major reasons why the paper got rejected. Should I have written "HTML-like" instead of "HTML-based"? Should I have written "SGML-based" instead of "HTML-based"? Both HTML and XML owe their lineage to SGML. SGML is a meta-language that doesn't describe a particular format (i.e. how to define tags). HTML defines a format for part of SGML. XML also defines a format for part of SGML, and defines the tag format (e.g. use of angle brackets for tags) the same as HTML. As a result, XML loads directly into many browsers designed for HTML, but the browsers simply don't recognize the content of the tags. So XML was IMHO based on many tag format concepts from HTML, but the paper got rejected anyway.]. Objects are represented in XML by a set of tags that describe the states of each of the objects’ members. The XML format also provides a means to support versioning. A program can accomplish this by parsing the XML data to interrogate its format, and then converting the old format to match that required by the current software. One of the advantages of XML is that it is not dependent on a particular object model. XML data can be read and written by systems outside the Java architecture such as relational databases. Because XML is HTML-based, XML parsers can not read or write formats such as non-HTML plain text files or images. [As noted before, Verdantium now persists objects in XML].

XML can be used in a variety of applications. An example of XML’s flexibility is the Simple Object Access Protocol (SOAP) which uses XML as the basis of a wire format for remote method invocation using HTTP [3]. The Java implementation of SOAP has some architectural similarities to Verdantium in the sense that they both use Java interfaces as opposed to base classes to represent the fundamental object types of the system. The element types in SOAP are implemented using an interface hierarchy to provide the methods supported by each type of SOAP data. Instead of the properties list metaphor used by Verdantium, SOAP represents data as a linked collection of structured types: arrays, simple types, compound records, and object references. [It could be said that XML describes "nouns and verbs" but it doesn't describe any kind of "vocabulary". As a result, Verdantium has classes that scan the format of the XML file, and then determine which component should load it. In a sense, it answers the question, "which component speaks in this vocabulary?"]

5. ACKNOWLEDGMENTS
The author would like to thank all the people who made helpful suggestions about the architecutre: Dr. Edward Ashcroft, Dr. Timothy Lindquist, Dr. David O. Hestenes, Dr. David Halliday, Al Butkus, Pat Reany, and Dwain Desbien. I would also like to thank Dr. Tony Faustini, without whom I may never have discovered the Java language.
6. REFERENCES

[1] Apple Computer. Inside Macintosh OpenDoc Cookbook, Addison-Wesley, Menlo Park, CA (1996).
[2] Apple Computer. Inside Macintosh OpenDoc Programmer’s Guide, Addison-Wesley, Menlo Park, CA (1996).
[3] Chappell, D., “Simple Object Access Protocol (SOAP) and Firewalls,” Web Page, http://msdn.microsoft.com/xml/ general/soap_white_paper.asp
[4] Coad, P., and P. Mayfield, Java Design, Printice Hall, Upper Saddle River, NJ (1999).
[5] Feghhi, J. Web Developer's Guide to Java Beans, Coriolis Group Books, New York, NY (1997).
[6] Ferrel, P. J., and R. F. Meyer, “Vamp: The Aldus Application Framework,” Proc. ACM OOPSLA, 185-189 (October, 1989).
[7] Fowler, M., Refactoring, Addison-Wesley, Menlo Park, CA (1999).
[8] Fuller, J., and A. Meadow. Essential OpenDoc, Addison-Wesley, Menlo Park, CA (1996).
[9] Gamma, E., R. Helm, R. Johnson, and J. Vlissides, Design Patterns, Addison-Wesley, Menlo Park, CA (1995).
[10] Green, T., “Research Issues of Geometry-Based Visual Languages and Some Solutions,” Ph. D. Dissertation, Arizona State University, Tempe, AZ (1999).
[11] Li, S., and P. Economopoulos, Professional Visual C++ 5 ActiveX/COM Control Programming, Wrox Press, Chicago, IL (1997).
[12] MacBride, A., and J. Susser. Byte Guide to OpenDoc, McGraw-Hill, New York, NY (1996).
[13] Microsoft. “Microsoft Office”, Computer Software, Redmond, WA.
[14] Morrison, M. Presenting Java Beans, Sams, Indianapolis, IN (1997).
[15] Reenskaug, T., and A. L. Skaar, “An Environment for Literate Smalltalk Programming,” Proc. ACM OOPSLA, 337-345 (October, 1989).
[16] Sun Microsystems, “Enterprise JavaBeans Technology,” Web Page, http://java.sun.com/products/ejb/
[17] Sun Microsystems, “Java AWT: Delegation Event Model,” Web Page, http://java.sun.com/products/jdk/1.1/docs/guide/ awt/designspec/events.html
[18] Sun Microsystems, “Java Beans, Part 1,” Web Page, http://developer.java.sun.com/developer/onlineTraining/ Beans/Beans1/simple-definition.html
[19] Sun Microsystems, “Java Studio,” Web Page, http://developer.java.sun.com/developer/Books/ Graphics2/index.html
[20] Sun Microsystems, “Java Technology and XML,” Web Page, http://java.sun.com/xml/index.html
[21] Sun Microsystems, “Keynote Presentation,” Web Page, http://java.sun.com/javaone/javaone96/McNealy.html
[22] Symantec, “Visual Café,” Computer Software, Cupertino, CA.
[23] Vizard, M., “Pull over, Sun; Big Blue’s gonna drive,” InfoWorld, 19(8), 3-4 (Feb, 1997).
[24] W3C, “Extensible Markup Language (XML) 1.0,” Web Page, http://www.w3.org/TR/1998/REC-xml-19980210