Building Desktop Applications with Web Services
in a Message-based MVC Paradigm
by Xiaohong Qiu
Ph.D. student of EECS department, Syracuse University
Research work is performed at Community Grids Lab, Indiana University
xiqiu@syr.edu, xqiu@indiana.edu
501 Morton N. St, Suite 222, Bloomington IN 47404
Community Grids Lab, Indiana University
1
Background
CGL research – general area is technology support for
Synchronous and Asynchronous Resource Sharing


e-learning
e-science
Grids

manage and share (typically asynchronously) resources (people,
computers, data, applications etc.) or distributed services in a
centralized fashion.
Web Services

Define loosely coupled software components across internet
interacting with messages.
Peer-to-peer Grids

link services, resources and clients in dynamic decentralized fashion
The system consists of a sea of message-based Services (e.g. shared SVG
as a Web Service)
Services linked by publish-subscribe messaging infrastructure (e.g.
NaradaBrokering)
2
Current projects of CGL
NSF Middleware Initiative (NMI)

CGL, Extreme Lab of IU, University of Texas, University of
Chicago, Argon National Lab, a suite of grid services
including portlets interface for middleware environment
NaradaBrokering

A open source messaging infrastructure/middleware for
collaboration, peer-to-peer, and Grid applications
collaboration environments


GlobalMMCS A open source multimedia collaboration
system (multiple video conferencing technology that
supports Java A/V, H323, real player clients; XGSP session
control)
Collaborative SVG, PowerPoint, and OpenOffice etc.
3
Research on a generic model of building applications
Applications: distributed, Web/Internet, desktop
motivations

CPU speed (Moore’s law) and network bandwidth (Gilder’s law)
continue to improve bring fundamental changes

Internet and Web technologies have evolved into a global information
infrastructure for sharing of resources

Applications getting increasingly sophisticated, e.g.
Internet collaboration enabling virtual enterprises;
large-scale distributed computing)

Requires new application architecture that is adaptable to fast
technology changes with properties
scalability
Reusability
Interoperability
Reliability
High performance
Low cost
4
Summarization of the situation
The subsystem of Internet has evolved into stability


TCP/IP network stack dominating the communication protocol domain;
IP forms the low-level sphere surrounding hardware network core
Construction of distributed operating system over the Internet has not
completed and keeps adding new functionalities to the general purpose platform

One current effort focuses on building of messaging infrastructure tailored for disparate
applications
Evolution of application architectures






client-server model
Multi-tier (e.g. three-tier) model
Peer-to-peer
A variety of distributed model (e.g. Java RMI, CORBA, COM/DCOM, J2EE, .NET)
Grids
Web Services and SOA
Web application deployment shows diverse directions but have common
features



User interfaces
Services for the sharing of information and resources (e.g. through unicast and multicast of group
communication)
In the most general sense, collaboration is the core problem and service of Web applications, although
“collaboration” usually refers to system with real-time synchronous and compelling time constraints
Next generation of Web client should enable pervasive accessibility


