an Alternative Approach to Developing Highly Interactive ... - CiteSeerX

3 downloads 0 Views 215KB Size Report
Section 4 shows how the example application in Section 2 can be built with ..... In the AJAX approach, the UI definition is provided by HTML, and the UI logic is ...
OpenXUP - an Alternative Approach to Developing Highly Interactive Web Applications Jin Yu

School of Computer Science and Engineering University of New South Wales 530 Devonshire Ct. Mountain View, CA 94043 USA +1-650-8619166 [email protected]

Boualem Benatallah Regis Saint-Paul

School of Computer Science and Engineering University of New South Wales UNSW Sydney NSW 2052 Australia +61-2-93854767 {boualem,regiss}@cse.unsw.edu.au

ABSTRACT

There is an increasing demand in making web user interfaces richer and more interactive. Currently, there are two approaches aiming at improving web user interfaces. First, downloaded code in form of Java Applet or ActiveX can be executed in browsers. And more recently, AJAX (Asynchronous JavaScript + XML) leverages browsers' JavaScript engine to render user interfaces without reloading pages. Both approaches have some weaknesses. In this paper, we present an alternative approach to creating highly interactive web user interfaces. Our approach is based on the Extensible User Interface Protocol (XUP), a SOAP-based protocol for communicating events and incremental user interface updates on the web. On top of XUP, we have built a web user interface development framework, OpenXUP, consisting of a thin client and a server toolkit which offers a set of event-driven APIs. The framework allows for the rapid development of highly interactive web applications and services.

Fabio Casati

HP Laboratories 1501 Page Mill Road, MS 1142 Palo Alto, CA 94304 USA +1-650-2368437 [email protected]

them on the server in a centralized way. The trend in enterprise application development is the use of web browsers to provide access to complex and feature-rich applications (e.g. CRM, ERP) used in production environment. Ideally, web applications should have the same level of productivity as traditional desktop applications. By productivity, we mean how efficiently end users can perform their job functionalities. High productivity requires the applications to provide highly usable user interfaces. Specifically, this imposes the following requirements on the applications: •

High usability: users should be able to interact with a set of rich UI components equivalent to those found in desktop applications. This is the key to a high level of usability and productivity.



Secure client environment: the client-side environment should only execute safe UI code, without compromising the security of the end user's computer.



D.2.2 [Software Engineering]: Design Tools and Techniques – Modules and interfaces, Software libraries. H.4.3 [Information Systems Applications]: Communications Applications – Information browsers. H.5.2 [Information Interfaces and Presentation]: User Interfaces – Graphical user interfaces, Interaction styles, Prototyping, Standardization, User interface management systems. H.5.4 [Information Interfaces and Presentation]: Hypertext / Hypermedia – Architectures

Low latency: users expect fast response time from their applications. This implies the use of asynchronous mechanism to perform UI operations while computing in the background. In addition, UI updates should be applied incrementally, without slow and annoying page refreshes.



Consistent look and feel: web applications should use the same UI metaphors and conventions as desktop applications, to reduce the end user's learning curve. Essentially, this allows the end user to use the same set of interaction techniques to work with both web and desktop applications.

General Terms

From the developer's point of view, a development framework should include the following features:

Categories and Subject Descriptors

Design, Human Management

Factors,

Standardization,

Languages,



Familiar programming model with a rich UI toolset: the framework should include rich and high-level UI components, similar to those found in desktop GUI toolkits. Essentially, the developer should be able to develop web applications the same way she develops desktop applications.



Hiding the network complexity: ideally, the development environment should allow the developer to be oblivious of the deployment method. The burden of managing client/server communications should be handled by the runtime framework, not by the developer.



Centralized administration: this aspect is indeed one of the key motivations in building a web application rather than desktop one. This centralization reduces maintenance and

Keywords

User interface (UI) development framework / toolkit, thin client, XML protocol, web services

1. INTRODUCTION

The web infrastructure offers unprecedented opportunities for quickly deploying applications on a large scale, while maintaining Copyright is held by the author/owner(s). ICWE’06, July 11-14, 2006, Palo Alto, California, USA. ACM 1-59593-352-2/06/0007.

Figure 1. Example application: XCat deployment cost and provides immediate application updates. Additionally, executing the code at the server side might be needed for legacy or security reasons; hence dismissing the possibility of adopting a client/server approach. •

Homogeneous programming language: the framework should allow both UI logic and application logic to be programmed in a comprehensive environment with a homogeneous language; as a result, the developer does not need to master multiple programming languages. In addition, the developer should be able to program UI logic in traditional languages, such as Java and C#; this allows easier maintenance of large scale UI logic code.

