Transcript Modular Data Pi

A Modular Data Pipelining Architecture
(MDPA) for enabling Universal
Accessibility in P2P Grids
Sangmi Lee
Department of Computer Science
Florida State University
July. 03. 2003
Outline
Part I.
Introductory Concepts and Motivation
Part II. Related Works
Part III. Enabling universal accessibility in
Services
Part IV. Prototype of MDPA
Part V. Contributions and Future Work
July.03.2003
[email protected]
Page. 2
Part I. Introductory Concepts and
Motivation
July.03.2003
[email protected]
Page. 3
Some Observations for Distributed Services
• Distributed Object Computing and Resource Utilization over the Internet.
• Grids manage and share asynchronous resources in a rather centralized
fashion
• Peer-to-peer networks are “just like” Grids with different implementations
of services like registration and look-up
• Computers are fast and getting faster. One can afford many strategies that
used to be unrealistic
– All messages can be publish/subscribe
– Software message routing
• Need Synchronous and Asynchronous Resource Sharing
– Can provide universal access using synchronous collaboration
technology
• Web Services interact with messages
– Everything (including applications like PowerPoint will be a WS?)
• XML will be used for most interesting data and meta-data
• P2P Grid provides P2P network between resources or users in a Grid
environment
July.03.2003
[email protected]
Page. 4
Classic Grid P2P Grid
Resources
Database
Database
Middle Tier
Brokers
P2P
Service
Providers Netsolve
P2P
P2P
P2P
Composition
Content Access
Collaboration
Computing
P2P
P2P
P2P
Security
P2P
Clients
July.03.2003
[email protected]
Page. 5
Universal Accessibility for P2P Grid
• Emerging Miniaturized Devices
• Wireless Network Communication (Wireless LAN(802.11b), 2.5,
3G wireless technology, PAN (Bluetooth), Satellite
Communication, etc.)
• Widespread use of Mobile Devices – Affordable mobile devices
and services
• Tendency of extending service for mobile devices.
– As a user: Mobile devices can be users of traditional distributed services
– As a service provider: A mobile device can itself be a service provider
with its portability (e.g. weather or traffic sensor and send information
with wireless network)
• However problems pertaining to limited computing and
display capabilities in addition to unreliable network
communications persist.
July.03.2003
[email protected]
Page. 6
Our Experiences I
• We’ve investigated on the Distributed Collaborative Services: Tango Interactive
(NPAC, Syracuse Univ.) Garnet Collaborative Service (FSU)
• Garnet Collaborative Service
• Purpose : Support distance Education, Training and if possible Computing as
Grid(Web) Services
• Integrate Synchronous and Asynchronous collaboration
• Support universal access including PDA’s collaboration with desktops
• Uniform XML event (message) based architecture
•All data structures defined in an XML Schema called GXOS
•XML for all metadata (Users, documents, computers) and object changes -- from
text chats to display changes etc.
•MyXoS manipulates GXOS objects
• We build on GMS/JMS (Java Message Service) as industry standard to implement
publish/subscribe model
• Support collaborative features : basic interactive features (textchat, whiteboard, etc.),
shared resources (shared display, shared export), AV conferences.
July.03.2003
[email protected]
Page. 7
Our Experiences II : Short Demonstration
July.03.2003
[email protected]
Page. 8
Our Experiences III: PDA Adaptor (Personal
Server)
July.03.2003
[email protected]
Page. 9
Lessons from Earlier works
• Adaptor architecture provided us an easy way to integrate
PDAs to existing distributed systems.
• However, we faced the limitation of proxy architecture.
– Content adaptation concentrated on adaptor could cause inefficient
network bandwidth usage.
– Proxy-based architecture for integrating network communication
protocols could not ensure end-to-end service features of intelligent
messaging frameworks.
– Optimization of individual messages could be an overhead on
message delivery
• The wireless communication capability and computing
power of mobile devices are getting better and better.
July.03.2003
[email protected]
Page. 10
Motivation
• A P2P Grid provides a natural environment for heterogeneous resource
sharing
• A traditional 3-tier distributed service expects unified user devices with
the infrastructure focused on back-end resources or the middleware
messaging service.
• Early efforts
– Software architectures for user interface (Seeheim model, MVC, PAC, etc)
which have been developed to support various advanced approaches in user
interface design.
– Scientific Visualization, which maps raw data sets to a graphical form for
effective human visual senses. These efforts (IRIS, AVS…) were developed for
a specific purpose and are not adaptable into a general purpose distributed
service as it is.
 The idea of separating user presentation from raw data is still a major