Ubiquitous availability to clients fro heterogeneous platforms (e.g. Windows, Linux, Unix, and
PalmOS)
Uniform Web interface that provides a platform with aggregation of multiple services
5
Architecture of network system
PDA
IBM
W
A
Network
N
ATM
Supercomputer
ut
in
Core
switch
router
g
FT
P W
SDL
Stre
a mi
ng Media
y
rl a
O
ve
P2
P
Messaging Infrastructure
router
t
lne
rd
Te
oa
SSL
eb
hit
Shared W
Cellular
phone
m Applications
Gr
yste
S
id c
eb Service ro
W
e
l
k
i
r
o
uting
om
F
w
t
e
n
p
P)
OA
(S
Sh
a
re
d
Database
File
Server
TC
IP
P
SM
P
23
UD
3
TP
H
ing
c
s
H
l
n
W
TTP
e
o co
eb
er
Application prot
f
n
Bro
w se
Co
V
/
rs Multip
A
layer game
Laptop
Workstation
Desktop
6
Our approach
Building applications centered on messages
Separation of application architecture from
messaging infrastructure
Message-based MVC Paradigm for
distributed, Web, and desktop applications
 MMVC and MVC
 MMVC and Web Services
 MMVC and collaboration
 MMVC and messaging infrastructure
7
Related technologies
Batik SVG browser (an open source project from
Apache that supports SVG 1.0)


A presentation style application is representative and complex in
nature (we experiments with multiplayer-online game with high
interactivity and compelling time constraints)
Similar applications includes Microsoft PowerPoint, Adobe
Illustrator, Macromedia Flash
SVG (W3C specifications for Scalable Vector Graphics)

A language for describing 2D vector and mixed vector/raster
graphics in XML.
DOM (W3C specifications for Document Object Model)


Programmatic interfaces for access and manipulate structured
document object
All modern browsers (approximately) support the W3C DOM
8
Methodology
Proposing an “explicit Message-based MVC” paradigm (MMVC) as
the general architecture of Web applications
Demonstrating an approach of building “collaboration as a Web
service” through monolithic SVG experiments.

As an example, we present architecture for three types of collaboration
─ monolithic, thin client, and interactive client.
Bridging the gap between desktop and Web application by
leveraging the existing desktop application with a Web service
interface through “MMVC in a publish/subscribe scheme”.

As an experiment, we convert a desktop application into a distributed
system by modifying the architecture from method-based MVC into
message-based MVC.
Proposing Multiple Model Multiple View and Single Model Multiple
View collaboration as the general architecture of “collaboration as a
Web service” model.
Identifying some of the key factors that influence the performance of
message-based Web applications especially those with rich Web
content and high client interactivity and complex rendering issues.
9
What is message-based MVC?
Message-based Model-View-Controller (MMVC)
is a general approach of building applications
with a message-based paradigm




emphasizes a universal modularized service model with
messaging linkage
Converges desktop application, Web application, and
Internet collaboration
MVC and Web Services are fundamental architecture from
desktop to Web applications, MMVC has general importance as
a uniform architecture
MMVC allows automatic collaboration, which simplifies the
architecture design
10
MVC paradigm
Model View Controller
Model
Controller
Mouse event
Keyboard events
Figure
View
Display
MVC Model
11
Message-based MVC model
Model
Web Service
Sematic
High Level UI
Input port
Events as
messages
Output port
Rendering as
messages
Raw UI
Display
User Interface
View
Messages contain control information
12
SMMV vs. MMMV as MVC interactive patterns
Model 1
Model 2
Model m-1
Model m
View 1
View 2
View n-1
View n
Model
View 1
View 2
View n-1
a) Single Model Multiple View
View n
b) Multiple Model Multiple View
13
A comparison of MVC and MMVC model in a case
of SVG application
Model View Controller
Decomposition of SVG Browser
Semantic
Model
Events as
messages
Rendering as
messages
Controller
High Level UI
Input port
Output port
View
Events as
messages
Rendering as
messages
Raw UI
Display
Display
a. MVC Model
Messages contain control information
b. Three-stage pipeline
Figure 1 Reformulation of SVG to message based MVC in a Web Service Model
14
Monolithic SVG Experiments
Collaborative SVG Browser



Teacher-Students scenario
Static Shared SVG contents
Dynamic Share SVG contents
Hyperlink
Interactivity and animation (JavaScript binding)
Collaborative SVG Chess game