These requirements are not particularly new or surprising. Indeed, the web development community has been trying to address them with different approaches, such as Java Applet and AJAX. These approaches have some of the characteristics mentioned above; however, we believe there is still a significant gap between these requirements and the current solutions. We will discuss at length the limitations of existing approaches in the next section, based on a concrete scenario. To satisfy the above requirements and overcome limitations in existing approaches, we propose a framework called OpenXUP. For developers, the framework provides a programming environment that closely resembles desktop applications. That is, rich user interface components, such as those found in Windows Forms and Java Swing, can now be used in building web applications. In addition, OpenXUP maintains one of the most important benefits of web applications - zero client-side administration, since all application code resides on the server side. The goal of OpenXUP is to provide a UI programming model that combines advantages in both web page-based applications and desktop applications. For end users, the framework aims at bringing web applications closer their desktop counterparts. That is, web applications built with OpenXUP will appear identical to desktop applications. In addition, OpenXUP's asynchronous event delivery and

incremental UI updates mechanism enables fast application responses without annoying page refreshes. Finally, the framework provides a safe client environment, without the common security risks arisen from client-side code execution. The outline of the paper is as follows: In Section 2 we present a motivating scenario; we also review the existing approaches and show that they each present some inadequacies in that particular context. We then describe the OpenXUP framework in Section 3. Section 4 shows how the example application in Section 2 can be built with OpenXUP. Finally, we discuss related work and conclusions in Section 5 and 6.

2. MOTIVATING SCENARIO

In this section, we present a motivating example and examine the various current web UI technologies that can be used to build it. We will show that these technologies have some limitations with respect to the set of requirements presented in Section 1.

2.1 XCat

To illustrate the requirements of a rich web UI environment, we show an example application, XCat, which is a hosted multibuyer, multi-seller e-commerce solution. XCat is typically hosted by an ASP (application service provider) or a marketplace operator and used by consumers (buyers) and retailers (sellers). XCat has two interfaces that deal with consumers and retailers respectively. The retailer part of XCat includes functionalities such as electronic catalog editing, order processing, and logistics. In this example we focus on the electronic catalog editing functionality, which allows multiple users within a retailer's organization to concurrently and efficiently edit their product information stored in server-side databases. It also has a workflow-based preview and approval process, which allows product managers to perform quality assurance on the accuracy of the product information. Since each retailer may have thousands of products, the editing, preview, and approval user interfaces must be very efficient. Without high usability, the data entry specialists and product managers' productivity may suffer, and

many of the retailer's products may not get into the electronic catalog on time. Hence, XCat should provide a rich UI experience analogous to that of desktop applications. Figure 1 shows the desired user interface for XCat. In this screen, the left hand side is a tree interface, containing a hierarchy of product categories; this allows efficient catalog navigation and selection. The right hand side is a tabbed panel, with two tabs showing the list of attributes and the list of products under the currently selected category. The products tab (not shown) also has scrolling and pagination control, allowing thousands of products to be displayed in an incremental fashion. To allow maximum efficiency and usability, the end user should be able to select a category by clicking on the tree node, using arrow keys, or typing the tree node's label while the tree component has the focus. Similarly, to expand a category, the end user may click on the "+" icon, double-click on the category name, or press the right arrow key. In addition, the product information editing interface should support full keyboard navigation. The end user should be able to go to a particular input field with keyboard shortcut (without using mouse), and traverse input fields via the tab key. This is the behavior that we would expect from a well-designed desktop application.

2.2 Using Existing Web UI Technologies

Traditionally, the UI front end of web applications is built in HTML with the aid of some JavaScript for data validation and action confirmation. We refer to this approach as the classic HTML approach. The major functionalities of XCat could be implemented using this approach. However, the usability is very low. Every user interaction results in a full page refresh, which is both slow and annoying. In addition, since many of the rich UI components are not available in HTML, end users need to perform many unnecessary steps to achieve the desired functionality. Finally, many of the tree navigation operations would involve roundtrips to the server. Ideally, once the category tree is filled with data, most operations should be performed locally at the client. To overcome these limitations, additional approaches have emerged to make the web UI richer and more interactive. Technologies such as Java Applet, ActiveX, and .NET Smart Client allow binary code to be downloaded and executed on the client side. Collectively, we call them the applet approach. With this approach, the usability is very high, since applets take advantages of the native desktop GUI. However, applet code contains UI code and some application logic, which needs to be downloaded to the client to be executed. So as the user interface and application logic become more complex, the file that needs to be downloaded becomes larger and larger. In addition, since XCat is an online application with rapid release cycles for new features, it will require frequent re-download of parts of the applet binaries. The applet approach also requires developers to maintain two pieces of code, one for the client side and one for the server side. In addition, developers need to take care of the communications between the applet and the server side using RPC facilities such as Java RMI or .NET Remoting, or by wrapping messages within SOAP or HTTP requests. Finally, the execution of downloaded code by the client may impose security risks to the end user's computer. Although both

