Jyu Thesis

8/14/2019 Jyu Thesis

1/270

A UI-driven Approach to Facilitating

Effective Development of Rich and

Composite Web Applications

Jin Yu

A dissertation submitted in fulfillment of the requirements for the degree of

Doctor of Philosophy

School of Computer Science and Engineering

University of New South Wales

Sydney, NSW 2052, Australia

Supervisor: Prof. Boualem Benatallah

October 31, 2008


2/270


3/270

Originality Statement

I hereby declare that this submission is my own work and to the best of my knowledge

it contains no materials previously published or written by another person, or substantial

proportions of material which have been accepted for the award of any other degree or

diploma at UNSW or any other educational institution, except where due

acknowledgement is made in the thesis. Any contribution made to the research by

others, with whom I have worked at UNSW or elsewhere, is explicitly acknowledged in

the thesis. I also declare that the intellectual content of this thesis is the product of my

own work, except to the extent that assistance from others in the project's design and

conception or in style, presentation and linguistic expression is acknowledged.

Jin Yu

October 31, 2008


4/270


5/270

v

Acknowledgements

It has been a great experience to work as an external PhD student in the School of

Computer Science and Engineering, the University of New South Wales. As an off-

campus student, I faced numerous challenges in the last three years, due to the physical

distance (I reside in California) and time zone differences. I am most grateful to my

supervisor, Prof. Boualem Benatallah, who made all this possible after all.

Foremost, I would like to thank Prof. Benatallah for accepting and accommodating me

as an external research student, for he had to spend countless hours on email

communications with me. As a dedicated researcher and inspiring mentor, he has taughtme many valuable lessons, including key research disciplines and methodologies.

I would like to give special thanks to my co-supervisor, Prof. Fabio Casati, who I

interacted frequently (when he was in HP Labs in Palo Alto) and had many interesting

and fruitful discussions. Prof. Casati was also instrumental in many of my research

papers, as he not only gave insightful comments but also directly edited some the

papers.

In addition, I would like to thank my research collaborators Regis Saint-Paul, Florian

Daniel, Maristella Matera, and many students who have participated in the research

projects. I enjoyed the collaboration very much and gained invaluable skills by working

with them. Among the research students, I wish to express my sincere appreciation to

Evi Syukur, who spent many hours in helping me with proof reading and the printing

and binding of thesis hardcopies.

Finally, I am grateful to my parents and my wife, for their endless support and

encouragement throughout my PhD study. I express special thanks to my wife, who took

on the dreadful task of packing and unpacking when we moved to a bigger house,

allowing me to concentrate on the thesis and finish it on time.


6/270


7/270

vii

Abstract

It is well-recognized that the development of user interfaces is one of the most time-

consuming tasks in the overall application development process. At the same time, there

is an increasing demand for rich and fluid user interfaces from web users. As a result,

developers are facing increasing challenges in delivering web applications, especially

those with rich UI requirements.

In this thesis we present two solutions to facilitate the execution and rapid development

of web applications with rich user interfaces. The first solution is a rich internet

application (RIA) framework aimed at providing high usability and productivity to webapplications, while the second solution is a UI integration framework that simplifies

web application development by facilitating the composition of reusable UI

components.

The foundation of our RIA framework is an XML-based high-level protocol for

communicating asynchronous events and incremental UI updates on the web. The

protocol facilitates rich and highly interactive UI, while at the same time eliminates

frequent and slow page refreshes and provides a more responsive user experience.

Built on top of the protocol, a server-side runtime allows UI logic code to be executed

on the server side, while a set of server-side event-driven API enables developers to

implement sophisticated application-specific UI behavior. On the client side, a thin

client renders UI and processes native events, but leaves application-specific logic to the

server side. The thin client thus allows end users to enjoy a rich UI experience in a safe

client environment, without executing any downloaded code.

The proposed UI integration framework includes an abstract UI component model

which allows UI components to be programmatically manipulated via events,

operations, andproperties, essentially exposing UI as services. To facilitate component

interactions, the framework offers an event-based composition model, which allows

integration logic to be specified in the form ofevent listeners.


8/270

viii

Composite applications are executed via a lightweight runtime middleware, which

provides component adapters that allow the middleware to communicate with native UI

components implemented in a variety of languages and platforms. Finally, a graphical

development environment allows composite applications to be built in a drag-and-drop

fashion.


9/270

ix

Table of Contents

1. Introduction...............................................................................................................1

1.1 Requirements and Challenges...........................................................................2

1.1.1 Developing Rich Internet Application ......................................................3

1.1.2 UI Integration............................................................................................4

1.2 Contributions Overview....................................................................................6

1.2.1 Developing Rich Internet Application ......................................................7

1.2.2 UI Integration............................................................................................9

1.3 Thesis Organization ........................................................................................12

Part 1: OpenXUP an RIA Framework .........................................................................15

2. Background and State of Art in RIA.......................................................................17

2.1 Dimensions for Characterizing RIA Technologies .........................................17

2.1.1 Usability and Productivity.......................................................................17

2.1.2 UI Code Location....................................................................................19

2.1.3 Asynchronous UI.....................................................................................20

2.1.4 Development Environment .....................................................................20

2.2 RIA Technologies ...........................................................................................21

2.2.1 Classic HTML.........................................................................................21

2.2.2 Rich Client Technologies........................................................................22

2.2.3 Server-side Approaches ..........................................................................28

2.2.4 AJAX ......................................................................................................31


10/270

x

2.2.5 Remote Display Technologies ................................................................33

2.2.6 Rich UI Languages..................................................................................36

2.2.7 Comparisons ...........................................................................................36

2.3 Summary.........................................................................................................38

3. UI Transport Protocol .............................................................................................39

3.1 User Interface Model.......................................................................................40

3.2 Protocol Design...............................................................................................42

3.2.1 Definitions...............................................................................................42

3.2.2 Protocol Operations.................................................................................43

3.2.3 Network Event Delivery .........................................................................46

3.2.4 Server-side Notification ..........................................................................48

3.3 Examples.........................................................................................................49

3.3.1 Example 1 ...............................................................................................49

3.3.2 Example 2 ...............................................................................................51

3.4 Summary.........................................................................................................54

4. Developing and Executing RIAs.............................................................................57

4.1 Example Scenario ...........................................................................................58

4.2 Runtime Framework .......................................................................................60

4.2.1 OpenXUP Architecture...........................................................................61

4.2.2 MVC Pattern in OpenXUP .....................................................................63

4.2.3 Location of UI and Application Code.....................................................64


11/270

xi

4.2.4 Runtime Behavior ...................................................................................65

4.2.5 Server-side Asynchronous Notifications.................................................67

4.3 Development Environment .............................................................................67

4.3.1 Application Development APIs ..............................................................67

4.3.2 UI Templates...........................................................................................73

4.3.3 Multiple UI Languages............................................................................76

4.3.4 Asynchronous Event Handling ...............................................................77

4.3.5 Multi-threading .......................................................................................78

4.3.6 Application Development .......................................................................80

4.4 Implementation ...............................................................................................84

4.4.1 Protocol Module......................................................................................85

