Message-based MVC Architecture for
Distributed and Desktop Applications
Xiaohong Qiu
Department of Electrical Engineering and Computer Science Syracuse University
Presentation Topics
Ø
Background for My Research
Ø
Architecture of Message-based MVC
Ø
SVG Experiments
Ø
Performance Analysis
Ø
Collaboration Paradigms
Background
Ø
General area is technology support for Synchronous and Asynchronous Resource Sharing.Ø
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)
§e-learning (e.g. video/audio conferencing)
§e-science (e.g. large-scale distributed computing)
§e-business (e.g. virtual organizations)
§e-entertainment (e.g. online game)
Classic Grid Architecture
Resources
Netsolv e
Compositio n
Content Access
Computin g
Securit y
Collaboration
Middle Tie Brokers Service Providers
Client
s
Peer to Peer Grids
Brokers
Brokers
Event/Messag e Brokers
Broke rs
Broker s
Event/Messag e Brokers
Service Facing Web Service Interfaces
A democratic organization
User Facing Web Service Interfaces
Peers
Peers
Research on a generic model of
building applications
§
Application domains
§
Distributed (Web)
§ Service Oriented Architecture and Web Services
§
Desktop (client)
§ Model-View-Controller (MVC) paradigm
§
Internet collaboration
§ Hierarchical Web Service pipeline model
•
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
§ Internet collaboration enabling virtual enterprises
§ large-scale distributed computing
Summary of the situation
• The 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 is not completed
§ It keeps adding new functionalities to the general purpose platform
§ One current effort focuses on building ofmessaging infrastructure tailored for disparate applications
• Evolution of application architectures
§ client-server model
§ Multi-tier (e.g. three-tier) model
§ A variety of distributed model (e.g. Java RMI, CORBA, COM/DCOM, J2EE, .NET)
§ Grids
§ Peer-to-peer
§ 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 availabilityto clients fro heterogeneous platforms (e.g. Windows, Linux, Unix, and PalmOS)
§ Uniform Web interfacethat provides a platform withaggregation of multiple services
Our approach
• Explicit messaging replacing implicit messaging of traditional event listener paradigms
• Key idea is to generalize MVC with model and view communicating by messages with the messaging providing control mechanism
• Message-based MVC (M-MVC) paradigm integrates distributed, Web, and desktop applications
• SMMV and MMMV for general collaboration paradigms
• Prototyping monolithic SVG collaborations
§ Shared SVG browser
§ Share online chess game
• Decomposed SVG experiments and detailedperformance measurements to test viability of loose
coupling services message-based • Specifically investigate
§ M-MVC and MVC
§ M-MVC and Web Applications (Services)
§ M-MVC and collaboration (SMMV and MMMV paradigms)
§ M-MVC and messaging infrastructure (NaradaBrokering middleware)
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
Model
Controller
Vie
w
Mouse
event
Keyboard
events
Displa
y
Model-View-Controller (MVC) model
Double-linked multiple-stage Web Services
pipeline model of Web applications
Obje ct’’
Or WS’’ Obje
ct Or WS
Obje ct Or View Obje
ct’ Or WS’
Obje ct Or Displ
Architecture of Message-based MVC
•
M-MVC is a general approach for building applications with a
message-based paradigm
•
It emphasizes a universal modularized service model with
messaging linkage
•
Converges desktop application, Web application, and Internet
collaboration
– MVC and Web Services are fundamental architectures for desktop and Web applications
– Web Service pipeline model provides the general collaboration architecture for distributed applications
– M-MVC is a uniform architecture integrating the above models
•
M-MVC allows automatic collaboration, which simplifies the
architecture design
Reformulation of SVG to message-based MVC in a Web Service Model a. MVC Model b. Three-stage pipeline
Model View Controller
Controller
View
Display
Model
Messages contain control information
Decomposition of SVG Browser
High Level UI
Raw UI Display
Rendering as messages Events as
messages
Semantic
Events as
messages Rendering asmessages
Input port Output port
A comparison of MVC and pipeline model in a
case of SVG application
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
Collaborative SVG Chess Game
Players
Observers 17
Making SVG collaborative by sharing of intercepted events via
messaging broker with Publish/Subscribe scheme
Output port Input port
View
Renderer
User
Port
JavaScript Application as Web Service
Port
Facing
Resource
Renderingas
messages Eventas messages
Model
Master client
Set up an event class (topic)
Publish
an event to collaborativeclients
Subscribe to the topic
Facing
Input port Output port
View
Renderer
User Port
JavaScript Application as Web Service
Raw UI events
(e.g. Mouse and key
events)
High Level UI events
(e.g. SVG/DOM events)
Semantic events
(e.g. Application events such as
“capture” in chess game)
Collaborative events
(e.g. Master Events which has context information of collaboration and
information from previous stages)
Collaborative SVG Event processing chart
Classes of Events in SVG
Around 60 detailed
Events
XGSP Session control Server NaradaBrokering Event (Message) Service Infrastructure •• • Master client
SVG browser 1
F I R
O
Other client
SVG browser 2
F I R
O
Other client
SVG browser n
F I R
O
Control to/from all SVG browsers in the collaborative session Data from master client Control to/from XGSP Data to other clients Control to/from XGSP Data from master client Control to/from XGSP
Architecture of collaborative SVG browser on PC
NaradaBrokering
Event
(Message)
Service
Infrastructure
••
•
XGSP
Session control Server
SVG WS 1
Internet Game SVG WS 2
SVG WS n
••
•
SVG display 1
SVG display 2
SVG display n
Control to/from SVG WS1,2, …, n
Control to/from XGSP, SVG display 2 Rendering to SVG display 2
Control to/from SVG WS1,2, …, n
Rendering from SVG WS 2
Control to/from SVG display 2
Architecture of multiplayer game with SVG
This is decomposed SVG
example
Decomposed SVG Experiments
•
Convert a standalone application into
distributed system by splitting
Model
and
View
.
•
Where to split?
•
How to split?
•
How difficult to split?
Three MVC approaches based on different communication mechanism
and interactive pattern between
model
and
view
View Control Model View Messages Model View Model
Broke r
Pub/Sub
a) classic
(method-based) (method-based or message-based)b) request/response c) publish/subscribe(message-based)
Method-based MVC vs. message-based MVC
B
Subscribe
to event class
A
Broker
Setup anevent
class(topic)
publish anevent
class Sendevent
message based
A register call back method B
invoke call back method with event
method based
Decomposition of SVG browser into
stages of pipeline
We analyzed flow of events in Batik to see where best to decompose into
Model and View. There was no clear separation in original code
SVG parser Output (Renderer)
(update image buffer)
Input (UI events)
(e.g. Mouse and key events)
JavaScript
(access and manipulate DOM
element)
DOM tree (before mutation)
(DOM events)
DOM tree’ (after mutation) GVT tree’
(GraphicsNode changes )
GVT tree
(GraphicsNode events)
Decomposition Point
View Model
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 MVC paradigm tends to force a more restrictive
programming model
Implementation of Decomposed SVG Browser
Implicit State
subscribe
A B
Broker
publish send
event
Separated component/service model subscribe
A
View B
Broker
publish send
event
Conventional shared state model
Shared state
A
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
– The 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
• Experiments with decomposed Batik SVG browser based on
M-MVC model.
• The decomposed
Model
and
View
interact with event-based
message via messaging broker provided by NaradaBrokering.
• Many variables are set for testing scenarios, which including
• locations of
Model,
View
and event broker
• runtime environment (e.g. OS and network connection)
• Analysis
• Relationship of user interactions and structure of mouse events
• Performance of fine-grained mouse events
• Factors (
network latency
and
computation overhead
,
thread
scheduling
etc.) that affect overall system performance
Definition of typical events of distributed applications
message passing
(exchanging a message between components)
updating a region held in a single node Parallel Computing
a mouse movement moving a piece
Multiplayer Online Game (e.g. chess)
a mouse movement drawing a new graphics component (e.g. a
rectangle, a line, a path) Shared Whiteboard
a mouse click on a hyperlink loading a new URL
Shared Browser
inter-frame delay multi-way buffering (interactivity)
Video/Audio Conferencing
inter-frame delay one-way buffering
Internet TV Broadcast (Streaming Media)
n/a messaging passing
(exchanging a message between components) Distributed Simulation
n/a downloading a file
Shared File System (P2P)
a key stroke writing one line of message
Instant Messenger
a key stroke writing an email
MicroEvent MacroEvent
Applications
Summary of typical distributed applications and characteristics
multicast yes 10’s millisecs low mill sec sec high text, image, soundMultiplayer Online Game
multicast yes 10’s millisecs low mill sec sec high text, image Shared Whiteboard multicast no 100’s millisecs high .033 sec sec high image, sound Video/Audio Conferencing broadcast no second high .033 sec sec high image, sound Internet TV/Broadcast point-to-point yes 100’s millisecs high n/a sec n/a byte message Distributed Simulation multicast yes minutes or above high n/a min n/a byte stream
Shared File System (P2P)
multicast no second low milli sec sec low text Instant Messenger point-to-point no minutes or above low milli sec min low text, image Email connectivit y type reliabili ty latency tolerance level band-width Micr Event Macr Event Rendering complexity type
network connectivity features avg. min level of
interactivity Content
Performance Testing and timing points
T0 Machine B Output (Renderin g) Input (UI events) GVT tree’ GVT tree Machine A Event Proce ssor JavaScri pt DOM tree (before mutation) DOM tree’ (after mutation) Machine C Event Proce ssorT3 T1
T4 T2
Brok er
Notification service
(NaradaBrokering) Model(Service)
View(Client) Event Proce ssor Event Proce ssor DOM tree’ (mirrore d) DOM tree (mirrore
d) T0
§T0: A given user event such as a mouse click that is sent from View to Model.
§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
160.0
404.0 ±
20.0
23.3 48.4 ± 3.0 12.8 24.8 ± 1.6 4.317.0 ±
0.91
Solaris server Inter-City 5 194.0334.0 ±
22.0
26.3 49.5 ± 3.0 13.6 29.7 ± 1.5 4.820.0 ±
1.1
Linux cluster node server Within-City (Campus area) 4 185.0414.0 ±
24.0
20.5 43.9 ± 2.6 10.2 21.0 ± 1.3 2.814.9 ±
0.65
Linux server Office area 3 91.2123.0 ±
8.9
17.6 31.0 ± 1.7 9.07 18.9 ± 0.89 2.818.0 ±
0.57
High-end Desktop server Switch connects 2 173.0294.0±
20.0
23.7 48.9± 2.7 18.7 37.9 ± 2.1 14.833.6 ±
3.0
Desktop server Switch connects 1 stddev mean ± error stdd ev mean ± error stdde v mean ± error Stdd ev mean ± error NB location distance No End Rendering T4-T0(microseconds)Last return – Send time: T’1
-T0(milliseconds)
First return – Send time: T1-T0
(milliseconds)
First return – Send time: T1-T0
(milliseconds)
Average of all mouse events (mousedown, mousemove, and mouseup)
Mousedown events Test scenarios
Test
6 5 4 3 2 1 No Test Inter-City Inter-City Within-City (Campus area) Office area Switch connects Switch connects distance Test scenarios 176.0
364.0 ±
25.0
23.6 55.6 ± 3.4 19.3 37.8 ± 2.7 9.821.7 ±
1.4
Solaris server 179.0351.0 ±
27.0
32.8 54.6 ± 4.9 14.5 31.8 ± 2.2 8.818.1 ±
1.3
Solaris server 179.0329.0 ±
25.0
20.6 46.7 ± 2.9 11.6 26.9 ± 1.6 7.615.4 ±
1.1
Linux cluster node server 166.0364.0 ±
22.0
21.9 54.2 ± 2.9 14.2 36.3 ± 1.9 11.024.3 ±
1.5
Linux server 109.0158.0 ±
12.0
29.4 49.5 ± 3.1 13.8 29.5 ± 1.5 12.320.6 ±
1.3
High-end Desktop server 159.0405.0 ±
23.0
25.9 68.0 ± 3.7 19.4 52.1 ± 2.8 19.036.8 ±
2.7
Desktop server stddev mean ± error stdd ev mean ± error stdd ev mean ± error Stdde v mean ± error NB location End Rendering T4-T0(milliseconds)Last return – Send time: T’1
-T0(milliseconds)
First return – Send time: T1-T0
(milliseconds)
Bounce back – Send time:
(milliseconds)
Average of all mouse events (mousedown, mousemove, and mouseup)
Bouncing back event
Immediate bouncing back event
4.47
16.8 ± 0.72
3.67
7.96 ± 0.60
6
4.54
14.0 ± 0.74
3.68
7.96 ± 0.60
5
6.95
14.1 ± 1.1
3.76
7.89 ± 0.61
4
4.85
16.9 ± 0.79
3.69
9.16 ± 0.60
3
4.09
11.4 ± 0.66
2.53
4.46 ± 0.41
2
6.07
13.4 ± 0.98
3.78
7.65 ± 0.61
1
stddev
mean ± error
stddev
mean ± error
No
milliseconds
milliseconds
4 hops
(View – Broker – Model –
Broker – View)
2 hops
(View – Broker – View)
Test
Observations I
• This client to server and back transit time is only 20% of the total processing time in the local examples.
• The overhead of the Web service decomposition is not directly measured in tests shown these tables
• 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 overhead of NaradaBrokering itself is 5-15 milliseconds depending on the
operating mode of the Broker in simple stand-alone measurements. It consists
forming message objects, serialization and network transit time with four hops (client to broker, broker to server, server to broker, broker to client).
• The contribution of NaradaBrokering to T1-T0 is 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.
NB on Model; Model and View on
two desktop 1.5 Ghz PCs; local
NB on View; Model and View on two
desktop PCs with “high-end” graphics
Dell (3 Ghz Pentium) for View; 1.5 Ghz
Comparison of performance results to
highlight the importance of the client
All Event
Mousedow
Mouseu
Mousemove
All Event
Mousedow
Mouseu
Mousemove
Time T
1-T
0milliseconds
Events per
5 ms bin
NB on local 2-processor Linux
server; Model and View on two 1.5
Ghz desktop PCs; local switch
network connection.
NB on 8-processor Solaris server
ripvanwinkle; Model and View on
two 1.5 Ghz desktop PCs; remote
network connection through routers.
Comparison of performance results with
Local and remote NB locations
All Event
Mousedow
Mouseu
Mousemove
All Event
Mousedow
Mouseu
Mousemove
Time T
1-T
0milliseconds
Events per 5 ms binEvents per 5 ms bin
Observations II
• One usually gets better performance moving the NaradaBrokering broker off the
desktops; the better broker performance (there are no scheduling overheads) outweighs the increasing network overhead.
• The performance of NB on desktop server is not as good as that in fig 7.5 with NB on “gridfarm1” machine running Linux server.
• The results in fig. 7.7 (“ripvanwinkle” with 100 miles round trip distance) generates similar pattern as in fig. 7.5 (local connection) except with a slightly lower performance
corresponding to the greater network delay for “ripvanwinkle”.
• Our results show that use of windows desktops to run NaradaBrokering is never good even when one uses a machine running the model and view with no network delay.
• Windows scheduling introduces delays of 10-20 millisecond overhead that is much larger than the 1-2 millisecond delays coming from network transit within the extended university campus and the similar intrinsic processing time needed by NaradaBrokering on a clean Linux/UNIX machine.
NB on one node of HPC Linux cluster; Model and View on two desktop PCs; routers
network connection. A few events with timing greater than 100 milliseconds are not
shown on the plot
This illustrates that
this type of HPC
engine can be used in
Web Server mode
with each node
running different
services. We are only
using one node and
so this is not a
parallel computing
application
NB on 8-processor Solaris server
complexity; Model and View on
NB on 8-processor Solaris server
ripvanwinkle; Model and View on two
All Event
Mousedow
Mouseu
Mousemove
All Event
Mousedow
Mouseu
Mousemove
Time T
1-T
0milliseconds
Events per 5 ms binEvents per 5 ms bin
Mean Mousedown
Mean Mousemove
Mean Mouseup
Events
Per 0.5 ms
Mean ms
NB on Ripvanwinkl
NB on Vie
NB on Model
15 runs each
split over
3 days
Events
Per 0.5 ms
Mean ms
NB on Ripvanwinkl
NB on Vie
NB on Model
Standard
Deviatio
Mousedown
Standard Deviatio
Mousemove
Standard Deviatio
Mouseup
§
Ripvanwinkle ALWAYS Better
§
Means and Standard Deviations do not vary much from run to run
§
Mouse Down has larger standard deviation when NB on Model
§
Note Mouse Down has least model processing
§
NB-Model and NB-View similar except for Mouse Down where NB-View
better
§
In an exploratory run with NB running over the local network on a Dell PC
with Window XP (heavy loaded), we found very poor performance. For
example, the mean of the mousedown event was 92 milliseconds compared
to 16 milliseconds on ripvanwinkle
Observations III
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
SMMV vs. MMMV as MVC interactive patterns
§ SIMD– A single control unit dispatches instructions to each processing unit.
§ MIMD– Each processor is capable of executing a different program independent of the other processors. It enables asynchronous processing.
§ SMMV generalizes the concept of SIMD
§ MMMV generalizes the concept of MIMD
§ In practice, SMMV and MMMV patterns can be applied in both asynchronous and synchronous applications, thus form general collaboration paradigms.
View n-1 View n View 1 View 2
Model
a) Single Model Multiple View
View n-1 View n View 1 View 2
Model m-1 Model m Model 1 Model 2
b) Multiple Model Multiple View
• Monolithic Collaboration
• All participating components are formed as replications of an existing application without
explicit break up into a separate Model and Viewcomponent as required by the Web service architecture.
• Works through interception of the events on a master application and allows messaging broker to multicast them to the collaborating clients.
§ CGL applications of PowerPoint, OpenOffice and data visualization
• Web Service Collaboration framework
• Shared input port ─ replicated Web Service
§ CGL applications including A/V conferencing, shared whiteboard, text chats and SVG chess
• Shared output port
§ CGL shared display application
• SMMV and MMMV collaboration model (integration of desktop and distributed
models)
• SMMV ─ decomposed Model and Viewwith multiple clients sharing a single Model
component.
§ Instructor led learning
• MMMV ─ decomposed Model and Viewwith multiple models each driving its own separate
View. It enables ubiquity with the customization done from the Model at server side.
§ Participatory learning
master client Vie w NaradaBroker ing other client Vie w Model
as Web Service
other client Vie w other client Vie w Br ok er master client Vie w other client Vie w other client Vie w other client Vie w NaradaBroker ing Model
as WS as WSModel as WSModel as WSModel
Br ok er Br ok er Br ok er
Collaboration paradigms deployed with M-MVC model
SMMV
MMMV
master SVG browser client other NaradaBrokeri ngMonolithic collaboration
Identical programs receiving identical events
Summary of Contributions
• 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.