.NET and Java have sophisticated security sandbox to restrict the execution of downloaded code, security remains to be a major concern. As a result, many end users choose not to install applets when prompted, even though the applets are certified by public CAs (certification authority). In addition, due to the same security concerns, many organizations do not allow the installation of downloaded code, with a few exceptions for well-known applications such as Acrobat PDF Reader and Macromedia Flash. More recently the AJAX (Asynchronous JavaScript + XML) approach has emerged to improve browser-based UI. Here, complex JavaScript is used to execute UI logic in the browser. It heavily relies the browser's JavaScript engine. A large portion of UI code is in client-side JavaScript, which makes asynchronous network calls via XML messages and then modifies client-side UI through HTML DOM. This approach improves user interactivity, since the JavaScript code is able to modify client-side HTML without reloading the entire page. In addition, since the XML messages may be sent asynchronously, users are not blocked from further interactions. This approach offers much better user interactivity than classic HTML. However, it still cannot compare with traditional desktop GUI in terms of interactivity and usability, since it is constrained by the capability of DHTML and browser's JavaScript engine. For example, it is hard to implement XCat's keyboard shortcut requirements. In addition, UI code is fairly scattered, as changes in the HTML DOM require corresponding changes in JavaScript, and still some UI code needs to be on the server side (e.g. page transitions). Although IDEs such as Microsoft Atlas do a good job in terms of hiding browser incompatibilities and providing packaged JavaScript UI components, the overall development cost is still very high. This is because large scale JavaScript programming (involving both UI behavior and application logic) is harder to maintain and debug than traditional programming languages like Java. In addition, developers have to master multiple languages: JavaScript and DHTML on the client side, and another language (e.g. Java, C#) on the server side. Note that the developers we are referring here are application developers, not UI designers who create HTML designs using graphical tools. Finally, since JavaScript code is viewable through the browser, developers may loose a portion of their intellectual property even with sophisticated obfuscation techniques, so for certain applications this solution is not very appropriate. Therefore, we see the need of an alternative approach that enables end users to experience rich desktop UI while at the same time allowing developers to program web UI the way they program desktop UI.

3. OpenXUP OVERVIEW

To overcome the limitations of the existing approaches, we propose an alternative UI development framework, OpenXUP, which brings web applications closer to desktop applications. A key component of OpenXUP is the Extensible User Interface Protocol (XUP) [15,16], a SOAP-based protocol for communicating events and incremental user interface changes on the web. We chose SOAP as the underling protocol because it is well-understood, and its implementations in different platforms are widely available. With XUP, user interface changes are

delivered from the server to the client as incremental updates, not one full page at a time, so end users will no longer experience slow page refreshes. In addition, UI events can be delivered from the client to the server asynchronously, so end users will find applications to be much more responsive.

The above is just an example to help introduce the concepts. OpenXUP is independent of the actual UI language. It places no restriction on the UI component set, or the attributes or events associated with each component. That is, OpenXUP can work with any UI model that has an XML-based representation.

On the server side, OpenXUP offers a set of event-driven APIs, which enable developers to implement sophisticated applicationspecific UI behaviors. The OpenXUP APIs are designed to be familiar, closely resembling the APIs from desktop GUI toolkits. In addition, since all application code resides on the server side, it makes web applications easier to debug and maintain, without the need to worry about issues from distributed computing.

Now we proceed with the concept of UI definition and UI logic. Basically, UI definition is a description of the user interface, specifically, the UI components and their properties. UI definition is typically coded in declarative languages such as XUL and HTML. On the other hand, UI logic contains code that handles UI events and communicates with application logic code. UI logic is typically coded in a programming language. For example, in Java Applet, it is Java, and in AJAX, it is JavaScript.

On the client side, OpenXUP takes advantages of the desktop computing power to enable a rich and interactive user experience for end users. The client fully leverages the rich UI capability offered by native desktop GUI toolkits such as Windows Forms and Java Swing. However, the client remains thin in terms of application logic; that is, no application code is executed on the client side. The client renders UI and processes native events, but leaves application specific logic to the server side. As for the backend infrastructure, web applications built with OpenXUP can leverage all existing backend components (EJB, CORBA, COM, etc.), since OpenXUP's server side is designed to run within existing web application servers.

3.1 Background