Two players-multiple observers scenario
Complex interactivity with game intelligence
15
Collaborative SVG Chess Game
Players
Observers
16
Architecture of collaborative SVG browser on PC
Data to
other clients
R
Master client
SVG browser 1
Session control
Server
Control to/from
all SVG browsers
in the collaborative
session
Control to/from
XGSP
I
Data from
master client
R
O
Other client
SVG browser 2
F
Control to/from
XGSP
I
Data from
master client
R
O
•••
Event (Message) Service Infrastructure
XGSP
NaradaBrokering
F
Other client
SVG browser n
F
Control to/from
XGSP
I
O
Figure 3 Architecture of collaborative SVG browser on PC
17
Architecture of multiplayer game with SVG
Session control
Server
Control to/from
SVG WS1,2, …, n
Rendering to
SVG display 2
SVG WS 2
SVG WS n
Internet
Game
Control to/from
SVG display 1
Rendering from
SVG WS 2
SVG display 2
Control to/from
SVG display 2
•••
•••
Control to/from XGSP,
SVG display 2
NaradaBrokering
SVG WS 1
Event (Message) Service Infrastructure
XGSP
SVG display n
SVG WS1,2, …, n
Figure 4 Architecture of collaborative Web Services drawn for
particular case of Internet multiplayer game with SVG
18
Collaborative SVG Event processing chart
Collaborative events
Semantic events
Raw UI events
High Level UI events
(e.g. Mouse and
key events)
(e.g. SVG/DOM
events)
(e.g. Application
events such as
“capture” in chess
game)
(e.g. Master Events
which has context
information of
collaboration and
information from
previous stages)
Figure 5 Collaborative SVG Event processing chart
19
Method-based MVC vs. message-based MVC
Broker
register call back method
B
A
A
B
invoke call back method
with event
method based
message based
20
Decomposition of SVG browser into
stages of pipeline
Decomposition
Point
View
GVT tree’
Output (Renderer)
(GraphicsNode changes )
Model
DOM tree’
(after mutation)
SVG parser
(update image buffer)
JavaScript
GVT tree
Input (UI events)
(GraphicsNode events)
DOM tree
(before mutation)
(DOM events)
(access and
manipulate DOM
element)
(e.g. Mouse and
key events)
Figure 4 Decomposition of SVG browser into stages of pipeline
21
Important principals
One should split at points where the original method based linkage
involved serializable Java objects.

Serialization is needed before the method arguments can be
transported and this is familiar from Java RMI.
“Spaghetti” classes implied that additional state information would
need to be transmitted if we split at points where classes spanned
interfaces from different modules.

Batik often involved large classes that implemented many different
interfaces. These interfaces often came from different parts of the
program and crossed the possible stages mentioned above.
message-based paradigm tends to force a more restrictive
programming model where all data is shared explicitly and not
implicitly via interfaces crossing splitting lines.
22
Implicit State
Broker
A
A
Broker
B
View
A
B
Shared state
Conventional shared state model
Separated component/service model
23
The changes bring up issues that
cause a challenge to the system
Timing becomes a compelling issue

with the separation of client and Web Service server,
original assumption and design principle break since
time scope drastically increases from tens of
microsecond level (e.g. a Java method call) to a few
milliseconds level (network latency plus system
overhead).
Object serialization is a must have toolkit

