Design and run-time bandwidth contracts for pervasive computing middleware Peter Rigole K.U.Leuven – Belgium

Challenge Pervasive computing:  Flexible computing requirements Restricted host platform:  Scarce resources MPAC – Middleware 2003 WorkshopPeter Rigole

Vision Combining: 1.Resource aware applications monitoring, prediction, reliability 2.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 WorkshopPeter Rigole

State of the art: S EESCOA Component oriented software architecture For embedded devices A S EESCOA application consists of: –components –ports –port specifications –connectors –port contracts –component contracts Blueprints – instance model – C COM tool - contracts MPAC – Middleware 2003 WorkshopPeter Rigole

S EESCOA component specification Basis of run-time reliability and flexibility Four levels: –Syntactic level –Semantic level –Synchronization level –QoS level MPAC – Middleware 2003 WorkshopPeter Rigole

S EESCOA run-time Executing environment –Loads, instantiates, links components –Manages connections (local or remote) –Delivers and executes messages sent between ports MPAC – Middleware 2003 WorkshopPeter 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 C ORBA development process (code generators, support libs) MPAC – Middleware 2003 WorkshopPeter Rigole

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 WorkshopPeter Rigole

Contracts for S EESCOA 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 WorkshopPeter Rigole

Contracts for S EESCOA components Hier nog meer over ? MPAC – Middleware 2003 WorkshopPeter 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 WorkshopPeter Rigole

Representation MPAC – Middleware 2003 WorkshopPeter 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

Representation MPAC – Middleware 2003 WorkshopPeter Rigole

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 WorkshopPeter Rigole

Example: projector case SlideInterpreter connects with SlideVisualizer but, Bluetooth connection not enough bandwidth systems declines connection Solution: relocating SlideInterpreter component MPAC – Middleware 2003 WorkshopPeter Rigole

Example: projector case MPAC – Middleware 2003 WorkshopPeter 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 WorkshopPeter Rigole