Before discussing the details of our framework, we need to provide some additional background information. We begin by introducing the concept of user interface model (UI model) and user interface language (UI language). A UI model is a representation of the user interface which the end user perceives and interacts with. UI models may have XMLbased representations. We call these representations UI languages. Common UI languages include XUL (XML User Interface Language) [14], XAML (Extensible Application Markup Language) [12], UIML (User Interface Markup Language) [9], and SUL (Simple User Interface Language) [8]. A UI model typically consists of a tree of UI components (e.g. buttons, panels), a set of events (e.g. mouse click), and a list of resources (e.g. button images, files to be downloaded or uploaded). UI components are usually described by a tree of XML elements, with the UI components mapping to XML elements and the properties (e.g. color, size) of the components mapping to XML attributes. Refresh Update

3.2 Framework Components

In order to illustrate how OpenXUP works, we first need to describe the different components that are part of the framework (Figure 2). Consistent with the Web architecture, OpenXUP is client/server-based and uses existing web protocols (HTTP and SOAP).

3.2.1 XUP Client

The XUP client has two main tasks: one is to manage the interaction with the end user (display UI components and capture UI events) and the other is to communicate with the server (transform UI events to XML messages and then send them to the server; receive UI updates in XML messages from the server and then render them). These tasks are performed by the view manager and the XML serializer. In addition, the XUP client is a thin client, just like web browsers; application developers do not write any code on the client side.

3.2.2 XUP Server

The XUP server processes event requests from the client and sends back component and resource updates in the responses. The server side includes application-specific code provided by application developers (XUP applications) as well as OpenXUP middleware components: the event dispatcher, the application manager, and the XML serializer. Note that the XUP server may host one or more XUP applications running concurrently. XUP applications provide desired functionalities to the end user through the client. Application developers use the set of eventdriven APIs provided by the server to process events and update the UI. An event handler is a piece of code (i.e. instance method) in the XUP application. The server invokes the application by calling registered event handlers upon receiving an event request from the client. Event handlers make up the bulk of UI code in an XUP application. Finally, the XUP server only handles user interface processing, leaving backend components intact. Therefore, all backend components in existing web applications can be preserved.

...... ......

Listing 1. UI model example (in SUL) Listing 1 shows an example UI model. The root of the UI model is a window; within it there is a panel which contains two push buttons.

3.3 Model / View / Controller Paradigm

The OpenXUP framework reflects a slightly modified version of the MVC pattern, popular with desktop-based GUI programming. As shown in Figure 2, the client maintains the UI model as well as the view, while the server side only maintains the UI model. On

ASP.NET server XUP server Startup message:

XUP client

Application name, supported UI model namespaces, ...

UI model

Application 1 …...

Application manager

Session 1

Session ID, initial UI model, ...

UI view

Subsequent messages: XML serializer Event, UI data resulting from end user actions

View manager

Updates to UI components, resources, and event selectors, or fault

…...

UI model Event handler 1

XML serializer

…...

Event handler 2

Backend components COM / ADO.NET …...

…...

…... Event dispatcher

Figure 2. Framework architecture and protocol messages

the client side, the end user manipulates the view, which in turn causes the UI model to be updated. On the server side, the application programmatically manipulates the UI model through event handlers (i.e. the controller in MVC). Through XUP protocol message exchanges, the framework automatically synchronizes the client-side UI model and the server-side UI model.

3.4 Location of UI and Application Code

Here we illustrate the differences between OpenXUP and the applet and AJAX approaches, in terms of the location of the UI definition, UI logic, and application logic. In the applet approach, both UI definition and UI logic are programmed, rather than declared. In case of Java Applet, it is in Java; and in case of ActiveX, it is in C++. In addition, both UI definition and UI logic are on the client side, while most of application logic is on the server side. However, the client-side applet also contains some application logic, in order to render the application data and communicate with the server side. In the AJAX approach, the UI definition is provided by HTML, and the UI logic is programmed in JavaScript. Similar to the applet approach, both UI definition and UI logic are on the client side, while most of application logic is on the server side. However, the client-side JavaScript also contains some application logic, in order to render the application data and communicate with the server side. In OpenXUP, the UI definition is provided by UI languages such as XUL or SUL, and the UI logic is programmed. In our approach, the UI definition is executed on the client side, but the UI logic is executed on the server side. In addition, application logic also resides on the server side. Essentially, this approach separates UI definition from UI logic and application logic. The client side renders UI definition and processes native UI events by leveraging the desktop machine's rich UI capability and computing power. In addition, the client is very secure since no application code is downloaded to be executed on the client side.

3.5 Protocol Messages

The runtime behavior of the framework can be described in three phases of protocol message exchanges (Figure 2). First, the end user starts by establishing a session with an XUP application. Second, the end user interacts with the application which causes events and UI updates to be exchanged between the client and the

server. Finally, the end user terminates the session with the application.

3.5.1 Startup