4.4.2 OpenXUP Server.....................................................................................86

4.4.3 UI Templates...........................................................................................87

4.4.4 SUL.........................................................................................................88

4.4.5 Tracking UI Updates...............................................................................89

4.4.6 Performance Analysis .............................................................................89

4.4.7 Developer Productivity ...........................................................................93

4.5 Summary.........................................................................................................95

5. Delivering RIAs via Thin Client .............................................................................97

5.1 Thin Client Design..........................................................................................98

5.1.1 Architecture...........................................................................................100


12/270

xii

5.1.2 UI State Management............................................................................102

5.1.3 Network Event Delivery .......................................................................103

5.1.4 Synchronous and Asynchronous Events ...............................................104

5.1.5 Thin Client vs. Fat Client......................................................................105

5.1.6 XUPClient vs. Web Browsers...............................................................109

5.2 Running XUPClient ......................................................................................109

5.2.1 Accessing Web Applications ................................................................110

5.2.2 User Interactions ...................................................................................110

5.2.3 Desktop-like User Experience ..............................................................113

5.3 Implementation .............................................................................................113

5.3.1 Protocol Module....................................................................................115

5.3.2 Tracking UI Updates.............................................................................116

5.3.3 Performance Analysis ...........................................................................116

5.4 Summary.......................................................................................................117

Part 2: Mixup a UI Integration Framework................................................................119

6. Background and State of Art in UI Integration.....................................................121

6.1 Integration Layers..........................................................................................122

6.2 Dimensions for Characterizing UI Integration Technologies .......................126

6.2.1 Component Model ................................................................................127

6.2.2 Composition Model ..............................................................................128

6.2.3 Runtime Infrastructure ..........................................................................129


13/270

xiii

6.2.4 Development Environment ...................................................................131

6.3 UI Integration / Component Technologies....................................................131

6.3.1 Desktop UI Components.......................................................................131

6.3.2 Browser Plug-in Components ...............................................................133

6.3.3 Web Portals and Portlets .......................................................................133

6.3.4 Web Mashups........................................................................................135

6.3.5 Comparisons .........................................................................................143

6.4 Summary.......................................................................................................145

7. UI Component Model ...........................................................................................147

7.1 Reference Scenarios......................................................................................148

7.2 Lessons Learned from EAI / Service Composition.......................................150

7.3 Design Principles ..........................................................................................151

7.4 Abstract Component Model..........................................................................155

7.5 UI as Services................................................................................................160

7.6 Summary.......................................................................................................163

8. UI Composition Model .........................................................................................165

8.1 Lessons Learned from EAI / Service Composition.......................................167

8.2 Guiding Principles for UI Composition ........................................................168

8.3 Composition Model ......................................................................................170

8.3.1 Event Subscriptions ..............................................................................171

8.3.2 XPIL......................................................................................................172


14/270

xiv

8.3.3 Additional Integration Logic.................................................................173

8.3.4 Layout Information ...............................................................................176

8.4 UI Content Consolidation .............................................................................177

8.4.1 Value-Changed Events..........................................................................179

8.4.2 Hiding Content Items............................................................................181

8.4.3 Discussions ...........................................................................................182

8.5 Component Embedding.................................................................................183

8.6 Composite Component..................................................................................188

8.7 Summary.......................................................................................................192

9. UI Integration Framework.....................................................................................193

9.1 Example Scenario .........................................................................................194

9.2 Runtime Middleware.....................................................................................196

9.2.1 Event Automation .................................................................................197

9.2.2 Component Adapters.............................................................................199

9.2.3 Runtime Behavior .................................................................................203

9.3 Development Environment ...........................................................................204

9.3.1 Creating Component Descriptors..........................................................205

9.3.2 Specifying Composition Logic..............................................................207

9.3.3 Defining Layout ....................................................................................209

9.3.4 Deployment...........................................................................................210

9.4 Framework Implementation..........................................................................210


15/270

xv

9.4.1 Runtime Middleware.............................................................................210

9.4.2 Development Tools...............................................................................220

9.5 Summary.......................................................................................................224

10. Conclusions.......................................................................................................225

10.1 Summary.......................................................................................................225

10.1.1 OpenXUP..............................................................................................225

10.1.2 Mixup....................................................................................................227

10.2 Future Work ..................................................................................................230

Publications...................................................................................................................233

Project Web Site .......................................................................................................234

Bibliography..................................................................................................................235


16/270

xvi

List of Figures

Figure 2.1 Standard dialog ..............................................................................................18

Figure 2.2 Architecture of AJAX applications ...............................................................31

Figure 2.3 X Window System.........................................................................................34

Figure 3.1 Protocol message exchange ...........................................................................43

Figure 3.2 Before button click ........................................................................................49

Figure 3.3 After button click ...........................................................................................50

Figure 3.4 Before clicking "Add to list" button ..............................................................51

Figure 3.5 After clicking "Add to list" button.................................................................52

Figure 3.6 Selecting list item "Chocolate Chip" .............................................................53

Figure 4.1 Example application: XCat............................................................................59

Figure 4.2 OpenXUP framework architecture ................................................................61

Figure 4.3 XComponent class.........................................................................................68

Figure 4.4 Classes related to events ................................................................................69

Figure 4.5 XApplication class.........................................................................................70

Figure 4.6 XUserSession class........................................................................................71

Figure 4.7 SUL classes....................................................................................................71

Figure 4.8 SUL events.....................................................................................................72

Figure 4.9 SUL event masks ...........................................................................................72

Figure 4.10 XHTML classes ...........................................................................................77

Figure 4.11 XML parsing performance...........................................................................90


17/270

xvii

Figure 4.12 Request processing performance .................................................................92

Figure 5.1 XUPClient architecture................................................................................100

Figure 5.2 Open URL dialog.........................................................................................110

Figure 5.3 Initial window..............................................................................................112

Figure 5.4 After button click .........................................................................................112

Figure 5.5 XUPClient's system menu ...........................................................................113

Figure 6.1 Component integration at different layers ...................................................123

Figure 6.2 HousingMaps...............................................................................................137

Figure 7.1 The National Park Guide .............................................................................150

Figure 7.2 Component-defined event vs. native UI event.............................................156

Figure 7.3 Relationship between UI components and application logic / data services157

Figure 8.1 National Park Guide (event-based model)...................................................168

Figure 9.1 Architecture of the UI integration framework, Mixup.................................193

Figure 9.2 New York Times example ...........................................................................196

Figure 9.3 Event automation .........................................................................................198

Figure 9.4 Component adapters ....................................................................................200

Figure 9.5 Architecture of Mixup's development environment ....................................205

Figure 9.6 Eclipse-based Mixup Editor ........................................................................209

Figure 9.7 AJAX-based Mixup Editor ..........................................................................221


18/270

xviii

List of Tables

Table 2.1 Comparison of web-based UI technologies ....................................................37

Table 3.1 XUP protocol elements for incremental UI updates .......................................45

Table 3.2 Managing XUP status requests .......................................................................48

Table 3.3 Protocol comparison .......................................................................................55