messages, as a linkage vehicle, contains component
information from both sides and keep context same.
Synchronization is a factor to consider for context
consistency.
24
Performance Testing
T1: A given user event such as a mouse click can generate multiple associated DOM change events
transmitted from the Model to the View. T1 is the arrival time at the View of the first of these.
T2: This is the arrival of the last of these events from the Model and the start of the processing of the
set of events in the GVT tree
T3: This is the start of the rendering stage
T4: This is the end of the rendering stage
Decomposition
Point
View
T4
T3
Output
Output(Renderer)
(Renderer)
Input
Input(UI
(UIevents)
events)
GVT
GVTtree’
tree’
GVT
GVTtree
tree
T2 T1
T0
DOM
DOMtree’
tree’
(after
(aftermutation)
mutation)
Model
JavaScript
JavaScript
DOM
DOMtree
tree
(before
(beforemutation)
mutation)
Figure 8 Timing points
25
Performance Results
Table 1 Timing of Stages in milliseconds
First arrival from
Model: T1-T0
Start Process DOM
T2-T0
Start Rendering
T3-T0
End Rendering
T4-T0
mean
±
error
stddev
mean ±
error
stddev
mean
±
error
stddev
mean
±
error
stddev
Test
1
Solaris
server
110 ±
5.0
95.0
180 ±
10.0
184.0
243 ±
11.0
204.0
478 ±
13.0
238.0
Test
2
direct
connect.
Desktop
server
108 ±
5.0
132.0
180 ±
7.0
170.0
234 ±
8.0
194.0
485 ±
12.0
272.0
Test
3
wireless
connect.
Desktop
server
113 ±
3.0
54.0
212 ±
5.0
77.0
225 ±
5.0
78.0
510 ±
5.0
78.0
Test
4
IBM Linux
cluster node
76 ±
2.0
76.0
120±
2.0
136.0
190 ±
3.0
174.0
476 ±
3.0
194.0
Test
5
Solaris
server
1490
±
48.0
519.0
2213 ±
57.0
614.0
2275
±
56.0
597.0
2556
±
56.0
596.0
26
Three among the different ways of decomposing
SVG between client and Web Service component
Shared SVG Browser on PC
Shared SVG Browser on PDA
Event (Message) Service
Collaborative
Web Service
Events and
messages
Event (Message) Service
Collaborative
Web Service
Events and
messages
Internet Game
Event (Message) Service
Collaborative
Web Service
RFIO
RFIO
Web Service
Web Service
RFIO
Semantic
Semantic
High Level UI
SVG Browser
Input port
Events as
messages
UFIO
Input port
UFIO
Semantic
High Level UI
Raw UI
Display
Output port
Rendering as
messages
Events as
messages
Messages contain control information
Output port
Rendering as
messages
High Level UI
Raw UI
Display
Raw UI
Display
Messages contain control information
Events and
messages
Messages contain control information
a. Non-decomposed collaborative SVG
b. Decomposed WS optimized for thin
c. Decomposed WS optimized for
requiring minimal changes to the original
source code
clients
performance
Figure 2 Three among the different ways of decomposing SVG between client and Web Service component
27
Summary of message-based MVC
Provision of a universal paradigm with a service model converging
desktop applications, Web applications, and Internet collaboration
Web applications built on messages can achieve important features
such as scalability
The message-based approach is an indispensable part of the big
picture of system design with a separate intermediate messaging
layer


Reduce deployment overhead of applications
Increase portability of application by decoupling application architecture
with underlying platforms
It conforms to service oriented architecture with loosely coupled
messages linkage, which we expect to have an increasingly
important role for reusability, interoperability, and scalability
28
Observations
The overhead of the Web service decomposition is not directly measured in
this table although the changes in T1-T0 in each row reflect the different
network transit times as we move the server from local to organization
locations.
This client to server and back transit time is only 20% of the total processing
time in the local examples.
We separately measured the overhead in NaradaBrokering itself which
consisting of forming message objects, serialization and network transit time
with four hops (client to broker, broker to server, server to broker, broker to
client). This overhead is 5-15 milliseconds depending on the operating
mode of the Broker in simple stand-alone measurements. The contribution
of NaradaBrokering to T1-T0 is larger than this (about 30 milliseconds in
preliminary measurements) due to the extra thread scheduling inside the
operating system and interfacing with complex SVG application.
We expect the main impact to be the algorithmic effect of breaking the code
into two, the network and broker overhead, thread scheduling from OS.
29
NaradaBrokering
One can bind SOAP to NaradaBrokering and allow use
of any of NaradaBrokering transport
NaradaBrokering is placed in SOAP handler and controls
transport, security and reliable messaging using WSSecurity and WS-Reliable Messaging
For a stream, one first uses port 80 and conventional
SOAP over HTTP and then negotiates the transport and
encoding to be used in messages of the stream
30
Future Work
Performance analysis
Performance optimization
Apply the concept to other applications
(e.g. OpenOffice)
31
References
Community Grids Lab

University Web site http://www.communitygrids.iu.edu/

CGL Web site http://www.infomall.org
Additional Projects http://grids.ucs.indiana.edu/ptliupages/
Publications http://grids.ucs.indiana.edu/ptliupages/publications/
CGL activities summary (2003-2004)
http://grids.ucs.indiana.edu/ptliupages/publications/CGLHandout.pdf
Current major projects of CGL
NSF Middleware Initiative (NMI) at www.OGCE.org
NaradaBrokering at www.NaradaBrokering.org
Collaboration environments

GloblaMMCS at http://www.globalmmcs.org/

Commercial product: Anabas at www.anabas.com

Collaborative SVG at www.svgarena.org
32