The client begins by sending a startup request, which includes the name of the application and a list of UI model namespaces supported by the client. The server locates the application through the application manager and creates a user session for the client. The server then transfers the control to the application which creates an initial UI model, including UI components, resources, and a list of event selectors. Then the server sends a response through the XML serializer, including the session ID used for identifying the client in subsequent requests and the initial UI model. The client receives this UI model from the XML serializer and renders its initial UI through the view manager. The UI model namespaces allow the client and server to negotiate the UI language to be used for the session.

3.5.2 User Interactions

After the startup phase, the end user interacts with the application by manipulating the UI view, which triggers native UI events. The view manager will capture those native events and send them to the server through the XML serializer. The client maintains a list of event selectors specified by the application. An event is sent to the server only if the event satisfies the event selection criteria defined by an event selector. Together with the event, a list of UI data is also sent. Those UI data reflect changes made by the end user to the UI components, such as text entered in a text box and a check box been unchecked. Upon receiving an event request, the server locates the XUP application and user session, and passes the event to the event dispatcher, which in turn calls all the registered event handlers for that event. Event handlers execute the necessary application logics (e.g. by calling some backend components) and update the UI model accordingly. The server then returns the UI model updates to the client. The UI updates include UI components and attributes changes. The UI components could be simple UI controls or complex UI containers. This approach allows applications to perform both micro and macro UI updates, eliminating end users' visual discomfort with frequent page refreshes as in HTML-based applications. The client receives the XUP response and then updates its UI components and the list of event selectors. After that the client directs the view manager to render the UI updates.

Because events are delivered over the network, to conserve network bandwidth, the client does not send certain types of highfrequency events, such as mouse movement.

3.5.3 Session Termination

There are multiple ways for an end user to terminate the session with an XUP application. First, a particular event on a UI component may be interpreted by the application as a termination notice. For example, a click event on a button labeled "Quit" may be used by the application to terminate the user session. Second, the end user may explicitly exit the application by instructing the client to send a "shutdown" request to the server. Finally, the server may close the user session due to inactivity.

3.5.4 Network Bandwidth Consideration

It may appear that XUP is a fairly verbose protocol, since UI events are sent over the network and there are many types of UI events. However, XUP has been designed to minimize the amount of network traffic due to UI events. First, XUP's event selector mechanism allows an application to select interested client-side UI events based on their event types. For example, an application may want to receive mouse events but not keyboard events from a button. The client will only send the events selected by the application. In addition, to filter events of the same type, XUP supports the concept of event masks, which further refine the event selection criteria. For example, for keyboard events on a tree node, an event mask may specify an event should be sent only if the "delete" key or the "return" key is pressed; so no other keystrokes will cause the client to send the event to the server. Moreover, XUP supports rich UI components which maintain state information. Therefore, many UI events are handled locally by the UI components themselves. For example, the tree component in our XCat example remembers its own content - the hierarchy of tree nodes. Therefore, once the tree is populated, expanding a tree node (clicking on the '+' icon) is entirely a local operation, without a roundtrip to the server. Of course, the end user has the option to force a remote operation in order to refresh the client-side product category tree. In this example, she may simply hold down the shift key while clicking on the '+' icon. This will cause the client to send a "tree-node-expanding" event to the server, and the application on the server side in turn will update the content of the tree component. Furthermore, simple data validations can be performed locally on the client side, without roundtrips to the server. For example, rich UI components may support input validations such as date format, number range, text length, and even regular expression patterns; all these can be supported by the UI components locally, without involving application code on the server side. More complex validations need to be handled at the server side. However, the same applies to the applet and AJAX approaches. For example, in XCat, adding a product item into the catalog involves checking against the backend product database; obviously this has to be done on the server side. Finally, in the applet (and AJAX) approach, it is true that the client does not send UI events to the server side. However, instead, the client sends and receives application data to and from the server. The application data are usually serialized application objects, either in XML or binary form. Therefore, the amount of

traffic generated by applets is comparable to the amount of traffic in XUP. The applet may cache application data on the client side. In XCat, the applet may cache the product items for a visited category, so when that category is revisited, it does not need to retrieve those products from the server again. However, this complicates the client-side logic, as the applet needs to manage data caching. Furthermore, the data cache may become stale as XCat is a multiuser application, so the product items may need to be retrieved from the server again anyway.

3.6 Application Development APIs

Our current framework implementation includes a Windowsbased thin client and an ASP.NET-based server toolkit. The server toolkit provides a few class libraries which contain a set of highlevel .NET APIs. The APIs are event-driven, closely resembling desktop GUI toolkits such as Windows Forms and Java Swing. Developers use these APIs to develop highly interactive web applications, without the need to worry about client/server communications or protocol level issues. The APIs consist of two layers: UI language-independent layer and UI language specific layer. We now discuss each of these layers and the motivation behind separating the APIs into two layers.

3.6.1 UI Language-Independent API

