Web Service Architecture for e-Learning
by Xiaohong Qiu
July 23, 2004
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
Network system in a layered stack
Application
Messaging infrastructure
Same layer ?
Virtual distributed operating system
Physical network
6
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
7
Notification service
over network
Subscriber 1
broker
broker
subscribe
Publish
broker
deliver
Publisher 1
broker
broker
broker
broker
subscribe
Subscriber 2
deliver
represents a delivery service
node (DSN) that manages a
topic event queue for a broker
Architecture of publish/subscribe model based on
NaradaBrokering event broker notification service
8
Our approach
Building applications centered on messages
Separation of application architecture from
messaging infrastructure
Focus on exploration in design space and
study system composition and interaction.


Event models and Publish/Subscribe scheme
Message-based MVC Paradigm for
distributed, Web, and desktop applications
MMVC and MVC
MMVC and Web Services
MMVC and collaboration
MMVC and messaging infrastructure
9
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
10
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.
11
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
12
MVC paradigm
Model View Controller
Model
Controller
Mouse event
Keyboard events
Figure
View
Display
MVC Model
13
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
14
Monolithic collaboration model
NaradaBrokering
SVG
browser
master
client
SVG
browser
master
other
client
SVG
browser
master
other
client
SVG
browser
master
other
client
Identical programs receiving identical events
15
SMMV collaborative Web Service model
Model
SVG DOM
as Web Service
NaradaBrokering
SVG
View
master
master
client
SVG
SVG
SVG
View
View
View
other
master
client
other
master
client
other
master
client
Share output port
16
MMMV collaborative Web Service model
NaradaBrokering
Model
Model
Model
Model
SVG DOM
as Web Service
SVG DOM
as Web Service
SVG DOM
as Web Service
SVG DOM
as Web Service
Broker
Broker
Broker
Broker
SVG
View
master
master
client
SVG
SVG
SVG
View
View
View
other
master
client
other
master
client
other
master
client
Share input port
17
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
18
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
19
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
20
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
21
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
22
Collaborative SVG Chess Game
Players
Observers
23
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
24
The general event/listener model
register for event notification
Component
A
(Event Source)
Component
B
(Event Listener)
issue event occurrence
25
Java delegation event model
register event x listeners
x EventListener 1
Event
Source
x EventListener 2
Invoke call back method
with event x
x EventListener n
26
Topic-based Publish/subscribe model
Publisher 1
Publisher 2
Notification
Service
broker
broker
Topic A
broker
Topic B
Topic C
broker
Subscriber 1
Subscriber 2
Subscriber 3
Subscriber 4
Subscriber 5
27
Set up an event
class (topic)
Publish
an event
Facing
Model
JavaScript
Component
A
Component
B
Facing
Output port
Event as messages
Facing
Application as Web Service
JavaScript
Input port
Facing
Output port
Rendering as
messages
GVT
GVT
Renderer
Renderer
Figure2 Event-driven message-based Publish/Subscribe scheme
Facing
SVG DOM
SVG DOM
Input port
Rendering as
messages
to collaborative
clients
Model
Application as Web Service
Broker
Subscribe to
the topic
Broker
View
View
Master client
Participating client
Figure3 Shared Input Port of Collaborative SVG
28
Architecture of monolithic collaborative SVG
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
29
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
30
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
31
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.
32
Implicit State
Broker
A
A
Broker
B
View
A
B
Shared state
Conventional shared state model
Separated component/service model
33
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.
34
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
35
Future Work
Performance analysis
Performance optimization
Apply the concept to other applications
(e.g. OpenOffice)
36
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
37
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.
38