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