1. 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
501 Morton N. St, Suite 222, Bloomington IN 47404
Community Grids Lab, Indiana University

2. 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)

3. 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.

4. 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

5. 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

6. Network system in a layered stack
Application
Messaging infrastructure
Same layer ?
Virtual distributed operating system
Physical network

7. 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 WS-Security 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

8. Architecture of publish/subscribe model based on
NaradaBrokering event broker notification service

9. 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

10. 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

11. 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.

12. 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

13. MVC paradigm

14. SMMV vs. MMMV as MVC interactive patterns

15. Monolithic collaboration model
NaradaBrokering
Identical programs receiving identical events
master
SVG
browser
client
other

16. SMMV collaborative Web Service model
SVG DOM
as Web Service
NaradaBrokering
master
SVG
client
View
master
SVG
client
other
View
master
SVG
client
other
View
master
SVG
client
other
View
Share output port

17. MMMV collaborative Web Service model
NaradaBrokering
SVG DOM
Model
as Web Service
SVG DOM
Model
as Web Service
SVG DOM
Model
as Web Service
SVG DOM
Model
as Web Service
Broker
Broker
Broker
Broker
master
SVG
client
View
master
SVG
client
other
View
master
SVG
client
other
View
master
SVG
client
other
View
Share input port

18. A comparison of MVC and MMVC model in a case of SVG application
Model View Controller
a. MVC Model
Controller
View
Display
Model
Messages contain control information
Decomposition of SVG Browser
b. Three-stage pipeline
High Level UI
Raw UI
Rendering as messages
Events as messages
Semantic
Figure 1 Reformulation of SVG to message based MVC in a Web Service Model
Input port Output port

19. Method-based MVC vs. message-based MVC
Broker
Set up an event class (topic)
Subscribe to event class
Send event
register call back method
publish an event class A B A B
invoke call back method with event
method based
message based

20. Message-based MVC model

21. Shared SVG Browser on PDA Shared SVG Browser on PC
Three among the different ways of decomposing SVG between client and Web Service component
Shared SVG Browser on PDA
b. Decomposed WS optimized for thin clients
Rendering as messages
Events as messages
Messages contain control information
Semantic
High Level UI
R F I O
U F I O
Web Service
Event (Message) Service
Raw UI
Display
Shared SVG Browser on PC
a. Non-decomposed collaborative SVG requiring minimal changes to the original source code
SVG Browser
Collaborative Events and Web Service messages
Internet Game
c. Decomposed WS optimized for performance
Figure 2 Three among the different ways of decomposing SVG between client and Web Service component
Input port Output port

22. 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

23. Collaborative SVG Chess Game
Players
Observers

24. Collaborative SVG Event processing chart
Figure 5 Collaborative SVG Event processing chart
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)

25. The general event/listener model
Component A
(Event Source) B
(Event Listener)
register for event notification
issue event occurrence

26. Java delegation event model
Source
register event x listeners
Invoke call back method
with event x
x EventListener 1
x EventListener 2
x EventListener n

27. Topic-based Publish/subscribe model
Subscriber 1
Subscriber 2
Subscriber 3
Subscriber 4
Subscriber 5
Publisher 1
Publisher 2
Topic A
Topic B
Topic C
broker
Notification
Service

28. A B Broker Model View Subscribe to event class
Set up an event class (topic)
publish an event class
Send event
Component A B
Figure2 Event-driven message-based Publish/Subscribe scheme
Figure3 Shared Input Port of Collaborative SVG
Input port Output port
View
GVT
Renderer
User
Port
JavaScript
SVG DOM
Application as Web Service
Facing
Resource
Rendering as
messages
Event as messages
Model
Master client
Set up an event
class (topic)
Publish
an event
to collaborative clients
Subscribe to
the topic
Rendering as messages
Participating client

29. Architecture of monolithic collaborative SVG
Figure 3 Architecture of collaborative SVG browser on PC
XGSP
Session control Server
Event (Message) Service Infrastructure
NaradaBrokering
• • •
Master client SVG browser 1 F I R O
Other client SVG browser 2
Other client SVG browser n
Control to/from
all SVG browsers in the collaborative session
Data from master client
Control to/from XGSP
Data to other clients

30. Architecture of multiplayer game with SVG
Figure 4 Architecture of collaborative Web Services drawn for particular case of Internet multiplayer game with SVG
Event (Message) Service Infrastructure
NaradaBrokering
• • •
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
Rendering from SVG WS 2
Control to/from SVG display 2

31. Decomposition of SVG browser into stages of pipeline

32. 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.

33. Implicit State A B A B Broker Broker View subscribe subscribe publish
send event
Conventional shared state model
Shared state
subscribe A B
Broker
publish
send event
Separated component/service model

34. 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.

35. 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

36. Future Work Performance analysis Performance optimization
Apply the concept to other applications (e.g. OpenOffice)

37. References Community Grids Lab
University Web site
CGL Web site
Additional Projects
Publications
CGL activities summary ( )
Current major projects of CGL
NSF Middleware Initiative (NMI) at
NaradaBrokering at
Collaboration environments
GloblaMMCS at
Commercial product: Anabas at
Collaborative SVG at

38. 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.