ONR Review – June 11, 2003 RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Philip McKinley, Kurt Stirewalt, Betty Cheng, Laura

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?


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


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.


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


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


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


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


RAPIDware Activities

Assurance in Adaptation

Models Design Correctness

Empirical Theoretical

AOP Reflection

SyntacticContracts

SemanticContracts

Patterns


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:


This page intentionally left blank.


Models

DesignCorrectness

RAPIDware Activities:1. Models2. Design3. Correctness


Empirical Studies in Mobile Computing

P. K. McKinley


Mobile Computing Testbed

Multiple-cell WLAN

– 802.11b (for now)

– WLAN analyzers

– Dual-processor proxies

Mobile computers

– Dell laptops (Windows and Linux)

– iPAQ handhelds(Familiar Linux, Blackdown Java)

– Xybernaut MA-V wearables (Windows)


Our Approach Collect baseline results to quantify tradeoffs

among QoS, energy consumption, security, etc. Translate these results into rules for dynamic

adaptation Focus thus far on communication-related tasks “MetaSockets”

– An adaptable communication component developed in Adaptive Java (discussed later)

– Can be used directly by applications or by other middleware layers


MetaSockets Provide low-level, adaptable communication “Host-infrastructure” middleware (Schmidt)

MetaSockets

Operating system

JVM

Middleware

Application Code

Operating system

JVM

Higher-Level Middleware

Application Code

Adaptive Communication Functionality


Example MetaSocket Architecture

get()

get()

put()

put()

send()close()

Filter P

ipeline

put()

put()

get()

get()

receive()

joinGroup() close()

Filter P

ipeline

send()close()

receive()joinGroup()leaveGroup()close()

getStatus() getStatus()

insertFilter()removeFilter()

insertFilter()removeFilter()

FP

LP

Fltr

MT

SS

LP

FP

Fltr

MT

RS

invocationrefractiontransmutation

FP: firstPacketBuffer

SS: SendMSocketdependencypacket flow direction

RS: RecvMSocket

LP: lastPacketBufferFltr: Filter

MT: MetaSocketThread thread

MetaSendMSocketInternalArchitecture:

MetaRecvMSocketInternal Architecture:


Typical MetaSocket Experiment Audio Streaming Application (ASA)

– 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

...


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


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


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


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


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.


Performance (Real Losses) Insert threshold: 10% Remove threshold: 1%

Automatic Insertion/Removal of FEC (20,4)

0

10

20

30

40

50

60

100

900

1700

2500

3300

4100

4900

5700

6500

7300

8100

8900

9700

1050

0

1130

0

1210

0

1290

0

1370

0

1450

0

1530

0

1610

0

1690

0

1770

0

1850

0

1930

0

Packets

Pac

ket

Lo

ss R

ate

(%)

Network Loss Rate

Application Loss Rate


Energy Management Baselining

Multimeter connected to iPAQs Audio/video/data streams across wireless LAN Measure energy usage, vary FEC parameters


Software measurements… Dynamically measure remaining battery life during

earlier experiment Periodically read from /proc/hal/battery

Software-Measured Battery Life

154156158160162164166168170

Packets

Bat

tery

Life

(min

utes

)

Power Consumption Slope

156158

160162

164166

168

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000 15000 16000 17000 18000 19000 20000

packets

batte

ry Lif

e (mi

nutes

)

no FEC-insert FEC-remove FEC


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


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


Related Work... Adaptive Middleware

– TAO, 2K/Gaia, QuO, MCF, MOST/ADAPT, CEA, CompOSE|Q, MOOSCo, DaCapo++, MASH/Ninja, Rover, Odyssey, MobiWare, etc.

PCL (Adve, et al.) Composition filters (Aksit, et al.) AOP (Kiczales), COOL (Lopes), ... GenVoca (Batory)


Conclusions, Future Directions Conclusions:

– Experiments show that MetaSockets are an effective means to QoS-oriented adaptation.

Future Directions:– A MetaSocket is only one type of adaptable

components. Any AJ component can be metafied and adapted at run time.

– Other cross-cutting concerns (security, power consumption, and fault-tolerance) can be addressed with AJ components.


This page intentionally left blank.


RAPIDware Activities:1. Models2. Design3. Correctness

Models

Design

Correctness


Computational Reflection and

Adaptive Java

E. P. Kasten and P. K. McKinley


Origins of Adaptive Java Many adaptive middleware approaches involve

computational reflection– ability of a process to reason about (and possibly alter) its

behavior Key issue: Openness vs. Preemption Adaptive Java provides language-level support for

adaptability that separates introspection and intercession.

Maes’ original work did not necessarily intertwine these two functions, although most contemporary works do so.


Reflection Base-level program is augmented with one or

more meta levels Entities at a meta level are called meta-objects Meta-object protocol (MOP): collection of

interfaces provided Different MOPs may be defined for different

cross-cutting concerns: performance, fault-tolerance, security, etc.


One possible view... MOPs are constructed from primitive atoms that

provide access to component behavior

May facilitate coordination, consistency-checking, and extension of MOPs


“Orthogonality” Instead of considering orthogonal MOPs,

we assume that they may intersect We do consider orthogonal dimensions

of accessing component behavior:


Components in Adaptive Java Can be considered as objects that have been

“wrapped” in a meta layer that provides:– invocations: provide access to imperative

functionality (base methods)– refractions: operations to observe internal structure

and behavior– transmutations: operations that modify

computational behavior Encapsulation (rather than inheritance) is the

principle mechanism to support dynamic composition


Component Interfaces


Absorption and Metafication

Absorption: Turning a base-level class into a base-level component, redefining computational interface with (mutable) invocations

Metafication: run-time creation of refractive and transmutative interfaces on a component (and so on)


Adaptive Java Implementation

Language extensions developed to support the functionality described above

Adaptive Java 1.0 implemented with source- to-source translation, using CUP parser

Invocations, refractions, and transmutations are all converted into Java classes, which are accessed via a hash map.

Eventually, we may re-implement Adaptive Java as a compiled language, possibly requiring support from the JVM


MetaSocket Absorption Codepublic component SendMSocket

absorbs java.net.MulticastSocket

{

/* constructor */

public SendMSocket(...)

{

setBase(new java.net.MulticastSocket(...));

}

/* invocations */public invocation void send(...) { base.send(...); }public invocation void close() { base.close(); }

}


MetaSocket Metafication Codepublic component MetaSendMSocket metafy SendMSocket { /* constructor */ public MetaSendMSocket(SendMSocket sendMSocket) { setBase(sendMSocket); } /* invocation that "replaces" the send() invocation in SendMSocket */ public invocation void send(...) { ... firstPacketBuffer.put(packet); ... } /* refractions */ public refraction byte[] getStatus() { return filterPipeline.getStatus(); } /* transmutations */ public transmutation void insertFilter(int position, Filter filter) { ... filterPipeline.add(position, filter); ... } public transmutation Filter removeFilter(int position) { ... return filterPipeline.remove(position); } /* private fields */ private java.util.Vector filterPipeline = new java.util.Vector(); PacketBuffer firstPacketBuffer = new PacketBuffer();}


Summary Summarize AJ


Issues From survey


Ongoing Subproject: Perimorph

Documents

ONR Review – June 11, 2003 RAPIDware: Component-Based Design of Adaptive and Dependable Middleware Philip McKinley, Kurt Stirewalt, Betty Cheng, Laura