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