A Light-Weight Broker for GUI Applications

Internal event transaction: Internal events are transferred from a UI object to a Container object with an identifier (event-name) for the event and data-name on GUI components to get. Our architecture gets input data from a GUI component on a UI object using its data-name at first, and then shared data are updated automatically. After that, a required operation for the event-name are performed to a Model object defined previously (Figure 5).

Figure 5: Internal event transaction

An external behavior for a JavaBeans component is realized as access transfer to properties of a Model object or a UI object from external and event notification to external via a Container object.

INTEGRATED DEVELOPMENT TOOL BEAMBUILDER
A tool, in which BeaM components can be developed along with BeaM architecture visually, is required because components are generally integrated visually using RAD tools which are based on the WYSIWYG philosophy [7]. BeaMBuilder is a tool for developing BeaM components. ModelBuilder (for Model), UIBuilder (for UI) and Integrator (for Container) in BeaMBuilder give functions for each kind of objects. Figure 6 shows this development model.

ModelBuilder: ModelBuilder helps developers to develop Model objects. Developers determine a data-name for a Model object with shared data in data definition. ModelBuilder generates necessary program codes for data sharing and store the information about shared data in ModelInfo objects.

UIBuilder: UI objects can be designed visually using UIBuilder. Developers declare to keep watch on shared data in Model objects using data-name for UI. UIBuilder generates necessary program code for data sharing. Internal events are defined after event-names are defined for events from GUI. The information about shared data and internal event are automatically stored in UIInfo objects.

Integrator: Using this, developers can get the information about shared data from ModelInfo and UIInfo, link shared data to Model objects and UI objects visually, and describe transaction for noticing an internal event from UI objects. Based on these operation, Integrator generates the codes for Container class (ConcreteBean class in Figure 2) and stores properties and events to show as JavaBeans components, in BeanInfo objects.

EXAMPLE OF DEVELOPMENT AND ITS EVALUATION
Through an example, we will show the method for developing GUI application components based on the BeaM architecture by BeaMBuilder, and also the advantages for correction and extension against existing methods. We adopted JBuilder2.0 [8] of Inprise Corporation as a comparative target.

LoginFormBean along with JavaBeans framework is a Bean of which functions in AuthenticatorBean [9] are simplified. LoginFormBean is used for entering ID and password. It has an id and a password as the property, and its access methods are made public (Figure 7).

Figure 7: GUI image of LoginFormBean

In the existing method, for such modification, developers must modify access methods for the properties of id and password (Figure 8). These access methods are not modified in changing the design of GUI. In the result, it becomes difficult to customize GUI or ALP in each. If BeaMBuilder is used, developers only determine the data- name (UIDataName) same as before changing by UIBuilder, and they do not have to modify Model objects for ALP at all. Developers can visually determine data- name for the property of each GUI component by UIBuilder, so it is easy to change GUI application components.

public void setPassword(String password) {

this.password = password; // set a new value

// update the output to GUI

jPasswordField1 setText(password);

}

public void setId(String id) {

jComboBox.setSelectedItem(id);

if (!jComboBox.getSelectedItem().equals(id))

jComboBox.addItem(id);

this.id = id;

}

In Figure 9, we compared JBuilder2.0 with BeaMBuilder about the number of modified lines in these change. Based on these results, using BeaMBuilder, developers may need to modify linking definition in Container objects in changing and modifying the one GUI. However, because linking definition is independent between Model objects and UI Objects, developers do not have to modify the other objects.

Figure 9: Comparison of modification

Coordination of output data
Referring above, property "password" has to update not only for direct input from users to GUI but also for other input from system in LoginFormBean.

If applications are carefully designed for interaction between internal data of components and output to GUI, this problem can be avoided. However, developers do not have to take care of coordination between Model objects and UI objects about shared data. Because UI objects always keep watch the status of shared data.

