Design and run-time bandwidth contracts for pervasive computing

middleware

Peter Rigole

K.U.Leuven – Belgium

Peter.Rigole@cs.kuleuven.ac.be

Challenge

• Pervasive computing:Flexible computing

requirements

• Restricted host platform:Scarce resources

MPAC – Middleware 2003 Workshop Peter Rigole

Vision

Combining:

1. Resource aware applicationsmonitoring, prediction, reliability

2. Fine-grained applicationsrun-time scaling: removing, relocating, updating comp.

In a design-time methodology– including awareness of limited resources– maintaining the flexibility to enable perv. comp.

MPAC – Middleware 2003 Workshop Peter Rigole

State of the art: SEESCOA

• Component oriented software architecture

• For embedded devices

A SEESCOA application consists of:– components

– ports

– port specifications

– connectors

– port contracts

– component contracts

Blueprints – instance model – CCOM tool - contracts

MPAC – Middleware 2003 Workshop Peter Rigole

SEESCOA component specification

• Basis of run-time reliability and flexibility

Four levels:– Syntactic level

– Semantic level

– Synchronization level

– QoS level

MPAC – Middleware 2003 Workshop Peter Rigole

SEESCOA run-time

• Executing environment– Loads, instantiates, links components– Manages connections (local or remote)– Delivers and executes messages sent between ports

MPAC – Middleware 2003 Workshop Peter Rigole

State of the art: QuO

Quality Objects:– Applications adapting to QoS offered by resources– Application designer decides HOW the application

should adapt to changes in resource availability (QDL)– Providing:

• Several layers of tools (code generators based on QDL, …)

• Adaptive distributed applications

• CORBA development process (code generators, support libs)

MPAC – Middleware 2003 Workshop Peter Rigole

QuODrawbacks:

– Object level (no real components)– Client – Object relationship

• Contracts, RMI, stubs, skeletons, …

– Design-time distribution of objects– Run-time reconfiguration is difficult to achieve– QDL: description of all feasible QoS states = burden

Burden for program designer to describe adaptationCould we let the middleware make these decisions?

MPAC – Middleware 2003 Workshop Peter Rigole

Contracts for SEESCOA components

• Contracts on all components and ports– no decisions for distribution at design time

Requirements:– Easy for application designers

• In terms of parameters that are relevant to app. designers

– Multiple contracts possible• When contracts indirectly depend on certain resources

– Fallback mechanism• For contracts that can not be established

(relocation unsuccessful)

MPAC – Middleware 2003 Workshop Peter Rigole

Example: bandwidth contracts• Technology independent

– various implementations of physical layers

• Detail– exact required bandwidth is never known– no complex dependencies with application details– tradeoff between expressiveness and manageability

• Solution: statistical expressions on meaningful parameters– MS: Message Size

– ITBM: Interval Time Between Messages

MPAC – Middleware 2003 Workshop Peter Rigole

Representation

MPAC – Middleware 2003 Workshop Peter Rigole

• Statistical analysis:– Port output:

• avg ITBM = a

• avg ITBM acc = b

• var ITBM = c

• var ITBM acc = d

• max ITBM = e

• min ITBM = f

– Port input:• max ITMB < m

• n < min ITMB

• o < avg ITBM < p

• q < var ITMB < r

• avg MS = g• avg MS acc = h• var MS = i• var MS acc = j• max MS = k• min MS = l

• max MS < s• t < min MS• u < avg MS < v• w < var MS < x

Connection setup and negotiation• Exchanging contracts• outgoing flow behaviour must match incoming

requirements• Agreement Connection contract• Now run-time system judges feasibility

– based on knowledge about available bandwidth

• When declined: further negotiation– Solutions: other contracts, relocation of components

• No solution: notify application manager– application/user reacts

MPAC – Middleware 2003 Workshop Peter Rigole

Example: projector case

• SlideInterpreter connects with SlideVisualizer

• but, Bluetooth connection not enough bandwidth

systems declines connection

Solution: relocating SlideInterpreter component

MPAC – Middleware 2003 Workshop Peter Rigole

Concluding remarks• Appropriate architectures for ad hoc systems:

– let middleware decide how to distribute and adapt applications

– judging by resource consumption and availability– Cyber foraging: searching for distributed resources

• Difficulty: realistic adaptation strategies– without sacrificing application availability

• Fine-grained application structure is required– for flexibility– for supporting dynamic resource management techniques

MPAC – Middleware 2003 Workshop Peter Rigole