Architectural Requirements for the Effective Support of Adaptive Mobile Applications

1. Architectural Requirements for the Effective Support of Adaptive Mobile Applications Lawrence Li ICS 243F

2. Topics • Introduction • Drawbacks of Current Approaches • Current Architectural Model • Architectural Requirements • Proposed Architectural Framework

3. Introduction • Mobile applications should adapt to environmental and contextual triggers • E.g. physical location • Current methods of adaptation • System (middleware adapts) • Application adapts • Combination of the above two techniques

4. Introduction (cont’d) • Authors’ criticism of current methods • (Too) Numerous methods of notifying applications of changes • Need control messages from system to applications

5. Drawbacks of Current Approaches, Examples • Power management • Low power mode for hard disk • Lack of coordination between multiple applications leads to inefficient power management during auto-save

6. Drawbacks of Current Approaches, Examples (cont’d) • Conflicting adaptation • Different adaptation mechanisms for different attributes • If applications respond independently to changes • E.g. mechanism for managing power, network bandwidth • If an application responds to power-save by reducing power consumption, network bandwidth availability will increase • Consequently, some other application will increase network bandwidth usage • Other scenarios • Preference – end-to-end approach to adaptation (all components involved in interaction must be able to adapt) • System-wide adaptation policy • Difficult to coordinate

7. Current Architectural Model

8. Current Architectural Model (cont’d) • Application to Middleware • A - Requirements of the application sent to middleware (provides requirements info to middleware – e.g. QoS) • B - Control messages to middleware • Middleware to application • C – Information sent to application (e.g. events) • D – Control messages to application

9. Architectural Requirements (authors’ recommendations) • Extensible set of attributes • E.g. Common interface used to communicate device driver and architecture • Middleware control of applications • Applications register the set of possible adaptive modes they support • Middleware then makes decision choosing mode(s) • Decision based on monitoring resources of system and trying various combinations of modes to achieve desired goal • Or require applications to provide estimates of the consequences of each mode on resources • System-wide adaptation • Distributed adaptation

10. Current architectural framework • Separation of policy and mechanism • Note this is not present in figure 4 • Makes coordination difficult

11. Proposed architectural framework

12. Proposed architectural framework (cont’d) • Separation of policy and mechanism • Adaptation control • Driven by policies • Coordinates responses • Gets system info from context space • Context space • Repository for retrieving pertinent info from device monitors, applications, and middleware • Gets info from device monitor, application, middleware • Device monitor • Daemon processes that monitor state of devices and software components

13. References • Efstratiou C., Cheverst K., Davies N., Friday A., "Architectural Requirements for the Effective Support of Adaptive Mobile Applications", Middleware 2000, New York, April 2000 • Cheverst, K., Christos Efstratiou, Nigel Davies, and Adrian Friday. "Architectural Ideas for the Support of Adaptive Context-Aware Applications" Proceedings of Workshop on Infrastructure for Smart Devices - How to Make Ubiquity an Actuality, HUC'00, Bristol, September 2000