ONR Review – June 11, 2003 RAPIDware: Component-Based RAPIDware: Component-Based Design of Adaptive and Design of Adaptive and Dependable Middleware Dependable Middleware Philip McKinley, Kurt Stirewalt, Betty Cheng, Laura Dillon, Sandeep Kulkarni Software Engineering and Networking Systems Laboratory Department of Computer Science and Engineering Michigan State University (http://www.cse.msu.edu/sens)
46
Embed
ONR Review – June 11, 2003 RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Philip McKinley, Kurt Stirewalt, Betty Cheng, Laura.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
ONR Review – June 11, 2003
RAPIDware: Component-RAPIDware: Component-Based Design of Adaptive Based Design of Adaptive
and Dependable and Dependable MiddlewareMiddleware
Philip McKinley, Kurt Stirewalt, Betty Cheng,
Laura Dillon, Sandeep Kulkarni
Software Engineering and Networking Systems Laboratory
Department of Computer Science and Engineering
Michigan State University
(http://www.cse.msu.edu/sens)
Software Engineering and Network Systems Laboratory
Motivations Increasingly, distributed software must interact with
both the physical environment and its execution environment
Mobile computing software must adapt to dynamic conditions in several cross-cutting concerns:– Quality of Service– Platform characteristics– Security– Energy Consumption– Fault Tolerance
How to support run-time adaptive behavior not envisioned during development?
Software Engineering and Network Systems Laboratory
RAPIDware Project Goal... Develop adaptive middleware technologies that enable
users to communicate seamlessly and securely across a diverse, dynamic, and evolving mobile computing and communication infrastructure.
Target domain is collaborative computing– military command and control – crisis management systems– management of military/industrial installations– computer supported cooperative work
The methods investigated can be applied to many other domains
Software Engineering and Network Systems Laboratory
Key Issues Separation of Concerns
– Separating adaptive software functionality from the imperative code
Adaptation Assurance– Guaranteeing that adaptations do not change the
imperative behavior of the application in unexpected ways
Migration Path for Development– Support adaptation through existing and new
development paradigms.
Software Engineering and Network Systems Laboratory
Separation of Concerns Can adaptive behavior in “non-functional” concerns
be separated from the (functional) application code?
Doing so can facilitate the development, operation, and maintenance of adaptive systems
How to implement “tradeoffs” among concerns– control changes in communication quality of service – manage energy consumption in battery-powered devices– provide fault tolerance according to specifications– actively monitor the system, execute security policies
Software Engineering and Network Systems Laboratory
Separating Adaptive Behavior
APPLICATION LAYER
observersresponders
Proxy node(e.g., desktop)
Application
Host computer(wired workstation)
“core” middleware components
Application
Host computer(wireless laptop)
Application
Host computer(wireless palmtop)
data paths
MIDDLEWARE LAYER
NETWORK LAYER
Adaptive Logic --decision makers,event handlers,
component loaders
Software Engineering and Network Systems Laboratory
Assurance Issues How to support synchronization and
atomicity during recomposition Use of ``certified components’’ How to define and reach safe points System-wide integrity
– Feature interaction– Global/system invariants
Software Engineering and Network Systems Laboratory
Migration Path Complexity of adaptive software is high Different types of developers:
– Application developers– Adaptation developers
Support existing programming models Transition to new programming
techniques/languages/paradigms
Software Engineering and Network Systems Laboratory
RAPIDware Activities
Assurance in Adaptation
Models Design Correctness
Empirical Theoretical
AOP Reflection
SyntacticContracts
SemanticContracts
Patterns
Software Engineering and Network Systems Laboratory
New Ideas Separation of concerns in adaptive software
Extracting adaptive software functionality from the imperative code Codifying interactions among concerns
Adaptation assurance in recomposable software Integrity in recomposition (synch., state maint.) Safe adaptation points Syntactic and semantic contracts to govern adaptation
Migration path for development Design abstractions that can be realized in existing software development methods Same abstractions can lead to new paradigm for developing adaptive software
RAPIDwareComponent-Based Development of
Adaptable and Dependable Middleware
Impacts Self-healing systems to support mission-critical
communication and computation, despite highly dynamic environmental conditions.
Self-auditing systems that can report and respond automatically to security threats and component failures.
Principled approaches to design of high-assurance adaptable software for use in both military and commercial environments.
What else???
ScheduleYears 1 and 2:
Baseline studies on adaptability in mobile computingTheoretical models for (re)compositon and FTDesign approaches using AOP, reflection, patternsAssurance: synchronization, safe adaptation
Year 3: Feature interaction analysis and software support Decision-making design and experiments
Year 4:
Year 5:
Software Engineering and Network Systems Laboratory
This page intentionally left blank.
Software Engineering and Network Systems Laboratory
– MetaSocket is used instead of MulticastSocket– Live audio stream from a desktop to multiple
iPAQs– Physical experiment configuration:
Access Point
Wireless Receivers
Audio Stream
Wired Sender
...
Software Engineering and Network Systems Laboratory
Wired NetworkWireless Network
TraderF
ilter Pip
eline
ComponentLoader
(CL)
DecisionMaker(DM)
Player
EventMediator
(EM)
LP
FP
MT
RS
PB
PB
AL
NL
FD
FP: firstPacketBuffer AL: RecvAppLossDetector
RS: RecvMSocket
LP: lastPacketBuffer
PB: PacketBuffer FD: FECDecoder
refraction or transmutation
invocation
thread
MT: MetaSocketThreadNL: RecvNetLossDetector
Dependency
Reflection
Event propagation
ASA ComponentInteraction
Software Engineering and Network Systems Laboratory
WLAN Error Characteristics
Most burst errors are very short Small packets help to isolate errors Well suited to use of block-based FEC
Burst error distribution, 320-byte packets
0%10%20%30%40%50%60%70%80%90%
100%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Burst Length (packets)
loc 1
loc 2
Burst error distribution, 48-byte packets
0%10%20%30%40%50%60%70%80%90%
100%
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Burst Length (packets)
loc 1
loc 2
Software Engineering and Network Systems Laboratory
Wireless networks produce dynamic and location dependent packet loss because of signal strength, interference, antenna alignment.
802.11b MAC layer does not provide link-level acknowledgement for multicast frames.
FEC can be used to improving reliability by introducing redundancy into the data channel.
Block Erasure Code Operation
Software Engineering and Network Systems Laboratory
MetaFECEncoder: a component in AJ that absorbs a FECEncoder class. MetaFECDEcoder: a component in AJ that absorbs a FECDecoder class.
Forward Error Correction Filters
invocationrefraction
transmutation
FE: FECEncoder dependency
event propagation paththread
(a) MetaFECEncoder
start()stop() setSrcPacketBuffer()
setDstPacketBuffer()setNK()
FE
getSrcPacketBuffer()getDstPacketBuffer()getNK()
start()stop() setSrcPacketBuffer()
setDstPacketBuffer()setNK()
FD`
getSrcPacketBuffer()getDstPacketBuffer()getNK()
FilterMismatchEventFECMismatchNKEvent
FD: FECDecoder
(b) MetaFECDecoder
Software Engineering and Network Systems Laboratory
Performance (Emulated Losses) FEC Filters inserted automatically at time 8, when loss rate exceeds 30%. FEC Filters removed automatically at time 45, when loss rate drops below 10%. Inserted again at time 60. Removed again at time 80.
Software Engineering and Network Systems Laboratory
Software Engineering and Network Systems Laboratory
MetaSocket Filter Delay (iPAQs) Delay can be significant, largely due to thread synchronization in JVM Some tasks (encryption) too slow for real-time streaming on these
iPAQs Others (FEC decoding, loss monitoring) can keep up with real-time
audio
0
50
100
150
200
250
128 256 384 512 640 768 896 1024 1152 1280
Packet size (bytes)
Ave
rag
e d
elay
(m
sec)
nm
metasocket
aldald-fec-nld 4-8
ald-fec-nld 4-16
ald-fec-nld 4-24
encenc-ald-fec-nld
Software Engineering and Network Systems Laboratory
Current Activities Decision-making software:
– Tradeoffs among QoS, energy, security, FT– Event/Rule based approach– Hierarchical discriminant regression (HDR)
Using MetaSockets to support higher level middleware
Investigations of “safe” adaptation
Software Engineering and Network Systems Laboratory