Can You Share JavaBeans?

The authors are at the Department of Computer Science at Virginia Tech. They can be contacted at begolej @cs.vt.edu, [email protected] .edu, and [email protected], respectively.

A JavaBean is simply a component that conforms to the bean specification (http://splash.javasoft.com/beans/ docs/beans.101.pdf). Beans communicate with each other through the use of properties, which are "named attribute(s) associated with a bean that can be read or written by calling appropriate methods on the bean." Typically, a bean exposes its state through its public properties. A property is declared by matched get and set methods. For example, an object can expose a property named background by simply providing methods named getBackground and setBackground with appropriately typed return values and parameters. Using Java's Reflection package, JavaBeans allow dynamic querying and setting of properties at run time. This means that users (or another bean) can discover and modify a bean's properties, which may in turn affect the appearance or behavior of the bean. The JavaBeans specification encourages developers to not only expose attributes as properties, but also to provide notification of property changes to registered listeners. When a property changes, a bean can generate a PropertyChangeEvent describing the change, and deliver it to registered listeners. A property that fires such an event is called a "bound property," because its value can be bound to a property of another object. By exposing the application state as bound properties, JavaBeans can easily become collaborative.

Collaborating Beans

With minimal run-time support and some discipline on the part of the bean programmer, most JavaBeans can be made collaborative. Our approach to collaboration is based on a replicated architecture, where each collaborator maintains a copy of the shared data. The JavaBeans mechanisms described in the previous section give us the necessary tools to replicate component state at the granularity of properties. Because the JavaBeans framework can dynamically query and set properties, you no longer need to encode state changes in a message protocol to be explicitly relayed to replicas. Instead, the framework can automatically extract the necessary information from a bound property's change notification and construct a message for distribution. Using this approach, we have created a collaborative JavaBeans environment called "Sieve," shown in Figure 1 (available at http://simon.cs.vt.edu/ sieve/ and from DDJ; see "Resource Center," page 5). Sieve listens for property changes from each bean on the workspace and, when a PropertyChangeEvent is generated, Sieve packages it in a message and sends it to the corresponding replicas. When such a message is received, the local replica of the changed component is found, and the changed property is set to the new value.

Latecomers are brought up to date by replaying the record of property changes. Replay time is minimized by keeping only the most recent property changes. We prefer this to the alternative of sending a copy of a shared object using Java Object Serialization (JOS), because JOS requires specific development effort and pausing for serialization would disrupt a collaborator's work.

It is possible for two or more collaborators to generate potentially conflicting property changes. To resolve this, we use the strategy described by A. Karsenty and M. Beaudouin-Lafon in "An Algorithm for Distributed Groupware Applications" (Proceedings of the 13th International Conference on Distributed Computing Systems, IEEE Computer Society Press, 1993), where potentially conflicting operations mask, commute, or are order specific. Typically, property changes are maskable. That is, when two operations occur in sequence, the result is the same as when only the last change is applied. Examples of typical maskable properties are color, length, position, and size. Maskable properties are handled by ensuring that only the last property change is applied to each replica.

In some cases, property changes are not maskable. They may be commutative, where the result of applying a series of operations is the same regardless of the order; or order specific, where the final state depends on the order. For both cases, component developers must be aware that the component will be shared. Instead of firing a simple PropertyChangeEvent, the component must generate a specific type of event that is recognized by the Sieve environment, and must handle potentially conflicting events. This can be trivially implemented by not applying the change locally until the corresponding message returns. More efficient algorithms are known, such as the distributed operational transformation algorithms described by C. Sun and C.S. Ellis in "Operational Transformation in Real-Time Group Editors: Issues, Algorithms, and Achievements" (Proceedings of the ACM Conference on Computer-Supported Cooperative Work, ACM Press 1998).

Many useful collaboration-unaware components may be quickly developed and shared with our approach. For example, we implemented a collaborative wrapper for the HotJava Bean component that consists of less than 100 lines of code. Much of that code is to create the interface and combine the subcomponents of the HotJava browser. Example 1 shows the code that is needed to share this browser bean. Thus, little work is required to create a collaborative version of a powerful web browser. For some components, however, property changes may not provide sufficiently fine granularity. Consider a component that implements a simple text editor. One approach to sharing it would be to expose the entire text content as a property. Any keystroke that changed the content would then cause a property change, and the entire content would be propagated to all replicas. This approach might be sufficient for small chunks of text, but would not be desirable once the content grew to more than a few words. A better solution is to send only a description of each change. JavaBeans encourages components to generate an event as notification of any such change. This event can be distributed using the same mechanism as a PropertyChangeEvent, and if it contains sufficient information, a collaboration-aware wrapper can merge the change into each replica's content. Component-specific collaboration support code must be written to handle the event, but the component itself remains collaboration unaware.

Conclusion

When a component's state can be efficiently defined by a finite set of bound properties, it can be shared with no extra development effort. A collaborative version of the HotJava browser illustrated that significant software components may be shared with little implementation effort. For those cases where collaboration-aware components are desired, mechanisms can be developed explicitly to create efficient collaborative components.

Available electronically is an HTML browser (see Browser.java) that combines the HotJava HTML components (available separately at http://www.sun.com/ software/ htmlcomponent/). Also available electronically you will find: TextBean.java, a simple text input bean; BrowserApp.java, a simple application that runs the browser; make-it.bat, a DOS batch file to compile the above java files; and runit.bat, a DOS batch file to run BrowserApp.

Acknowledgment

We gratefully acknowledge the support of the Department of Education under grant P116B60201 and the National Science Foundation under grants DGE-9553458 and REC-9554206.

DDJ