Table 4.1 Server code size ..............................................................................................85

Table 4.2 XML parsing performance..............................................................................90

Table 4.3 Request processing performance ....................................................................91

Table 4.4 Code size comparison (classic HTML vs. OpenXUP) ...................................94

Table 5.1 Client code size .............................................................................................114

Table 6.1 Comparison of UI integration approaches ....................................................143

Table 9.1 Application startup performance...................................................................218

Table 9.2 User study: composition development time..................................................223


19/270

xix

Code Listings

Listing 3.1 UI model example (in SUL) .........................................................................41

Listing 3.2 XUP request for Example 1 ..........................................................................50

Listing 3.3 XUP response for Example 1........................................................................50

Listing 3.4 XUP request for Example 2 (button click) ...................................................52

Listing 3.5 XUP response for Example 2 (after button click).........................................53

Listing 3.6 XUP request for Example 2 (selecting list item) ..........................................54

Listing 4.1 UI template example .....................................................................................74

Listing 4.2 Multiple UI languages example....................................................................76

Listing 4.3 C# source code fragment for XCat ...............................................................81

Listing 4.4 UI template "catalog.xml".............................................................................82

Listing 4.5 "Selection-changed" event request................................................................84

Listing 5.1 Event selector example ...............................................................................104

Listing 5.2 Startup XUP request ...................................................................................110

Listing 5.3 Startup XUP response.................................................................................111

Listing 5.4 Event request for button click .....................................................................112

Listing 5.5 Event response for button click ..................................................................112

Listing 7.1 UISDL descriptors (National Park Guide)..................................................159

Listing 7.2 Binding for the park listing component ......................................................160

Listing 7.3 UISDL descriptor with multiple bindings...................................................162

Listing 8.1 Composition model description (National Park Guide) .............................172


20/270

xx

Listing 8.2 Process-based integration logic...................................................................175

Listing 8.3 Component descriptors for credit application and vehicle registration ......178

Listing 8.4 XPIL fragment for content consolidation ...................................................179

Listing 8.5 Component descriptors with value-changed events....................................180

Listing 8.6 Component descriptors for YouTube and the news report .........................184

Listing 8.7 Composition model for the multimedia news report ..................................185

Listing 8.8 Component descriptors for Google Maps and PImage...............................187

Listing 8.9 Composition model for the real estate application .....................................187

Listing 8.10 Composite component for the original park guide ...................................189

Listing 8.11 Composition model for the multimedia park guide..................................191

Listing 9.1 UISDL descriptors for Yahoo pipe news feed and YouTube video ...........195

Listing 9.2 XML response from the "getWeatherInfo" operation.................................201

Listing 9.3 Generated JavaScript object for the XML response ...................................202

Listing 9.4 Composition model for the New York Times example..............................208


21/270

1

Chapter 1. Introduction

1.Introduction

Web-based applications and services are now the dominant form of software

development and deployment. It is well-recognized that a significant amount of time in

developing an application is spent on its user interface (UI) [Mye92]. Therefore, UI

development has become a key element in the web application development process

[Bri02][Gar02].

Traditionally web applications use HTML to render their user interface. UI is delivered

as HTML pages coupled with some simple JavaScript for data validation. This form of

UI is very simple, but lacks true interactivity, since HTML was originally designed to

render text with embedded images and therefore does not offer rich UI controls [Jel04].

In addition, web pages are always reloaded after each user actions (e.g., mouse click).

This is very annoying to end users, since it takes time to reload a web page even if only

a very small portion of the user interface needs to be updated.

In response to that, developing rich internet applications (RIA) has become an essential

part of the recent Web 2.0 [ORe05] trend. In RIA, interactions are no longer page-based;

that is, user actions do not always result in page refreshes only the changed UI

elements will be re-rendered. Thus, web UI becomes as fluid and as rich as traditional

desktop UI. RIA not only benefits end users, it also benefits the overall network

infrastructure as it requires less roundtrip to the servers and the data involved are

typically small (i.e., not entire pages of data). At the same time, it presents new

challenges to developers because the shift from traditional page-based programming

model to RIA may require additional skills and development effort.

With the added rich UI requirement, the already time-consuming task of web UI

development becomes even more daunting. To save development time and effort, the

reusability of UI is of critical importance. There are many UI toolkits, such as Java

Swing1 and .NET Windows Forms2, which provide pre-packaged classes modeling fine-

grained UI controls (e.g., buttons and menus). However, the reusability of the UI

1 http://java.sun.com/products/jfc/2 http://msdn.microsoft.com/en-us/netframework/aa497342.aspx


22/270

2


remains low since the unit of reuse is low-level UI controls such as buttons and panels,

not high-level UI components encapsulating real application functionalities.

High-level UI components are essentially the presentation front-ends of web

applications or services. Examples of such UI components are: a stock quote portlet that

retrieves stock prices from Yahoo, a weather gadget that displays weather information

from WeatherBug's weather database3, and street maps such as Google Maps4 and

Yahoo Maps5. The availability of these high-level UI components will dramatically

shorten the UI development time of web applications and services.

Once the required UI components are in place, they need to be put together to form an

integrated web application. This process is what we called UI integration or

composition, where UI components from various sources are assembled together to

behave in a synchronized fashion in the composite web application [Yu07b][Yu07c].

This is similar to traditional application integration and web service composition, where

components (i.e., services) are integrated together to form composite applications or

services. With the availability of high-level UI components and appropriate UI

integration middleware, web applications can be quickly put together, without having to

redevelop UI from scratch every time.

In this chapter, we will first discuss the requirements and challenges in developing UI

for web applications. We then outline our major contributions. Finally, we describe the

structure of this dissertation.

1.1Requirements and Challenges

In this section we outline the requirements and challenges in facilitating web UI

development. We separate the challenges in two areas: rich internet applications and UI

integration.

3 http://www.weatherbug.com

4

http://maps.google.com/5 http://maps.yahoo.com/


23/270

3


1.1.1 Developing Rich Internet Application

To provide end users with a rich and responsive user interface, RIA applications will

face the following challenges:

High usability and productivity. Traditional HTML-based web user interface lacks

true interactivity, due to the fact that HTML was originally designed to render hypertext,

not rich UI. This results in a reduction of both the web application's usability and the

end user's productivity. What's needed is a set of rich UI controls equivalent to those

found in desktop applications, so that the web UI can be as fluid and as rich as its

desktop counterpart.

For developers, this calls for a rich UI toolset, with a familiar programming model

similar to those found in desktop GUI toolkits. Essentially, developers should be able to

develop web applications the same way they develop desktop applications.

Asynchronous and incremental UI updates. HTML's page-based model requires the

entire page to be refreshed for each user action, even though typically only a small

portion of the UI needs to be updated. However, users expect fast response time from

their applications. This implies the use of asynchronous mechanism to perform UI

operations while computing in the background. Additionally, UI updates should be

applied incrementally, eliminating the latency and annoyance associated with slow but

frequent page refreshes. Furthermore, both asynchronous and incremental UI

functionalities should be provided by the framework, without the need of complex

programming techniques such as multi-threading and callback functions.

