Design and run-time bandwidth contracts for pervasive computing middleware

1
Design and run-time bandwidth contracts for
pervasive computing middleware

• Peter Rigole
• K.U.Leuven Belgium
• Peter.Rigole_at_cs.kuleuven.ac.be

2
Challenge

• Pervasive computing
• Flexible computing
• requirements
• Restricted host platform
• Scarce resources

MPAC Middleware 2003 Workshop
Peter Rigole
3
Vision

• Combining
• Resource aware applications
• monitoring, prediction, reliability
• Fine-grained applications
• run-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
4
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
5
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
6
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
7
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
8
QuO

• Drawbacks
• 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
  adaptation
• Could we let the middleware make these decisions?

MPAC Middleware 2003 Workshop
Peter Rigole
9
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
10
Contracts for SEESCOA components

• Hier nog meer over ?

MPAC Middleware 2003 Workshop
Peter Rigole
11
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
12
Representation

• 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 lt m
• n lt min ITMB
• o lt avg ITBM lt p
• q lt var ITMB lt r

• avg MS g
• avg MS acc h
• var MS i
• var MS acc j
• max MS k
• min MS l
• max MS lt s
• t lt min MS
• u lt avg MS lt v
• w lt var MS lt x

MPAC Middleware 2003 Workshop
Peter Rigole
13
Representation
MPAC Middleware 2003 Workshop
Peter Rigole
14
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
15
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
16
Example projector case
MPAC Middleware 2003 Workshop
Peter Rigole
17
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