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@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. 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

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

12. 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

13. 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

14. 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