Secure client environment. While many rich web client technologies tried to address

the limitation of HTML, their common approach is to download code to be executed on

the client side (i.e., the browser). The downloaded code could be binary (e.g., applet

byte code) or text (e.g., JavaScript), both impose security risks. Therefore, with

increasing number of internet-based security risks (e.g., identity theft6), the client-side

environment should only execute safe UI code (i.e., markups), without compromising

the security of the end user's computer.


24/270

4


Development complexity. Many rich web client technologies leverage JavaScript to

manage and extend the client-side UI. However, comparing to traditional programming

languages, large amount of JavaScript code remains much harder to develop, test, and

maintain. Although browser incompatibilities have been mitigated due to the availability

of sophisticated JavaScript toolkits, the performance of the JavaScript interpreter still

varies greatly among browsers [Wei08]. In addition, developers now need to be

concerned about intellectual property protection issues, as downloaded code can be

easily viewed and copied on the client side.

With traditional HTML applications, developers do not need to worry about network

issues since both UI logic and business logic code reside on the server side. However,

with rich web client technologies, UI logic is now at the client side, and therefore the

developers are responsible for the network communication between the client-side UI

logic and server-side business logic (e.g., to catch network exceptions). Ideally, the

development environment should allow developers to be oblivious of the deployment

method. The burden of managing client/server communications should be handled by

the runtime framework, not by the developers.

1.1.2 UI Integration

To facilitate the rapid development of web-based user interfaces, UI integration

frameworks will face the following challenges:

Reusable high-level UI components. Application componentization has long been a

common practice in web application development; that is, application functionalities are

packaged as modules or components to be reused. When developing a web application,the developer first selects application components containing desired functionality and

then glues them together appropriately. After that, she builds a user interface for the

integrated web application. Therefore, user interfaces are typically re-developed from

scratch every time. To simply the development of web-based user interfaces, it is

important to make them componentized so that they could be reused, just like

application functionalities.

6 http://en.wikipedia.org/wiki/Identity_theft


25/270

5


The granularity of the reuse should be high-level UI components encapsulating real

application functionalities, not low-level UI controls such as buttons and panels. A high-

level UI component can be regarded as the presentation tier of a web application

component or module. Examples of such UI components are: a news ticker that displays

headlines from CNN, a stock quote portlet that retrieves stock prices from Yahoo, and a

weather gadget that displays weather information from WeatherBug. A high-level UI

component may in fact consist of many low-level controls. The weather gadget, for

example, may contain a panel which houses a graph control for displaying the

barometer, two text labels for displaying high and low temperatures, a text field for

inputting zip code, and a few buttons to cycle through weather forecasts for different

days or ranges of days. Obviously, the desired unit of reuse is the entire weather gadget,

not the low-level UI controls within it.

Component heterogeneity. There are a variety of component technologies that can be

used to develop UI components. Those technologies (and their underlying languages and

platforms) are typically incompatible with one another. In addition, components are

typically built by different developers before the development of the composite

application. As a result, the composite application developer must be able to cope with

existing heterogeneous UI components from a variety of sources. For example, when

putting together a PIM (Personal Information Management) application, the developer

may need to integrate a .NET calendar component, a Java applet task list, and an AJAX-

based address book. All three components were built with incompatible component

technologies7. This is an overwhelming task as the composition developer must possess

the intimate knowledge of multiple component technologies in order to reuse

components built by them.

Therefore, what's needed is a facility that allows components built with different

technologies to be reused in the same composite application, while at the same time

hides the platform and language differences from the composition developer. Hence, the

7 The three components may in fact be available in the same component technology. For illustration

purpose, we assume they were inaccessible to the developer for reasons such as license and

distribution restrictions.


26/270

6


key is the ability to facilitate the communication among components from different

technologies so that they could seamlessly work in the same composite application.

UI composition. While the composition techniques in application integration (e.g.,

services composition) have been well-researched, there has been little study in the UI

area. As we have already discussed the importance of reusing user interfaces, proper UI

composition techniques are needed to assemble UI components into new, value-added

composite applications.

Currently, web-based UI composition exists mostly in form of combining page clips,

where several HTML fragments enclosed in or 8 are combined to

produce a new page. This form of UI composition is very limited in functionality. For

example, the page clips cannot effectively communicate or interact with one another;

they just sit side by side in the final page.

Therefore, what's needed is a composition model that facilitates the communications and

interactions among UI components, while at the same time provides a consistent visual

layout. This ensures that the UI components will behave in a synchronized fashion in the

composite application. In addition, the composition model needs to be simple yet

effective. Simplicity will facilitate quick adoption by developers and tech-savvy

business users, and may eventually enable end-user compositions.

1.2Contributions Overview

Our goal is to facilitate and simply the development of web-based, rich user interfaces.

To achieve this goal, we propose an RIA framework to develop highly interactive web

user interfaces, and a UI integration framework to facilitate the development of

composite applications by reusing existing, heterogeneous UI components.

8 These are HTML container elements that allow any web content to be embedded.


27/270

7


1.2.1 Developing Rich Internet Application

To provide a rich web UI experience to end users and to simply the development of

highly interactive user interfaces, we propose an RIA framework (called OpenXUP),consisting of the following ingredients.

UI transport protocol. The foundation of our RIA framework is the Extensible User

Interface Protocol (XUP) [YC02], an XML-based high-level protocol for

communicating events and incremental user interface changes on the web. We chose

SOAP/HTTP [Gud07a][Gud07b] as the default binding protocol because it is well-

understood, and its implementations in different platforms are widely available.

Alternative bindings such as REST9 [Fie00] are also possible.

In XUP, user actions result in UI events, which are sent as requests to the server side for

processing. Event requests can be delivered from the client to the server asynchronously,

so end users will find applications to be much more responsive. After processing the

events, the server sends back a response containing necessary UI updates. Since the UI

updates are incremental, not one full page at a time, end users will no longer experience

slow page refreshes.

Server-side runtime and development environment. OpenXUP offers a server-side

runtime environment similar to traditional web applications. That is, UI logic and

behavior are programmed on the server side. This allows the applications to be centrally

managed, without the hassles of client-side software maintenance. Unlike traditional

runtimes which return full HTML page in each response, our runtime keeps track of UI

changes, and only returns UI deltas in each response. This is achieved by maintaining a

UI model that corresponds to the exact user interface rendered to the end user.

OpenXUP's development environment includes a set of event-driven APIs, which enable

developers to implement sophisticated application-specific UI behavior on the server

side. OpenXUP APIs are designed to be familiar, closely resembling the APIs from

desktop GUI toolkits. This allows developers to quickly migrate their existing desktop-

based applications. In addition, since all application code resides on the server side, it

9 http://en.wikipedia.org/wiki/Representational_State_Transfer


28/270

8


makes web applications easier to debug and maintain, without the need to worry about

issues from distributed computing.

OpenXUP is very extensible in that it does not dictate a particular UI model. It places no

restriction on the UI control set, the properties or events associated with each control, or

the style or appearance of the UI. That is, OpenXUP can practically work with any UI

model that has an XML-based representation.