Multiple Views for ALP
In existing methods, the ways for providing multiple GUIs for ALP in application components are only follows: developers have to change the description of transaction for putting out to GUIs in application components, or make GUI and ALP independent and register another components, which put out data to multiple GUIs, as an event listener for changed data. For example of LoginFormBean, developers have to add the lines such as Figure 10 in adding new output to GUI. However, it is necessary to modify to receive the updating result on another shared data, so it costs too much both to find programming codes to modify and modify appropriately

public void setPassword(String password) {

this.password = password;

// existing output to GUI

jTextField2.setText(password);

// add new definition of output to GUI

logIndex++;

logTextArea.append(logIndex + ">" + password);

}

If those components are BeaM components, unique Model object is not necessary to aware of the existence of UI objects and notify automatically updating message. Therefore, developers can define multiple UI objects easily. For example of LoginFormBean, in case of adding output to GUI similarly, developers can only develop new UI objects, and change (add) shared data and linking definition of internal event in LoginFormBean (Figure 11).

public class LoginFormBean extends BeaMContainer {

public loginFormBean() {

super();

// binding data name

addDataName("Login_PASSWORD", "PASSWORD_Text");

LoginFormUI ui = new LoginFormUI((BeaMContainer) this);

// adding new output to GUI

LogTextAreaUI logui = new LogTextAreaUI((BeaMContainer) this);

setBeaMUI((BeaMUI) ui);

setBeaMUI((BeaMUI) logui);

}

}

Addition of new UI objects to existing BeaM components with necessary linking definition can be performed visually and easily using BeaMIntegrator.

Figure 12: Comparison of Addition

In Figure 12, we compared JBuilder2.0 with BeaMBuilder about the number of modified lines in above adding GUI. From these results, using BeaMBuilder, the Model object and the UI object are not directly aware of each other and the Model object, only one object in a component, can depend on multiple UI objects via Container objects. Therefore, it is easy to plug GUIs dynamically, or display same data to multiple GUIs at the same time.

Runtime Performance
Applying BeaM architecture to GUI applications, the runtime performance becomes lower instead of reusability. To evaluate the degradation of the performance, we measured the execution time by automatically repeating the fixed number of sequences of actions, i.e. entering values, firing LoginEvent and clearing the values. The result is shown in Table 1. Referring this, the difference is comparatively small, so BeaM has no performance problem for practical usage.

Table 1: Runtime Evaluation

CONCLUSION
In case of developing GUI application components along with BeaM architecture, the information of data to be shared and internal events are required in developing Model objects and UI objects. Therefore, it is necessary to consider about what kind of compound components including GUI is important, and ALP should be included.

In BeaM components, all of internal data are mediated via Container objects, so the performance becomes clearly worse than the components, which ALP and GUI depend on each other. But, by our evaluation, this rate is comparatively small. Therefore, our approach for Light-Weight GUI Broker is effective in practical usage.

We have to inspect how much application developers can get the effects of lowering costs with correcting and extending.

References
1. R. N. Taylor and G. F. Johnson: Separations of Concerns in the Chiron-1 User Interface Development and Management System. Proceedings of INTERCH'93, pp.367-374, 1993
2. D. McMahon: Rapid Application Development with Visual Basic 6 (Enterprise Computing). McGraw Hill, 1999.
3. The UIMS Tool Developers Workshop: A Metamodel for the Runtime Architecture of an Interactive System. SIGCHI Bulletin Vol,24, No.1, pp.32-37, 1992
4. G. Hamilton: JavaBeans 1.01 Specification. Sun Microsystems, 1997.
5. E. Gamma, R. Helm, R. Jphnson and J. Vlissides: Design Patterns. Addison Wesley, 1995.
6. R. Orfali, D. Harkey and J. Edwards: The Essencial Distributed Objects Survival Guide. John Wiley & Sons, Inc., 1996.
7. R. Englander: Developing Java Beans, O'Reilly, 1997.
8. Inprise: Borland Jbuilder. Available at http://www.borland.com/jbuilder/.
9. Sun Microsystems: HotJava HTML Component. Available at http://java.sun.com/products/hotjava/bean/.