The framework offers a set of UI language-independent classes that provide a common abstraction for all UI components, events, and resources. These classes serve two purposes. First, they allow the framework to support additional UI languages via plug-in modules. Second, they allow application developers to write less UI language specific code. At the base of any UI model is the notion of component, which represents UI controls such as buttons and labels. For this purpose, the API includes a class called XComponent, which is abstract, and serves as the base class for all UI components. Components in a UI model form a tree structure, therefore XComponent allows developers to access and manage the tree (retrieve the parent or the children, add / remove children, etc.). In addition, this class allows the selection of UI events to be handled by the application. For managing UI events, what is needed is the ability to selectively handle client-side UI events by specifying an event type, so that the client only sends events selected by the application. This strategy allows for very efficient network event delivery. Furthermore, we need to denote whether events are synchronous or not; in fact, the client should be able to send the event to server in the background, without blocking the end user from interacting with the application. Typically, asynchronous events should be used when the corresponding handling code in the application takes long time to execute. For this purpose, the API includes a class representing the event selector. To register the application's event handling code, the event selector class allows developers to attach event handlers. An event handler is a delegate, which is a pointer to an instance method in a class provided by the application. Multiple event handlers may be attached to the same selector. When the server receives an event from the network, it will first identify the event selector, and then

sequentially call all event handlers attached to the selector. Note that the concept of event handler corresponds to "event handler" in Windows Forms and "event listener" in Java Swing.

3.6.2 UI Language Specific API

The UI language specific APIs extend from the UI language independent API described in the previous section, and model concrete UI languages such as XUL, XAML, and SUL. This twolayer design allows the OpenXUP framework to be independent of the concrete UI languages and APIs. Our current implementation supports SUL via a UI language plugin module, which includes a set of UI language specific classes for SUL. Similarly, supporting additional UI languages such as XUL and XAML only involves the creation of appropriate plug-in modules, and there is no need to change the source code of our framework implementation. In addition, with the appropriate XML representations, we may also directly adopt the APIs from desktop GUI toolkits such as Windows Forms and Java Swing. We also plan to create an HTML plug-in module to leverage existing web resources. The implementation should be relatively straight forward, since we can easily integrate the existing HTML browser technology into a plug-in module.

3.7 UI Templates

Applications use the APIs defined in the last two sections to create and modify UI components and to handle events. However, creating a large number of components in source code may be quite tedious. Therefore, the framework also offers a templating mechanism which allows UI components to be defined in XMLbased templates. A UI template contains a tree of UI components. In our XCat example (Appendix 2), the top level component is a window with ID "w-main". Within the window, there are other UI components such menu bar and panel. More sophisticated user interfaces consisting of multiple windows and many nested components can be defined in a similar fashion. An application may use as many templates as needed, for different parts of the application's user interface.

Of course, all client implementations should be fully interoperable with all server implementations. For example, an end user can use the Windows-based XUP client to interact with an XUP application written in Java, running in an XUP server inside a J2EE servlet container.

4. BUILDING WEB APPLICATIONS

In this section we show how XUP applications are developed. To illustrate the concepts, we will use our example application, XCat.

4.1 Application Development

Developers use the classes and APIs illustrated in the previous sections to build applications such as XCat. They typically use an integrated development environment such as Visual Studio.NET. Of course, they may also use text editors and command line compilers, since the APIs are packaged in libraries. For building UI templates, they may use our UI template viewer or their favorite XML editors. To implement a new XUP application, the developer performs the following steps:

4.1.1 Creating Main Application Class

The first step is to create a main application class that extends from XApplication, which is an abstract class provided by the framework. The main application class must implement the startSession() method, which serves the same purpose as the "main()" function in desktop applications. Within this method, the developer creates the initial UI model. She may use APIs to create the initial components; alternatively, she may load them from a UI template. In addition, she adds event handlers for the appropriate events. For example, when an end user connects to XCat for the first time, the application creates a login prompt UI component to ask the user to input login information. In addition, an event handler is added to handle the "dialog-closed" event from the login prompt. Appendix 1 lists the C# source code fragment for XCat.

4.1.2 Creating UI Templates

To further reduce application coding, an application may also define event selectors in the template; this allows declarative event selection. Furthermore, the application can define the event handlers in the template as well, by referring to the instance methods of some application objects. Essentially, this allows declarative event wiring.

UI templates allow developers to declare UI components, rather than creating them in source code. Developers may use multiple UI templates for different parts of the UI model. UI templates may simply contain UI components, or they may declare application objects and event selectors.

3.8 Implementation

Appendix 2 lists the UI template "catalog.xml", which is used to render the XCat's main window after the user logins in.