Finally, web applications built with OpenXUP are fully compatible with existing

backend technologies (EJB10, CORBA [OMG08], COM11, etc.), since OpenXUP's server

side is designed to run within existing, established web application servers. This allows

OpenXUP-based applications to leverage all existing backend data and business logic

components.

Thin client. OpenXUP employees a thin client design while at the same time providing

rich UI to end users. Similar to browsers, OpenXUP's client side 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. However, the client takes advantages of the desktop computing power to

enable a rich and interactive user experience for end users. It fully leverages the rich UI

capability offered by native desktop GUI toolkits such as Windows Forms and Java

Swing, while at the same time maintains a small footprint.

As the client is thin, the security risks associated with executing downloaded code,

whether binary or script, are avoided all together. This ensures that end users will enjoy

a rich UI experience in a safe client environment.

Implementation. To validate our approach, we provide an implementation of the

proposed RIA framework, which includes a full implementation of the XUP protocol, a

.NET-based server-side runtime environment, a set of event-driven APIs for application

development, and a thin client that can be executed either as a standalone application or

10

http://java.sun.com/products/ejb/11 http://www.microsoft.com/com


29/270

9


as an Internet Explorer plugin. The implementation prototype fully leverages industry

standards such as SOAP and XML.

We also developed a lightweight UI modeling language called Simple User Interface

Language12 (SUL) in order to build some sample applications. However, since

OpenXUP is completely independent of the actual UI model, any UI model with an

XML representation can be used (e.g., XUL13 [Goo01], XAML [MS07b], and UIML14

[Abr99]).

1.2.2 UI Integration

To further simply the development of web applications with sophisticated user

interfaces, we propose a UI integration framework (called Mixup) aiming at the

development of composite applications by reusing heterogeneous UI components.

UI component model. Aiming at combining simplicity with effectiveness, we propose a

UI component model to represent the presentation front-ends of existing web

applications or modules. The key observations are that UI components require 1) a

conceptual, application-specific notion of state (e.g., the location and the zoom level for

street maps), 2) operations to request state changes, 3) events to notify state changes that

are primarily caused by user interactions, and 4) layout and appearance characteristics to

give a consistent look and feel to the composite application.

The proposed model is abstract, meaning that it is not tied to specific implementation

technologies. As a result, it can be used to describe existing UI components developed

with heterogeneous component technologies. This allows us to model UI components as

services, where an abstract UI component may have multiple bindings to native

component implementations.

To describe UI components, we propose the UI Service Description Language (UISDL),

which models a UI component as a service by describing both the abstract component

12 http://openxup.org/TR/sul.pdf

13

http://www.mozilla.org/projects/xul14 http://www.uiml.org


30/270


31/270

11


In a composite application, it is often necessary to place a component inside another. For

example, in a real estate application, it is desirable to place a small thumbnail image of

the selected property on a map showing the property location. Here, the thumbnail

image is provided by a real estate listing component and the map is provided by map

services such as Google Maps. Hence, we propose a component embedding mechanism

that allows one component to be embedded into another, where the two components

may not be aware of each other a priori.

Runtime middleware. In conjunction with the UI composition model, we provide a

lightweight middleware for the execution of composite web applications. The runtime

middleware interprets the XPIL document containing the composition logic and the

UISDL documents that represent the involved UI components. At runtime, the

middleware facilitates the interactions among the components by capturing events fired

by one component and dispatching them to operations of subscribing components.

Component adapters and inspectors. In order to support heterogeneous components,

the runtime middleware supports the notion of component adapters, which allow the

middleware to communicate with components from different component technologies.

Using these adapters, the middleware will permit the integration of UI components

developed using a wide variety of technologies, as long as the corresponding component

adapters are available.

This reinforces the notion of UI as a service, where components adapters facilitate the

bindings from the abstract UI component model to concrete native component

implementations. That is, the abstract model of a UI component is bound to one of its

bindings through an appropriate component adapter at the runtime.

On the development side, we introduce the notion of component inspectors, which allow

the automatic generation of component descriptors (i.e., UISDL documents) from native

UI components. As long as the appropriate meta-language facility (e.g., reflection) from

a component technology is available (e.g., Java, .NET), a component inspector can be

used to find out a legacy component's native events, operations and properties and then

generate a component descriptor with appropriate bindings to the native component

implementation.


32/270

12


Implementation. To validate our approach, we provide an implementation of the

proposed UI integration framework, Mixup, which includes a runtime middleware for

the execution of composite applications and a development environment to facilitate the

application design and development process.

The runtime middleware is a lightweight JavaScript library that can be executed in any

standard browser. It instantiates UI components defined in UISDL documents and

coordinates their interactions according to the composition logic specified in the XPIL

document.

We provide two development tools to assist the building of composite applications. The

first tool is an Eclipse GEF15 based visual editor. It allows developers to efficiently

create component descriptors (i.e., UISDL documents) and composition model (i.e.,

XPIL document) in a drag and drop fashion. The second tool is web-based (AJAX) and

serves the same purpose. Since it can be executed in the browser, no software

installation is necessary. As a result, the AJAX version is more suitable for tech-savvy

end users who demand quick and easy access, whereas the Eclipse version may be ideal

for developers who require maximum features with efficiency.

1.3Thesis Organization

The remainder of this thesis is structured into two parts. In Part 1, we discuss our

proposed RIA framework, OpenXUP, and in Part 2, we present our UI integration

framework, Mixup.

In Part 1, we start with a discussion of the current state of art of rich internet

applications in Chapter 2. We identify several dimensions which can be used to

characterize different RIA approaches, followed by a survey of related work using the

dimensions as a guideline. Next, we present the details of the proposed RIA framework,

OpenXUP. In particular, we discuss the UI protocol, XUP, in Chapter 3, the server-side

runtime / development environment and its implementation in Chapter 4, and the design

and implementation of the thin client in Chapter 5.

15 http://www.eclipse.org/gef/


33/270

13


Part 2 focuses on the proposed UI integration framework, Mixup. Chapter 6 discusses

the current state of art of UI integration, in both research and commercial development.

We identify several dimensions which can be used to characterize different UI

integration techniques, followed by a survey of several representative approaches in the

field, using the dimensions as a guideline. Next, we present the details of the proposed

UI integration framework, Mixup. First, we describe the abstract UI component model

together with the concept of UI as services in Chapter 7, followed a thorough discussion

of the event-based UI composition model in Chapter 8. The UI composition model also

includes content consolidation and component embedding mechanisms to enable a

seamless integrated UI. After that we describe the overall UI integration framework in

Chapter 9, which includes a lightweight runtime middleware to execute composite

applications, as well as a graphical development environment to facilitate rapid UI

composition. In the same chapter, we also present the notion of component adapters to

support legacy, heterogeneous components, and the notion of component inspectors to

support the automatic creation of component descriptors from native component

implementations. We then conclude the chapter by a discussion of the framework

implementation.

Finally, in Chapter 10, we give concluding remarks of this thesis and discuss possible

directions for future work.


34/270


35/270

Part 1: OpenXUPan RIA Framework


36/270


37/270

