univ. notre dame, september 25, 2003 support for run-time adaptation in rapidware philip k. mckinley...

18
Univ. Notre Dame, September 25, 2003 Support for Run-Time Support for Run-Time Adaptation in RAPIDware Adaptation in RAPIDware Philip K. McKinley Software Engineering and Networking Systems Laboratory Department of Computer Science and Engineering Michigan State University (http://www.cse.msu.edu/sens)

Upload: marian-debra-flynn

Post on 28-Dec-2015

213 views

Category:

Documents


0 download

TRANSCRIPT

Univ. Notre Dame, September 25, 2003

Support for Run-Time Adaptation Support for Run-Time Adaptation in RAPIDwarein RAPIDware

Philip K. McKinleySoftware Engineering and Networking Systems Laboratory

Department of Computer Science and Engineering

Michigan State University

(http://www.cse.msu.edu/sens)

Presentation Overview MSU SENS Laboratory RAPIDware Project Overview MetaSockets and Experiments Adaptive CORBA Template (ACT) Conclusions

MSU SENS Laboratory The Software Engineering and Network Systems

Laboratory supports research in:– software engineering– distributed computing– network protocols and real-time systems– fault tolerance and security – formal methods, code generation – compilation/analysis of concurrent systems

Research sponsored by NSF, ONR, DARPA, DOE, NASA, EPA, and several industrial partners

SENS Personnel Betty Cheng - software engineering, formal

methods, object-oriented development Laura Dillon - formal methods for concurrent

systems, real-time systems Phil McKinley - distributed computing, network

protocols, adaptive middleware Kurt Stirewalt - software analysis, interactive

systems, model checking Sandeep Kulkarni - fault tolerance, security ~30 graduate research assistants

Mobile Computing Testbed

Multiple-cell WLAN

– Various Wireless LANs

– WLAN analyzers

Mobile computers

– Dell laptops (Windows, Linux)

– iPAQ handhelds(Familiar Linux, Blackdown Java)

– Xybernaut MA-V wearables (Windows)

RAPIDware Project Funded by U.S Office of Naval Research

– Adaptable Software / Critical Infrastructure Protection – Outgrowth of Presidential Decision Directive 63 (May ’98)

Goal: Software (middleware) that can adapt to:– Changing environmental conditions– Hardware and software component failures– Possible security threats or violations– Heterogeneous platforms– Dynamic user requirements

RAPIDware involves:– 5 SENS faculty members and 10 graduate assistants

Middleware for “Internet Speed” development and evolution of applications must support:– Multiple dimensions of adaptability– Autonomous execution of middleware components– Dynamic composition of middleware services

“Principled” methods (compiler/language support, code generation, reflection, run-time checks, etc) needed to help ensure reliability, correctness, reusability, security

RAPIDware Goal... Enable users to communicate seamlessly and

securely across a diverse, dynamic, and evolving mobile computing and communication infrastructure.

Target domain is multimedia collaborative computing systems– military command and control – management of industrial installations– crisis management systems– computer supported cooperative work

Example: Enabling systems to operate through failures and attacks in network-centric battlefield.

MotivationsHighly variable wireless channels, changing topology, frequent disconnections

Motivations

Interaction withsensor networks

Motivations

Military Operations in Urban Terrain (MOUT)

Motivations

Collaboration among disparateplatforms and networks

Key Challenges Realizing tradeoffs among different cross-cutting

concerns:– Quality of service– Platform characteristics– Security policies– Energy consumption– Fault tolerance

Adaptation of legacy code, separation of concerns Safe adaptation of software (including dynamic

composition) of software

Adaptive Middleware Adaptive middleware can manage nonfunctional

aspects of the system in coordinated fashion:– actively monitor the system, execute security policies– provide fault tolerance for specified components– adapt to changing environmental conditions– manage energy consumption in battery-powered devices– insulate the application from device/network differences

“Always On” systems – E.g., command and control, many critical infrastructure

systems– require dynamic adaptation in ways not envisioned during

development.

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

RAPIDware Subprojects Programming language abstractions for

adaptation Support for adaptation in legacy applications Dynamic software composition

– Safeness– Efficiency– Fault tolerance– Security

Adaptive group key management Adaptive overlay networks

Middleware Layers

– Domain-Services Tailored to a specific class

of distributed applications

– Common-Services Functionality such as fault

tolerance, security, load balancing and transactions

– Distribution Programming-language

abstraction

– Host-Infrastructure Platform abstraction

Schmidt decomposed middleware into four layers:

Schmidt’s Middleware layers [2]

Mid

dlew

are

Laye

rs

Applications

Domain-Specific Middleware Services

Common Middleware Services

Distribution Middleware

Host-Infrastructure Middleware

Operating Systems and Protocols

Hardware DevicesSyst

emPl

atfo

rm

Part 1: MetaSockets Adaptive Java (AJ):

– An extension to Java that provides language constructs and compiler support for developing adaptive software.

MetaSockets:– An adaptable communication component

developed in AJ– Can be used directly by applications or by

higher-level middleware layers