Currently the client is implemented in .NET; it can be deployed as a standalone Windows program or as a browser plug-in (i.e. .NET Smart Client). Since the client is a thin client, it needs to be deployed only once, not on a per-application basis. In addition, installation should be fast as the client has a small footprint, currently about 400K. The server is a toolkit running inside the ASP.NET web application server, offering a set of event-driven .NET APIs for application development. We also plan to implement a Java-based server toolkit running inside a servlet container; this will provide a set of event-driven Java APIs for developing highly interactive web applications.

4.1.3 Implementing Event Handlers

Event handlers are instance methods containing an application's event handling code. They typically call some application logic classes and backend components, and then update the UI model appropriately. Event handlers may also load additional UI templates to update the UI model. The bulk of the UI logic code in an XUP application is in event handlers, which are called by the server after receiving event requests from the client. This event-driven programming style allows easy separation of business logic from presentation logic.

In addition, the application logic classes and backend components called by the event handlers may come from existing web applications. This provides an easy migration path from traditional web page-based applications to OpenXUP. In our XCat example, we demonstrate two event handlers (Appendix 1), corresponding to two user interactions in the application. The first event handler processes user login and displays the main application window; and the second event handler processes category selection changes.



User Logging-in

After the end user fills in the account information and hits the "ok" button, the framework will call the registered event handler to handle the "dialog-closed" event. This event handler authenticates the end user, and then proceeds to display the main application window by loading the UI template "catalog.xml". After loading the UI template, the event handler fills the tree component on the left hand side of the split panel by retrieving product categories from a backend database. Finally, it adds another event handler to handle tree node selection change events. Note that the newly added event handler is asynchronous, so the client will send selection change events asynchronously.



Changing Category Selection

To view the attributes and products of the "Operating Systems" category, the end user selects the tree node "Operating Systems" (Figure 1). This action causes the client to send the following event: ......

Listing 2. "Selection-changed" event request Here, the event is "selection-changed", under SUL's event namespace. The event detail contains an SUL event attribute descendant, which specifies the ID of the newly selected tree node, "_ED7559A5" ("Operating Systems"). The server receives this event and calls the registered event handler which retrieves the attributes and products of the selected category from the backend database and fills them in the "Attributes" and "Products" tabs on the right hand side of the main window. Note that this event is asynchronous, so the client will not block end users from using the application, giving end users a more pleasant experience. We have made this event asynchronous because the code in the event handler may take a long time to execute.

4.2 Application Deployment

Deploying applications in OpenXUP is relatively straight forward. First, the developer compiles the application source code into one or more .NET assemblies (DLLs). Second, if a previous version of the application is still running, it needs to be shutdown. Finally, the developer copies the assemblies and UI templates into the appropriate directories specified in the server configuration. Note that during the deployment process, the XUP server does not need to be restarted.

5. RELATED WORK