17

Chapter 2. Background and State of Art in RIA

Part 1: OpenXUP

2.Background and State of Art in RIA

RIA has become a key component of Web 2.0, as more and more users demand rich web

user interfaces which may greatly improve web applications' usability and productivity.

As a result, numerous RIA technologies with varying architectures have emerged in both

research and industry, resulting different features and functionalities.

In this chapter we present the current state of art in rich internet application

development, by illustrating the features and differences, strengths and weaknesses of

several leading RIA approaches. First, we give an overview of the field, followed by a

set of dimensions that can be used to compare and characterize related researches and

technologies in this area. Finally, we discuss related work in this area using the

dimensions as guidelines.

2.1Dimensions for Characterizing RIA Technologies

To discuss related technologies in the RIA field, we need a set of dimensions to

compare them. First, RIA technologies have varying degrees of usability and

productivity. Second, the location of UI code dictates the architecture of the solutions,

with impact from security, communications, to intellectual property protections. In

addition, the support of asynchronous UI allows user interfaces to be more interactive,

without having users "wait" for the UI. Finally, the development environment dictates

how easy RIA applications can be developed; this includes, for example, choices of

programming languages and APIs.

2.1.1 Usability and Productivity

The primary purpose of rich internet applications is to improve the usability and

productivity of web applications. By usability, we mean whether a user interface is easy

to learn and operate. A highly usable interface is thus intuitive and allows users to start

using the application without extensive initial training [BV03]. Similarly, productivity

implies whether a user interface allows users to work with the web application

efficiently [Bai88]; i.e., to achieve a task with the minimum number of mouse clicks

and/or keystrokes.


38/270

18


Part 1: OpenXUP

UI conventions and metaphors improve a user interface's usability and productivity and

reduce its learning curve. There are many established UI conventions in desktop UI

[Mye00]. For example, if a dialog box in Windows contains a "Yes" and a "No" button,

users can either click on the buttons to invoke the desired functionality, or they can use

keyboard shortcut, the "Enter" key for "Yes" and the "Escape" key for "No" (see Figure

2.1). Similarly, many keyboard shortcuts help users navigate menus and edit text (e.g.,

"control-c" and "control-v" to copy / paste text).

Figure 2.1 Standard dialog

This type of conventions is much less established in web UI. Very few web applications

support keyboard shortcuts. Some newer AJAX-based [Gar05] applications do supportthem, but have very different conventions. For example, GMail16 and Yahoo Mail17

support keyboard shortcuts, but each with very different conventions. As a result, the

keyboard shortcuts offered by these applications are only used by a limited number of

power users.

Desktop UI is very mature as a result of many years of research and development.

Desktop-based UI toolkits offer many rich, powerful, and standardized UI controls

which users are very familiar with. Examples are tree, combo box (editable list), slider,

and context menu. Therefore, to provide a high level of usability and productivity in

web applications, users should be able to interact with a set of rich UI controls

equivalent to those found in desktop applications.

16

http://gmail.com17 http://mail.yahoo.com


39/270

19


Part 1: OpenXUP

2.1.2 UI Code Location

We use the term UI code to refer to the code that renders UI (i.e., UI definition) as well

as the code that handles UI events caused by user actions (i.e., UI logic). For webapplications, the code that renders UI is usually in the form of markups (e.g., HTML),

whereas UI logic code must be programmed in script or traditional programming

languages.

UI code can be either located on the client side or on the server side. UI definition is

processes at the client side since the rendering of UI markups is usually performed by

the web browser. It is the location of UI logic code that determines the architecture of a

RIA solution.

When UI logic is located on the client side, the code needs to be downloaded to be

executed by the client. The execution of downloaded code may impose security risks to

the end user's computer. Therefore, both .NET and Java have sophisticated security

sandbox to restrict the execution of downloaded code. In addition, for trusted execution,

downloaded code must be certified by public CAs (certification authority). On the other

hand, if UI logic code is located on the server side, client-side security is no longer a

concern as no downloaded code needs to be executed by the client.

UI logic code on the client side needs to handle issues arisen from client/server

communications. Typically, the client-side UI logic code employs some form of RPC

mechanism to communicate with the server-side application logic code. During this

process, the UI code must catch any exceptions caused by network issues. On the other

hand, if UI logic code is located on the server side, the communication between UI logic

and application logic is much more reliable, so developers do not need to worry about

network issues in the UI logic code.

Finally, if UI logic code is downloaded to the client side, the intellectual property (IP)

associated with that code needs to be carefully evaluated. If the downloaded code is

script-based, IP cannot be protected since anyone can view the source code in the

browser. Binary-based byte code (e.g., Java classes and .NET assemblies) could be


40/270

20


Part 1: OpenXUP

decompiled, so the associated IP could also be revealed. However, IP protection

becomes a non-issue if UI logic code is on the server side, as the code is never exposed.

2.1.3 Asynchronous UI

Users expect their applications to be very responsive. However, many applications block

users from further interactions while performing computations (e.g., by presenting an

hour glass cursor to the users). To make applications more responsive and interactive,

some form of asynchronous mechanism must be employed to perform UI operations

while computing in the background.

Asynchronous UI makes applications to appear more responsive, but it adds complexity

in application development. Applications must support background computation via

multi-threading or callback functions, both of which require additional effort on the

developer's part.

2.1.4 Development Environment

An application development environment offers languages and APIs to create rich

internet applications. Both traditional languages such as Java or C# and scripting

languages such as JavaScript can be used to program rich UI behavior.

Traditional languages may be more appropriate for large scale development, since they

are more structured and have mature tool support. In addition, it is likely that developers

can use the same programming language to code both UI logic and application logic,

allowing an easier integration. Scripting languages are less verbose and easy to get

started. However, large of amount of scripts is hard to maintain, and therefore may not

be suitable for applications with complex UI logic.

APIs play an important role in creating rich UI behavior. Since UI logic mainly consists

of the handling of UI events caused by user actions, the API should be event-driven,

reflecting the nature of rich user interfaces. In order to support rich and highly

interactive UI, the API should support the manipulation of rich UI controls and the

handling of their associated events, similar to those found in desktop-based GUI

toolkits. This also brings familiarity to developers who have experiences in desktop GUI


41/270

21


Part 1: OpenXUP

programming. Finally, the API should be extendable, so that developers can create their

own custom UI controls.

2.2RIA Technologies

A large number of RIA technologies exist to aid the development and deployment of

web applications with rich and interactive UI. In this section, we attempt to group them

into several categories and compare their strengths and weaknesses along the

dimensions introduced earlier. Although classic HTML-based web applications cannot

be regarded as rich internet applications, they serve as a baseboard upon where other

RIA technologies can be compared. After all, the primary goal of RIA technologies is toovercome the limitations of classic HTML-based applications.

2.2.1 Classic HTML

Traditionally, web applications are built with HTML pages. We call this the classic

HTML approach, where web pages are generated on the server side, with some

manually inserted JavaScript code for data validation. Each user interaction (e.g.,

clicking on a link or a button) in the browser results in an HTTP request, which in turn

causes a new page to be generated and returned.