approach in distributed services such as the Web service infrastructure.
• Therefore, the P2P Grid needs a software architecture, for supporting
heterogeneous devices, which clearly defines data processing within the
services that it provides.
July.03.2003
[email protected]
Page. 11
Research Objectives
• Investigating a software architecture which provides,
–
–
–
–
Modular data processing
Flexible Interoperability between object processing
User Interactivity
Universal Accessibility
• Developing a prototype based on this software architecture
• Ability to apply this software architecture design to other
areas
• A service paradigm, which factors both the nature and
capability of heterogeneous devices into its design.
July.03.2003
[email protected]
Page. 12
Part II. Related Work
July.03.2003
[email protected]
Page. 13
Classical Approaches for Presentation Generation
• PAC-Amodeos model : Presentation-Abstraction-Control (PAC) model
+ Arch model( refined Seehiem model )
• MVC (Model-View-Controller) Architecture
• Advantage : Separating User Presentation from Raw data object 
Provides flexible data representation (multiple synchronized views on
the same information)
• Open problems : Data processing is defined coarsely. As a consequence,
the design of the adapting process in multiple service instances cannot
be unified  cannot ensure interoperability between data processing
• Approaches in Scientific Visualization : Focused on the specific purpose
of application, thus, hard to adapt into general purpose applications.
July.03.2003
[email protected]
Page. 14
Proxy-based architectural approaches
• Provides an interface to the service, which adapts mobile
devices to the conventional network communication
environments. (iMobile from AT&T, WBI project from IBM,
ICEBERG from Berkeley)
• Advantages
– More manageable for a specific group of users
– Easy to integrate new devices to legacy service.
• Disadvantages
– Network communication overhead if the content adapting scheme is
performed only in proxy.
– Hard to ensure end-to-end service for existing communication
framework (security, fault-tolerance, etc)
July.03.2003
[email protected]
Page. 15
Standards for Heterogeneous Environments
• W3C(XML based markup languages, CC/PP..) OASIS (Web
service description language), TEI, UnicodeConsotium, ANSI,
Dublin Core Metadata Initiate etc.
• Advantage
– Interoperability between heterogeneous devices, applications and
network environments.
• Open Problems
– In some specific area, “Data Standard” does not have meaning of
standard because of too many standards—limited interoperability
within the group using same metadata sets.
– Complexity of data processing—parsing, indexing, searching.
July.03.2003
[email protected]
Page. 16
Content Adapting Technologies
• Transcoding : Data process which mutates and
customizes an object based on the requesting device and
the user’s preferences
• Web Clipping (Palm), Quality Aware Transcoding (Duke
Univ.) TranSqui (Univ. of Massachusetts), Web Sphere
Everyplace Access (IBM)
• Transcoding technology can be a remote resource in
distribute services.
July.03.2003
[email protected]
Page. 17
Part III. Enabling universal accessibility in
Services
July.03.2003
[email protected]
Page. 18
Modular Data Pipelining Architecture (MDPA)
• Basic Constraints for the software architecture for
enabling Universal Accessibility
–
–
–
–
–
–
–
July.03.2003
Modularity
Adaptability
User Interactivity
Flexibility
Reusability
Scalability
Interoperability
[email protected]
Page. 19
Modular design of Data Processing
IBM
computation unit
Generating user presentation
real time
multimedia
Database
DAT
CTL
DTX
PCL
MCL
User event transmit
Universal user devices
• DAT (Data) stage: Data source (facing remote resources)
• CTL (Control Logic) stage: Semantic control of the data
• DTX (Data Transformer) stage: Process of filtering the object for
heterogeneous devices
• PCL (Presentation client) stage: Generating abstract presentation for
each client
• MCL (Minimal client) stage: Actual drawing onto user device
July.03.2003
[email protected]
Page. 20
Event Model in MDPA (I)
• MDPA is an event based software architecture
• Two directions of dataflow
– Event transmission
– Presentation Generation
User Event Transmitting
DAT
CTL
DTX
PCL
MCL
<?xml vers
<!DOCTYPE
<!--local DT
<svg width=
<desc>This
SVG document
with the original
size of 1200 x 2000
DOM tree of
SVG
document
Rendered Image
with CSS for PDAs
(resolution of
160 x 160)
SVG browser
for PDAs
Actual Display
on PDA
Generating Presentation View
July.03.2003
[email protected]
Page. 21
Event Model in MDPA (II)
EXT event DAT event CTL event DTX event PCL event
MCL event
User Event Transmitting
DAT
CTL
DTX
PCL
MCL
<?xml vers
<!DOCTYPE
<!--local DT
<svg width=
<desc>This
SVG document
with the original
size of 1200 x 2000
DOM tree of
SVG
document
Rendered Image
with CSS for PDAs
(resolution of
160 x 160)
SVG browser
for PDAs
Actual Display
on PDA
Generating Presentation View
• Different stages have different data processing
• User Event is a combination of multiple event types or single event type : e.g.
loading new URL includes moving mouse to text window (MCL) + Typing
text (MCL) + Loading new data (EXT)
• We define minimal unit of user event based on the pattern of event
processing.
• We should show MDPA supports these event types successfully.
July.03.2003
[email protected]
Page. 22
Architecture of Each Stage
• Interface: A set of ports facing other
stages, users, or resources.
• Presentation Filters: Processes for
generating user presentations.
• Event Filters : Processes for
transforming user event to deliver
to next stage based on the original
information
• Stage Manager : Basic concurrency
management.
• Finally, Event type is decided by
which stage executes its Event
Processor.
Output Port
facing DAT stage
Stage Manager
Event
Filter
Event
Processor
Input Port facing
DTX stage
Presentation
Filter
Output Port
facing DTX stage
CTL stage
Filtered event by
event filter in
DTX stage
Output Port facing
CTL stage
Input Port facing
CTL stage
User presentation
generated by
event processor in
CTL stage
Stage Manager
Event
Filter
Event
Processor
Input Port facing
PCL stage
Presentation
Filter
Output Port facing
PCL stage
DTX stage
Filtered event by
event filter in
PCL stage
July.03.2003
Input Port
facing DAT stage
[email protected]
User presentation
filtered by
presnetation filter
in DTX stage
Page. 23
Modeling of MDPA
• Using software architecture pattern of “Pipes and Filters” :
suitable for presenting data flow
– Each processing step is encapsulated in a filter component
– Data is passed through pipes between adjacent filters.
– Recombining these filters allows us to build families of related
filters.
• Representation of data process in MDPA : Modular PTnets (Place and Transitions petri-net)
– The main uses of Petri nets are for discrete event simulation and
modeling complex system such as communication protocols or
distributed databases.
– State-based formalism
– Graphical expressiveness
– Well developed tools
July.03.2003
[email protected]
Page. 24
Modular PT-net
• Original PT-net includes four
components: a set of place P, a
set of transitions T, a weight
function W, and a mapping
function for the initial marking
M o.
• Modular PT-net : sharing Place
or Transition, so, easy to
represent Modular approach for
big systems [Christensen+00].
• Each module should be able to
generate output independently.
• Each stage of MDPA is
represented as a Module and
sharing transitions (interface
between stages)
token
Place A
Transition T
Place A
Fusing Transition T Place B
Module A
Place B
Module B
Two modules sharing one transition
July.03.2003
[email protected]
Page. 25
A Service with MDPA
• A Service : A set of processes from capturing user event to delivering
user presentation
• Defining of a Service within MDPA following the Definition of Modular
PT-net
– Define Stage as a Module of Modular PT-net
– There is no fusing Place
– Define Interface as a fusing Transitions
 Put it altogether!