RemoteJFC [2] is a distributed user interface toolkit based on the JFC (Java Swing) API. It has two components: the client is a viewer with Java Swing look and feel; the server contains application code, which uses an API that resembles JFC. The client side does not contain any application logic. Through the server API, the application code processes UI events from the client and sends UI updates to the client. RemoteJFC uses RMI for network communication, which is Sun proprietary and firewall unfriendly. In addition, it requires two-way RMI servers. When the client sends UI events to the server, the server behaves as a RMI server; when the server sends UI updates to the client, the client also becomes an RMI server. This architecture poses serious security problems. XWeb [3] is a system for supporting multi-modal user interactions on the web. It supports multiple modalities (speech, gesture, etc.) as well as multiple devices. However, its protocol, XWeb Transfer Protocol, modifies HTTP. This makes XWeb incompatible with common HTTP servers such as IIS and Apache and therefore severely limits XWeb's usefulness. ASP.NET Web Forms [4] provides an event-driven programming model to page-based applications. It is one step toward XUP's approach. However, it is still limited by the UI controls offered by HTML browsers. Moreover, in every protocol response, a full page is always returned. JavaServer Faces (JSF) [6] offers a Java-based event-driven API for developing web applications. Its default HTML / JSP based implementation is very similar to ASP.NET Web Forms, and therefore suffering similar limitations. JSF only standardizes on the API, so in theory it could be used with other UI languages. However, JSF still maintains the "page" concept, which is not ideal for highly interactive user interfaces. XForms [13] improves upon traditional HTML Forms by providing better client-side events and data validations. However, XForms inherits HTML's page-based model; that is, the response of a form submission either replaces the current form or the entire containing page. In addition, it only offers a limited set of user interface controls. Therefore, it is still hard to build rich web user interfaces with XForms. Macromedia's Flex framework [7] leverages the popular Flash client to render rich user interfaces. There is no browser compatibility issue, since Macromedia controls the Flash client technology. However, similar to AJAX, a large amount of scripting code (ActionScript, Macromedia's extension to JavaScript) is used to manipulate the UI. There are many mature remote display technologies, such as X11 [11], NeWS [1], DPS [5], VNC [10], etc. Comparing to XUP, these are lower level UI protocols, transporting bitmaps and low-

level primitives. For example, in X11, everything is based on bitmaps and windows; the protocol does not offer higher level abstractions such as buttons or scrollbars. Furthermore, these protocols have very high network bandwidth requirement, since typically every keystroke and mouse movement is transported over the network. Therefore, these protocols only work well in a local area network environment, where network resource is plenty. XUP works with high-level UI components, and it supports asynchronous requests for long server-side operations. Furthermore, it filters out high-frequency events such as mouse movements. Therefore, XUP is ideal for developing interactive web applications in both local and wide area networks.

public void start(XUserSession session) mSess = session;

// display the login prompt SInputPrompt loginPrompt = new SInputPrompt(); ...... // add an event handler to authenticate user // and display the main window loginPrompt.addEventHandler( new XEventHandler(onLoginPromptClosed), SDialogClosedEvent.QUALIFIED_TYPE); } // event handler for dialog-closed event private void onLoginPromptClosed(XEvent ev) // authenticate the user ...... // display main window if successful

6. CONCLUSION

The OpenXUP framework brings web applications closer to their desktop counterparts. It offers richer and more powerful UI components while maintaining the zero client administration advantage.

// attach components in the template to the UI tree mSess.componentRoot.addChild(temp.component); // get a handle of the category tree component STree catTree =(STree) mSess.component("tr-category"); // fill the tree with categories from // backend database ...... // add an asynchronous event handler for // category selection event catTree.addEventHandler( new XEventHandler(onCatTreeSelectionChanged), SSelectionChangedEvent.QUALIFIED_TYPE, true); ......

For developers, OpenXUP offers an efficient UI development environment, similar to their familiar desktop GUI toolkits. With OpenXUP, developers no longer need to constantly tweak HTML and JavaScript to support complex user interfaces. OpenXUP's event-driven API allows developers to rapidly create rich web applications without concerning about network communication issues.

7. APPENDIX 7.1 Appendix 1: C# source code fragment // application main class public class XCatSrv: XApplication { public override bool startSession( XUserSession session, ......) { ...... // create a new catalog editing session XCatSess catSess = new XCatSess(); catSess.start(session); return true; } ...... } public class XCatSess { private XUserSession mSess = null;

{

// load main window from a UI template UITemplate temp = templateLoader.load("/catalog.xml");

With OpenXUP, end users will no longer experience frequent "page refreshes" as commonly seen in today's web applications. Users will perceive much faster response time since UI updates are delivered to them asynchronously and incrementally, rather than one full page at a time. In addition, since OpenXUP improves the usability of web applications, end users will achieve much higher productivity. Finally, OpenXUP offers a secure client environment since the client only processes UI definitions, and no application code is executed at the client side.

Finally, we observe that OpenXUP is targeted at applications that are highly interactive with complex UI logic; it is not designed to replace all existing web applications. HTML and browser are well-suited for applications that involve large amount of textual information with few user interactions. Similarly, desktop applications and applets (ActiveX, Java Applet, etc.) are more appropriate for graphics-intensive applications, where mouse tracking is required (e.g. video games, image processing applications).

{

} // event handler for category selection-changed event private void onCatTreeSelectionChanged(XEvent ev) { STree catTree = (STree) ev.component; STreeNode selectedNode = null; lock (mSess) { selectedNode = catTree.selected; } // retrieve products and attributes of the selected // category from backend database ...... // update UI lock (mSess) { // fill the Attributes and Products tabs of the // selected category ...... } } ...... }

7.2 Appendix 2: UI template "catalog.xml" ...... ......

...... Name Display Name ......

8. REFERENCES

[1] Gosling, J., Rosenthal, D.S.H., Arden, M.J. NeWS Book: An Introduction to the Network / Extensible Window System. Springer Verlag, March 1990.

[2] Lok, S., et al. A Graphical User Interface Toolkit Approach to Thin-Client Computing. In Procs of WWW 2002 (Honolulu, HI, May 2002).

[3] Olsen, D. R., et al. Cross-modal Interaction using XWeb, In Procs of UIST 2000 (San Diego, CA, November 2000).

[4] ASP.NET Web Forms [5] Display PostScript Handbook, Adobe Systems Inc.

[6] JavaServer Faces [7] Macromedia Flex [8] SUL [9] UIML [10] Virtual Network Computing (VNC). [11] X Window System. [12] XAML

[13] XForms 1.0 [14] XUL [15] XUP - Extensible User Interface Protocol.

[16] Yu, J. and Benatallah, B. XUP - a SOAP-based Simple User Interface Protocol. In Procs of AusWeb 2005 (Gold Coast, Australia, July 2005).