This page-based model lacks true user interactivity, since HTML was designed

explicitly for presenting passive documents and therefore lacks many useful user

interface controls. In addition, frequently page refreshes are very annoying to end users,

since it takes time to reload a web page even if only a very small portion of the user

interface needs to be updated. Also, this wastes network resources since a full web page

is always downloaded after each user interaction. Overall, user interfaces developed

using the classic HTML approach lack both usability and productivity.

Any programming languages can be used in this approach. However, the API is page-

based. That is, the API revolves around how to efficiently generate HTML pages, mostly

based on a combination of templating mechanism with embedded code. Examples are

JavaServer Pages18 (JSP), Active Server Pages19 (ASP), and PHP20. The page-based

18 http://java.sun.com/products/jsp


42/270

22


Part 1: OpenXUP

programming model does not capture the notion of UI events, therefore cannot provide a

high level of interactivity to end users.

Since UI logic is programmed at the server side, no code needs to be downloaded and

executed by the client browser. Therefore, client-side security is not a concern. In

addition, since both UI logic code and application logic code reside on the server side,

developers do not need to worry about communication issues between the two. Finally,

IP protection is not an issue because UI logic code is kept on the server side and never

exposed to the users.

The classic HTML approach does not support asynchronous UI. Users must not act on

the UI before the browser finishes the ongoing request / response cycle. If the user

attempts to interact with the application (e.g., clicking on a link or pressing a button),

the current request / response cycle will be interrupted, resulting adverse effect on the

application. While terminating a search may not cause much damage, interrupting a

credit card transaction may result the user's credit card been charged without booking

the order into the seller's inventory system.

2.2.2 Rich Client Technologies

To overcome the limitations in classics HTML-based applications, a slew of client-side

technologies have emerged. They are typically deployed as browser plug-ins and require

downloaded UI code to be executed on the client side.

ActiveX 21 is one of the first technologies that allow downloadable code to be executed

inside browser. An ActiveX control is typically packaged in a CAB [MS05] file that is

downloaded on demand, while the browser renders the HTML file containing reference

to the CAB file. Once downloaded and instantiated, an ActiveX control may execute

any native Windows code. Therefore, an Active control may contain any UI controls

provided by Windows, resulting a rich and interactive UI that's identical to Windows'

desktop UI experience.

19 http://www.asp.net/

20 http://www.php.net/


43/270

23


Part 1: OpenXUP

Since an ActiveX control allows any native code to be executed on the user's computer,

it can cause many harmful effects. Therefore, Internet Explorer requires downloaded

binaries to be signed by a trusted public certificate authority22 (CA). At runtime, the

certificate issued to the ActiveX control will be presented to the user, asking her

permission to install / execute this control. However, the user usually has no idea of

what's inside the control, so she can either reject it or blindly grant the permission. Once

granted, the downloaded code can practically do anything to the user's computer.

ActiveX mixes the UI definition code that renders the UI and the UI logic code that

provides UI behavior in response to user actions. Both are programmed in whatever

programming language used to implement the ActiveX control. This makes UI

appearance customization less flexible, as it requires UI source code to be changed and

recompiled.

Since ActiveX controls are on the client side, developers must explicitly handle client /

server communications. Although ActiveX controls are downloaded by the browser and

exposed to the end users, IP protection is not a concern since they are compiled machine

binaries.

On the development side, ActiveX controls can be created using many traditional

programming languages, such as C++ and VB. ActiveX controls can access any APIs

provided by the desktop operating system, including Windows' graphical libraries. The

ActiveX API itself is extendable, allowing developers to create custom controls. Finally,

ActiveX does not offer any explicit mechanism for asynchronous UI, so developers must

use callback functions or multiple threads to support that.

Java Applet 23 is Java's alternative to ActiveX controls. It allows Java code to be

executed inside the browser. Instead of native machine code, a Java applet consists of

Java classes made of high-level, platform-neutral byte code. Java applets must be

21 http://msdn.microsoft.com/en-us/library/aa268985.aspx

22

http://en.wikipedia.org/wiki/Certificate_authority23 http://java.sun.com/applets/


44/270

24


Part 1: OpenXUP

executed by the Java browser plug-in, which is available as part of the Java Runtime

Environment (JRE) installation.

Since Java applets have access to most of Java's desktop GUI APIs, they may provide

the same level of usability and productivity as desktop Java applications. Specifically,

the APIs are event-driven, and include a comprehensive set of UI controls for building

rich and interactive user interfaces. The APIs are also extendable developers can build

custom UI controls based on one or more built-in Java UI controls. Java has good

support for callback methods and multi-threading, so developers can take advantage of

those facilities to implemented asynchronous UI.

On the security side, Java Applet provides a sandbox mechanism in addition to signature

from a trusted public CA. The security sandbox restricts what APIs can be called by the

downloaded code, so that applets cannot perform harmful operations (e.g., removing

local files) on the user's computer.

Similar to ActiveX controls, Java applets mix UI definition code and UI logic code, both

of which must be programmed in Java. As a result, applet source code must be changed

and recompiled in order to alter or customize the UI appearance of an applet.

Since applets reside on the client side, developers must manage client / server

communications through RMI24 or other messaging facilities. Although applets are in

binary form, they can be easily decompiled. Therefore, developers must ensure that

valuable IP is not exposed through downloadable applets.

.NET Smart Client [Hil04] offers several improvements to ActiveX. It allows .NET

code to be executed inside the browser. Similar to Java applets, a .NET smart client

contains high-level byte code rather than native machine code. The byte code is stored in

one or more .NET assemblies (DLL files), which are executed by the .NET Common

Language Runtime (CLR). However, .NET CLR is only pre-installed on newer versions

of Windows (i.e., Vista), so users with older Windows must manually install CLR.

24 http://java.sun.com/javase/technologies/core/basic/rmi/


45/270

25


Part 1: OpenXUP

Smart clients have access to the .NET class libraries, including .NET Windows Forms.

As the APIs provided by Windows Forms are event-driven and include a comprehensive

set of UI controls, smart clients can offer a rich and interactive web UI on par with

desktop UI. In addition, developers can create custom UI controls by extending from the

built-in UI controls provided by Windows Forms. Since .NET has comprehensive

support for callback methods and multi-threading, developers can leverage those

facilities to implemented asynchronous UI, providing a more responsive user

experience.

To mitigate client-side security risks, .NET provides Code Access Security25 (CAS)

through a complex set of security APIs to restrict what can be done by the downloaded

code. However, since the security APIs are very complex, they add additional challenges

to the already challenging task of rich web UI development.

Similar to ActiveX controls and Java applets, smart clients mix UI definition code and

UI logic code, both of which must be programmed in languages supported by .NET