Event Transmit
Interface
Interface
Interface
Interface
Interface
Interface
Output Input
Output Input
Output Input
Output Input
Output Input
Resource
Input Output
Input Output
Input Output
Stage DAT
Stage CTL
Stage DTX
Input Output
Stage PCL
Input Output
Stage MCL
User
User Presentation Generating
Place
July.03.2003
Fusing
Transition
Arc
[email protected]
Page. 26
Definition of a Service
Define a Service architecture following Definition of Modular PT-net
DEFINIT ION4.12A Service wit h MDP A
T hesingle servicein MDP Ais defined as a t ripleMNService= (S, P F, T F)such t hat:
(i)
S is a finit eset of modules called as " st age".
S = {P TDAT , P TCTL, P TDTX , P TPCL , P TMCL }
W hereeach st age defined as a P T - net such t hat:
P TDAT = (PDAT , TDAT , WDAT , MoDAT );
P TCTL = (PCTL, TCTL, WCTL, MoCTL);
P TDTX = (PDTX , TDTX , WDTX , MoDTX );
Def. 4.7 ~ 4.11
P TPCL = (PPCL , TPCL , WPCL , MoPCL );
P TMCL = (PMCL , TMCL , WMCL , MoMCL );
(ii)
T hereis not fusing placein MNService, T hereforeP F = {}
(iii)
W e define Int erfaceof st age s as a set of fusing t ransit ions in st age s,
Int erface
s = Input P ort
s  Out put P ort
s where,
Input P ort
s is a set of fusing t ransit io
ns, such t hat:
ip  s, O(ip) s, and I(ip) s' where s  s'.
Out put P ort
s is a set of fusing t ransit ions, such t hat
op  s, I(op) s, and O(op) s' where s  s'
T hereis a set of fusing t ransit ions in MNService,.
T Fservice = Int erface
DAT  Int erface
CTL
 Int erface
