Architectural Requirements for the Effective Support of Adaptive Mobile Applications
Lawrence LiICS 243F
Topics
Introduction Drawbacks of Current Approaches Current Architectural Model Architectural Requirements Proposed Architectural Framework
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
Introduction (cont’d)
Authors’ criticism of current methods (Too) Numerous methods of
notifying applications of changes Need control messages from
system to applications
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
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
Current Architectural Model
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
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
Current architectural framework Separation of
policy and mechanism Note this is
not present in figure 4
Makes coordination difficult
Proposed architectural framework
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
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