(e.g., C#, VB.NET, C++). As a result, the source code of a smart client must be changed

and recompiled in order to alter or customize the UI appearance of the smart client.

Since smart clients reside on the client side, developers must manage client / server

communications through messaging facilities such as .NET Remoting [OH01] or

ASP.NET Web Services26 [How01]. Similar to Java applets, although in binary form,

.NET assemblies can be easily decompiled. Therefore, developers must ensure that

valuable IP is not exposed through downloadable .NET assemblies.

Flash 27 is a popular browser plug-in that was originally designed to render animations

(i.e., vector graphics) in browsers. More functionality was added later to provide rich UI

functionalities. Due to its ubiquitous status among browsers, quite a few RIA

frameworks have been built on top of Flash; for example, Flex28 and OpenLaszlo29. All

25 http://msdn.microsoft.com/en-us/library/930b76w0(VS.80).aspx

26 http://msdn.microsoft.com/en-us/library/t745kdsh.aspx

27 http://www.adobe.com/products/flashplayer/

28 http://www.adobe.com/products/flex/

29 http://www.openlaszlo.org/


46/270

26


Part 1: OpenXUP

these frameworks leverage the Flash browser plug-in to render rich UI and provide user

interactions.

Although Flash-based frameworks provide many rich UI controls, the look and feel is

very different from standard desktop UI controls such as those from Windows Forms

and Java Swing. A new look and feel may appear attractive, but the disadvantage is that

users would have to learn a set of new UI conventions and metaphors. In addition,

keyboard shortcuts are not adequately supported, which negatively impacts the user's

productivity.

Developing Flash-based UI involves creating two types of files, MXML [Coe03] (or

LZX30 for OpenLaszlo), an XML-based declarative language for modeling UI, and

ActionScript31, a JavaScript-based language provided by Adobe (previously

Macromedia). MXML files contain the UI definition and ActionScript files contain the

UI logic. Since the Flash browser plug-in cannot direct interpret MXML or

ActionScript, they must be compiled into an SWF32 file, which can then be executed by

the Flash plug-in. Separating UI definition from UI logic allows an application's UI

appearance to be changed without affecting its UI logic. However, since MXML and

ActionScript are typically compiled into a single SWF file, changing either one will

require a recompilation of both.

With Flash-based applications, both UI definition and UI logic code (in the compiled

form) reside on the client side. As the UI logic code may contain any ActionScript,

client-side security becomes an issue just like Java applets and ActiveX controls. In

addition, developers must manage client / server communication via messaging facilities

such as BlazeDS33. Although the SWF file format is binary, it can be easily decompiled

to reveal ActionScript source code. Therefore, developers must ensure that valuable IP

is not exposed through compiled ActionScript in downloadable SWF files.

30 http://www.openlaszlo.org/lps/docs/reference/

31 http://www.adobe.com/devnet/actionscript/

32

http://www.adobe.com/devnet/swf/33 http://opensource.adobe.com/wiki/display/blazeds/


47/270

27


Part 1: OpenXUP

Flex allows UI definition to be specified in MXML and UI logic to be programmed,

whereas OpenLaszlo uses a combination of LZX and JavaScript. The APIs are

extendable so that custom UI controls can be added by developers. Since Flash runtime

does not support multi-threading, developers must manually divide lengthy computation

tasks and use callbacks to achieve asynchronous UI.

Silverlight 34 is Microsoft's alternative to Flash. It is deployed as a browser plug-in and

provides rich user interactions with sophisticated graphical and multimedia capabilities.

Comparing to Flash, Silverlight has a relatively small deployment base, since it is still in

early product lifecycle and has limited platform / browser support.

Developing Silverlight applications involves coding in XAML for UI definition and

JavaScript for UI logic. Unlike Flash, Silverlight can directly interpret XAML and

JavaScript. JavaScript code can be either embedded in XAML document or can be

referenced externally. Separating UI definition from UI logic allows an application's UI

appearance to be changed without affecting its UI logic.

XAML provides a rich set of UI controls. In addition, starting from version 2.0,

Silverlight can execute any downloaded .NET assemblies (subject to the same security

restrictions as .NET smart clients). This enables developers to use rich UI controls from

both XAML and .NET Windows Forms libraries, resulting a high level of usability and

productivity similar to desktop applications.

With Silverlight-based applications, both UI definition and UI logic code reside on the

client side. As the UI code may consist of JavaScript and downloaded .NET assemblies,

client-side security becomes an issue just like Flash and .NET Smart Client. In addition,

developers must manage client / server communication via messaging facilities such as

.NET Remoting or ASP.NET Web Services. Since JavaScript is in source code form

and .NET assemblies can be easily decompiled, developers must ensure that valuable IP

is not exposed through downloaded JavaScript and .NET assemblies.

On the development side, Silverlight supports JavaScript for coding the application's UI

logic. With the ability to execute .NET assemblies in Silverlight 2.0, any .NET


48/270

28


Part 1: OpenXUP

languages can be used to develop rich UI in Silverlight. As for API, applications can use

JavaScript to access and manipulate XAML's Document Object Model (DOM) [Hor00],

as well as the HTML DOM [Ste03] in the containing browser. In addition, Silverlight

2.0 applications may call any .NET libraries, including those providing rich user

interactions. Both the JavaScript API and the .NET API are event-driven and can be

extended to create custom UI controls. For Silverlight 2.0 applications, .NET's

comprehensive support for callback methods and multi-threading can be leveraged to

implemented asynchronous UI, providing a more responsive user experience.

2.2.3 Server-side Approaches

Since the client-side technologies mentioned above all require users to install browser

plug-ins to execute downloaded code, several server-side approaches have emerged that

allow UI logic be programmed at the server side, just like classic HTML applications.

Improving upon the page-based programming model, they offer abstractions that

represent rich UI controls and a set of APIs resembling their desktop counterpart.

ASP.NET Web Forms [She01] provides an event-driven programming model to page-

based applications. In addition to standard UI controls offered by HTML, it provides a

set of extended UI controls resembling the ones found in the desktop environment. The

goal is to provide developers with an API similar to desktop UI toolkits.

Since it ASP.NET runs on top of the .NET framework, any .NET programming

languages can be used to develop ASP.NET Web Forms applications. Its API is quite

extendable, so developers can easily create custom UI controls. In ASP.NET Web

Forms, UI definition is provided in ASP pages while UI logic primarily consists of eventhandlers that can be programmed in any .NET languages. The separation of UI logic

from UI definition allows the UI appearance to be changed or customized without

altering the UI logic code (and vise versa).

Client-side security is no longer an issue since the UI logic code is on the server side

and consequently no downloaded code needs to be executed on the client side. In

34 http://silverlight.net/


49/270

29


Part 1: OpenXUP

addition, developers do not need to manage client / server communications since both

UI logic and application logic reside on the server side. IP protection is also not an issue

because no source code is exposed to the users.

Although ASP.NET Web Forms provides many desktop-like UI controls and an

associated event-driven programming model, it is still limited by the basic controls

offered by HTML browsers. This is because the rich UI controls are made of basic

HTML controls. For example, the calendar control is made of an HTML table

containing links to each day of the month. In addition, most user actions result in a

request / response cycle that returns a full HTML page, causing an annoying page

refresh. Furthermore, asynchronous UI is hard to implement as now the UI logic runs on

the server side, so the developer has no control of the client side, unless using advanced

JavaScript techniques (e.g., AJAX). As a result, although

Documents

Jyu Thesis