DTX  Int erface
PCL  Int erface
MCL
July.03.2003
[email protected]
Page. 27
Representation of Stage with Modular PT-net
Definition 4.7 ~ 4.11
Presentation Filters
Fusing transitions
: Interface
PCL DTX DAT CTL EXT
event event event event event
Filtered
Presentation
from PCL
t19
Filtered
events
from MLC
receive presentation
from PCL stage
Input Port
Output Port
facing PCL stage facing PCL stage t20
Generated
Presentation
m15
Event
t14 is in Queue
m13
m14
Presentation is receive
from PCL stage
t16
Event Filters
Presentation
filtering
t15
Presentation
filtering
Event
processing
t21
t22
t23
transmit event
to PCL stage
t24
t13
m7
m8
m9
m10
m11
m12
filtered event
Event
Queuing
t7
t8
t10
t9
t11
t12 filtering event
m16
Presentation
Filter
Caching Output
m17
t17
Output Port
facing User
m1
Filtered
presentation
Event
Processor
Filtered &
stored Output
Display
Presentation
t18
m18
m3
m2
Place
July.03.2003
Transition
Fusing
Transition
m5
m6
received event
Event
Filter
This stage is
available
Stage
Manager
Input Port t1
facing User
t2
t3
User
Presentation
Stage Manager
m4
t4
t5
t6
receive event
Events
from User
Arc
MCL PCL DTX DAT CTL EXT
event event event event event event
Event Processor
[email protected]
Page. 28
Tools for Modeling and Analysis
• Demonstration : Visual Object net++
Technical University of Ilmenau, Germany
http://www.systemtechnik.tu-ilmenau.de/~drath/visual_E.htm
• Analysis : Tina Ver. 2.5.1
LAAS ( Laboratory for Analysis and Architecture of Systems), France
http://www.laas.fr/tina/announce-2.5.1.html
July.03.2003
[email protected]
Page. 29
Analysis of Modeling MDPA
• Specification : Specify every path for every event types (Table 4.2) 
specify every paths inside of stage for each event
• Implementation : Defining a Modular PT-net (Def.4.7 ~ 4.12)
• How to verify : Specification .iff. Implementation ?
– We analyze our implementation with PT-net tools.
– Show the specification is satisfied with our PT-net implementation (Is
each path strongly connected?)
• SCC (Strongly Connected Components) : Two nodes are strongly
connected, iff, there exists a finite directed path, which starts at a
source node and ends in a destination node.
• Finally, each path specified in the stage (module) is strongly
connected.
• Obviously, since we used fusing transitions for representing
interfaces, each interface is strongly connected.
• No formal verification is included in this dissertation.
July.03.2003
[email protected]
Page. 30
Aggregation of Services
• Integrating services and enabling multiple service
instances for user
–
–
–
–
Interface facing each data pipeline
Shared process of presentation generation
Independent event transmission to each data pipeline
Unified MCL stage for a single device
User Presentation Generation
Service Instance A
Aggregated
Service
Input port facing
DTX of Service A
Input Output
Input Output
Input Output
ResourceA
Input Output
Service Instance B
Input Output
ResourceB
DAT
Place
July.03.2003
Input Output
Input Output
CTL
DTX
FusingPlace
Transition
Between
Service A and B
[email protected]
Input Output
Input port facing
DTX of Service B
PCL
Fusing Transition
Between Service
A and B
MCL
User
Arc
Page. 31
Collaborative service with MDPA
• MDPA considers the interoperability between users in
P2P Grid environments.
• Asynchronous collaboration
• Synchronous collaboration (real-time collaboration, 10 ~
1000 msec.)
– Shared Display : Sharing image data in the master’s framebuffer
– Shared Input Port : Sharing user input event and generating
individual display with the full set of data processing.
– Shared Output Port : Sharing user output, more flexible than
shared display because it is customizable.
• The collaboration model within MDPA aims to support a
flexible collaborative environment for heterogeneous
users.
July.03.2003
[email protected]
Page. 32
Shared Display model
• Immediate sharing of the bitmap image data from the master
user’s framebuffer memory
• Basic filtering (compression data, etc) is performed in the Messaging
middleware
• Master/Participants share all stages except for the MCL stage
• Therefore easy to implement. However, this is less flexible.
Event Transmit
Interface
Interface
Interface
Interface
Interface
Interface
Output Input
Output Input
Output Input
Output Input
Output Input
Input Output
Resource
Input Output
DAT
Filtering for
Heterogeneous
devices
Place
Input Output
CTL
Fusing
Transition
DTX
m1
t1
Arc
t2
Transition
Input Output
PCL
Filtering
m3
Adjusted
object for
participant
A
Filtering
m2
m4
Input Output
Adjusted
object for
participant
B
Master
Input
port
Master's
t3
output
Master's
output t4
MCL
Output
Input
port
MCL
Participant A
Output
MCL
Participant B
User Presentation Generating
July.03.2003
[email protected]
Page. 33
Shared Output Port Model
• Sharing Output port to PCL stage
• Basic content adaptation is possible
• Each participant should have PCL and MCL stages
Event Transmit
Interface
Interface
Interface
Interface
Interface
Interface
Output Input
Output Input
Output Input
Output Input
Output Input
Input Output
Resource
DAT
Input Output
CTL
Input Output
DTX
Input Output
Input Output
PCL
MCL
Master
Interface
Interface
Interface
Interface
Input Output
PCL
Place
Fusing
Transition
Input Output
Participant A
MCL
Interface
Interface
Arc
Transition
Input Output
PCL
Input Output
MCL
Participant B
User Presentation Generating
July.03.2003
[email protected]
Page. 34
Shared Input Port Model (CTL Event)
• Every user has full set of MDPA
• Only sharing user input event
• For each shared input event each service generates user
presentation
Interface
Interface
Interface
Interface
Interface
Interface
Output Input
Output Input
Output Input
Output Input
Output Input
Input Output
Resource
Resource
July.03.2003
DAT
Input Output
Input Output
CTL
DTX
Input Output
PCL
Input Output
MCL
Master
Output Input
Output Input
Output Input
Output Input
Output Input
Input Output
Input Output
Input Output
Input Output
CTL
DTX
Input Output
PCL
DAT
[email protected]
MCL
Participant
Page. 35
Shared Input Port Model (DAT/EXT Event)
• DAT event
Interface
Interface
Interface
Interface
Interface
Interface
Output Input
Output Input
Output Input
Output Input
Output Input
Input Output
Resource
DAT
Output Input
Input Output
Input Output
CTL
DTX
Input Output
PCL
Input Output
MCL
Master
Output Input
Output Input
Output Input
Output Input
Input Output
Input Output
DTX
Input Output
PCL
Input Output
CTL
Interface
Input Output
Resource
DAT
MCL
Participant
• EXT event
Interface
Interface
Interface
Interface
Interface
Interface
Output Input
Output Input
Output Input
Output Input
Output Input
Input Output
Resource
DAT
Output Input
Input Output
Input Output
CTL
DTX
Input Output
PCL
Input Output
MCL
Output Input
Output Input
Output Input
Output Input
Input Output
Input Output
Input Output
Input Output
Master
Interface
Input Output
July.03.2003
[email protected]
Page. 36
Application –Aware Transcoding
for Shared Display
• Goal : Fast and Efficient
Propagation upon change of the
master’s display.
• Approach: Reduces size of data
over the wireless network
Desktop PC
LAN/J2SE
1106 x 930
4017.9 KB
Bitmap Image
– Graphic Format Transformation
for specific devices (Based on Java
MDPA)
– Data Compression
Filtering shared display message
– Color Depth Adjustment
for wireless devices
– Image Resolution Adjustment
– Aggregative Update
PDAs(iPaq3900)
Resolution:240 x 320
Wireless LAN 802.11b
J2ME(Personal Java)
Image size:553 x 465
50.9 KB Bitmap Image
July.03.2003
[email protected]
SmartPhone(treo300)
Resolution:160x160
3G wireless comm.
J2ME(MIDP)
Image size:120x100
1.7 KB/PNG image
Page. 37
Application –Aware Transcoding
for Shared Export
• Goal : Support Flexible view
points.
• Approach: Manipulate abstracted
data and Reduce size of data
– Graphic Format Transformation
for specific devices (Based on Java
MDPA)
– Stylesheets (CSS)
– Data Compression
– Image Resolution Adjustment
Styling with CSS for Black/White PDAs
Workflow of Generating image for Shared Export (Collaborative SVG browser)
SVG Document
Rendering
Stylesheet
July.03.2003
Image
Formatting
Data
Compression
User Profile
[email protected]
Page. 38
Part IV. Prototype of MDPA
July.03.2003
[email protected]
Page. 39
Challenge of the Web Service Architecture
• Provide clear framework with the representation of resources and well
defined interfaces (ports) specified in WSDL
• Enable the development of collaborative services that can interoperate with
existing services implemented in different ways (Perl, Phython, Java, etc.)
• Support for unified user setup of collaborative environment for multiple
services.
• Easy to reuse/discover for integrated collaborative features.
• Support for object sharing and integrated service environments
July.03.2003
[email protected]
Page. 40
Developing MDPA Service as a Web Service
• Each service is encapsulated as
WS semantics
• Interfaces between services,
users and resources are
defined clearly in WSDL
• Each WS is accessible to other
WS via a resource facing port.
• Multiple services are
integrated into a Portlet
aggregation environment
(Jetspeed, WebSpheres)
• Accessible to other resources
(including DB, file systems,
URL, 3rd party services, A/V
conference services, etc.) via
resource faced “ports”.
• Flexible packaging method is
possible
July.03.2003
Collaborative Applications as
Web Services: defined with
WSDL
[email protected]
WSDL
WSDL
WSDL
WSDL
WWWW
S S S S
Collaborative
Collaborative
Collaborative
Service/stage
Application
Application
ApplicationR R R R
P P P P
Web
Service
Web
Web
Service
Web
Service
Service
User Face Web Service
WSRP Ports : define
WS as a Portlet
Page. 41
Packaging and Structuring the service
Remote
resources
Example 1. Put it all together in one WS
WSDL
W
DAT
CTL
DTX
P
Web Service
Remote
resources
WSDL
W
DAT
WS
P
WS
CTL
P
P
S
R
DTX
WS
S
R
W
CTL
WS
P
S
R
Example 3. Accessing multiple WSs in one stage
July.03.2003
W
P
S
R
Remote
resources
WSDL
WSDL
DAT
WSDL
W
WS
W
Example 2. One Stage in One WS
WSDL
S
R
S
R
[email protected]
WS
WS
WS
DTX
Page. 42
Carousel Web Service
• Prototype of Real-time collaborative service with MDPA.
• DAT+CTL+DTX is designed as a Web Service (example.1)
• PTL is implemented in two phases
– Markup Languages (HTML/WML)
– Layout of Client application (J2SE AWT APIs/J2ME MIDP)
• MCL is supported in various ways (Traditional PC
monitor(32bit true color)/ iPaq(320X240 12bit color)/
Treo300(160x160 8bit color)) based on J2ME technology
• Real-time collaboration requires efficient and reliable
messaging framework
July.03.2003
[email protected]
Page. 43
Distributed Event Service :NaradaBrokering
• Based on a network of cooperating broker nodes
– Cluster based architecture allows system to scale to arbitrary size
• Originally designed to provide uniform software multicast to support realtime collaboration linked to publish-subscribe for asynchronous systems.
• Now has four major core functions
– Message transport (based on performance measurement) in
heterogeneous multi-link fashion
– General publish-subscribe including JMS & JXTA and support for RTPbased audio/video conferencing
– Filtering for heterogeneous clients
– Federation of multiple instances of Grid services
July.03.2003
[email protected]
Page. 44
Linkage with Event Service
Remote Collaborative
Web Services : integrated
As portlets in Portal
Aggregator
Collaborative
Collaborative
Collaborative
WebService
Collaborative
WebService
WebService
Web Services
Portal Aggregator
Event Service
Real-time event is processed
By the event service
(NaradaBrokering)
: text message/framebuffer
image/URLs/Microsoft events,
etc.
Heterogeneous Users
July.03.2003
[email protected]
Page. 45
Architecture of CAROUSEL Web service
Session Manager
Collaborative
Web Services
Collaborative
Web Services
Collaborative
Web Services
NB publish/subscribe
Portlets
Event Service
Portal Aggregator
NB publish/subscribe
Traditional Desktop devices
July.03.2003
Handheld wireless devices
[email protected]
Page. 46
Scenario
Aggregative Portal
1. Login
2. Setup
3. User setup input
Session Manager
4. User preference/
service request
5. Service Topics /
Available NB
Information
6. Service
Invocation
7. Service Topics
NB information
user
8. User Event
9. Service Output
NaradaBrokering
July.03.2003
[email protected]
Collaborative WS
Page. 47
Security Framework
• Required in both phases of network communication
• Within Traditional WS Architecture
– (Web Service Portal, Web Service  Web Service)
– Popular Security Solution is possible (SSL, SOAP Security
Extentions (W3C), S-HTTP, etc)
• Within Real-time messaging
–
–
–
–
–
July.03.2003
Inherit Security Framework of NaradaBorkering
Topic based encryption of message exchanges
Key Management Center (KMC) manages key distribution
Ensures end-to-end message security
Mobile device should have encryption/decryption module if it is
the generator/consumer of secure messages respectively.
[email protected]
Page. 48
Reliability and Fault Tolerance
• Reliability and Fault Tolerance also should be considered
in Two Phase of network communications
• Within the traditional WS Architecture
– Portal service for Mobile Device is stateless.
• Within the Real-time Messaging Service
– Inherit reliability and fault tolerance scheme from high-level
messaging such as JMS scheme (NaradaBrokering is JMS
compliant)
– Access point for the mobile device should provide reliability.
Application layer protocol can ensure the reliability (e.g.
message acknowledgements, status of network communication
links, etc)
July.03.2003
[email protected]
Page. 49
Shared Input Port Model with
Web Service Infrastructure
Collaboration as a WS
Set up Session
Event
Service
R Web U
F
F
Servic
I
I
e
O
O
WS
Viewer
R Web U
F
F
Servic
I
I
e
O
O
WS
Viewer
WS
Display
Master
WS
Display
Other
Participants
R Web U
F
F
Servic
I
I
e
O
O
July.03.2003
[email protected]
WS
Viewer
WS
Displa
y
Page. 50
Select Collaborative SVG Portlet : HTML
Select Collaborative SVG Portlet
for Desktop environment
July.03.2003
[email protected]
Page. 51
Select Collaborative SVG Portlet : WML
Select Collaborative SVG Portlet
for PDA environment
July.03.2003
[email protected]
Page. 52
Setup the collaborative environment
Setup Operating System
Setup User Device Resolution
Setup Types of Display
Setup from PDA
July.03.2003
[email protected]
Page. 53
Collaborative Browser for Users
Input URL of
SVG document
Browse
Ready-to-use image
from SVG content server
Catch user’s collaborative
events from viewer
July.03.2003
[email protected]
Page. 54
Part V. Contributions and Future Work
July.03.2003
[email protected]
Page. 55
Conclusions
• This dissertation presented a modular architecture for designing
services in the context of the P2P Grid.
• Refined the data process as a set of modular stages.
• Categorized the user event based on the definition of stages.
• Showing the software architecture based on the Filters and Pipes
pattern, and modeled with Modular PT-net theory
• Modeling of aggregation/ collaboration for services with MDPA
• Presented how the architecture is deployed with a Web service
infrastructure
• Implemented the prototype of a collaborative SVG Web service for
heterogeneous environments
• Explained how MDPA incorporates and interacts with content
adaptation technologies.
July.03.2003
[email protected]
Page. 56
Contributions
• Service Design: MDPA provides a software architecture that incorporates
heterogeneous user device profiles into its main service design phase. This
enables the P2P Grid service designed using MDPA to support diverse user
devices while ensuring maximum quality-of-service to each device.
• Refinement of Data Processing : MDPA modularizes data processing, and
defines each process with distinguishable characteristics.
• User Interactive Event Model : Based on the definition of Data Processing,
MDPA provides a user event model
• Interoperable Data Processing Architecture : Multiple sets of data
processing can interoperate with each other.
• Collaboration: A modeling of collaboration in different degree of flexibility
• An adaptable system to support Universal Accessibility : MDPA provides
an environment for developing universally accessible software with its well
defined data processing stages and schemes of interoperating with other
service instances.
• Prototype with a demonstrative application : Carousel Web service
July.03.2003
[email protected]
Page. 57
Future Work
• User Interface : Flexible
MDPA compliant data
object
• Intelligent Messaging
middleware: special
features for mobile
devices
• Deployment with OGSI
• Extend the adaptability to
Wearable Devices
July.03.2003
[email protected]
Page. 58
Thank you!
Demonstration and Source Code is downloadable from
http://grids.ucs.indiana.edu/ptliupages/projects/carousel/
July.03.2003
[email protected]
Page. 59
Future Work 1. User Interface
• For mobile devices, network/computing capability is
improving at a rapid rate.
• User display has the obvious size limit for miniaturized
mobile devices.
• Consider flexible accessibility to data object.
• Should be defined universally and adaptable to the
service and device.
July.03.2003
[email protected]
Page. 60
Future Work 2. Intelligent Messaging Middleware
• Accessible from heterogeneous network communication
environments seamlessly.
• Should support basic data compression, security,
reliability, and fault-tolerance.
• Should ensure end-to-end service feature for mobile
devices.
• Extend the concept of Web service infrastructure –
Service discovery/aggregation should be possible in
messaging middleware as well.
• Provide Reliability/Fault Tolerance for mobile devices
July.03.2003
[email protected]
Page. 61
Future Work 3. Deployment with OGSI
• OGSI (Open Grid Service Infrastructure) provides an
environment to integrate key Grid technologies with WS
mechanisms to create a distributed system framework
• Since OGSI inherits WS, we expect MDPA to be
compliant with OGSI.
• More refined Port type (extended WSDL) can provide
more intelligent data processing for P2P Grid service
• Stateful WS concept of OGSI can support easier lifetime
management and multiple instances for collaborative
services in its aggregated portal environments
July.03.2003
[email protected]
Page. 62
Future Work 4. Wearable Devices
• We can extend the adaptability
issue to wearable device and
more advanced wireless
network communications
(PAN, satellite)
• As devices get more powerful
and specialized, a more
integrated and role-based
design is required.
July.03.2003
[email protected]
Page. 63
Example: Shared SVG Web Service
• SVG (Scalable Vector Graphics) is a 2D vector graphics
standard format from W3C with a structured XML
syntax
• DOM based structure, so clearly represents object
instance in each stage of process
• Prototype of Shared Input port model
– Every user has individual service instance.
– Collaborative/Non-collaborative user event is processed
– User preferences and device profile is defined in setup session.
• Minimum Functionality in User device : Easy to adapt
new devices
July.03.2003
[email protected]
Page. 64
Defining the Interface
• Dataflow in MDPA is performed via communication with interfaces
including input and output ports
• In Modular PT-net (shared transition), input/output ports are
represented as fusing transitions.
Definit ion4.6 Int erface.
T heInt erfaceof a st age s is defined as,
Int erfaces= Input port s  Out put port s,such t hat:
(i)For node x, we use S(x) t odenot et hest age t o which x belongs.
(ii)Inputportis a set of t ransit ions t such t hat ,
(S(O(t )))= s  (S(I(t ))= s' ) (s  s' ),
(iii)Out put portis a set of t ransit ions t such t hat ,
(S(I(t )))= s  (S(O(t ))= s' ) (s  s' ).
July.03.2003
[email protected]
Page. 65
Universal Access in CAROUSEL Web service
F
I
R
O
WSDL
Application or
Content source
Web Service
U
O
F
I
Selection
View
(NaradaBrokering)
Event Service
Filter
Customized View
Selector
Control Channel
Portal
(Aggregator)
•Customized User-Facing Ports
-setup for device and user preferences
Customized View
Filtering data for PDAs and Smartphones with
different message topics
Control Channel
User
Profile
Render
July.03.2003
[email protected]
Page. 66
Customizing User Facing Port
• Based on General Purpose Web service aggregator
(Apache’s Jetspeed)
• Supporting HTML/WML
• Customizable Layout of portal (integrating environment)
• Provide environment for selecting preferences, hardware
capabilities, network service, etc..
• Deliver the information to session manager
July.03.2003
[email protected]
Page. 67
Filtering in Event Service
Service output for PC
Service output for iPaq
Service output for regular
wireless smartphone
• Non-collaborative/Collaborative
event filtering
• Collaborative Event is processed
depending on the type of devices
• Master user/Participants filtering
 Filtering by the topics of
Publish/Subscribe messaging
system (NaradaBrokering)
July.03.2003
Service output
for Treo using 3G
[email protected]
Page. 68