An Architecture to Support Context-Aware Applications
-
Upload
henry-mcgowan -
Category
Documents
-
view
27 -
download
0
description
Transcript of An Architecture to Support Context-Aware Applications
An Architecture to Support Context-Aware Applications
Anind K.DeyDaniel Salber
Gregory D. AbowdMay 1999.
Introduction What is Context?
Information Application’s operating environment Sensed by the application Actions based on current state
Context Aware Applications Use context to provide task-relevant information and/or
services. eg.tour guide, conference assistant, context-aware mailing
lists, Dynamic Ubiquitous Mobile Meeting Board (DUMMBO).
Problems with using context
Lack of standard architecture Ad-hoc design, very little reusability Acquired from non-standard sources Abstraction to provide meaning to
application Dynamic
Context Handling Direct Hardwiring of Context
Code to handle sensor details embedded in application
Bulky applications Loss of generality, difficult to reuse or use by
multiple applications
Using Servers Polls sensor network Maintains current location information Abstracts details of sensors from application Multiple applications Applications must be proactive Each server offers a different interface
Widget Software component
Provides access to context information Hide complexity of actual sensor network used Abstract context information according to need Provide reusable and customizable building blocks
State Set of attributes that can be queried by an application
eg. Location, identity
Behavior Responds to changes in environment Provides callbacks to applications registered with it
Differences from GUI widgets
Distributed Architecture 3 components viz.
Generators – acquire context information Interpreters – abstract information Servers – Aggregate information
Active all the time Activation not driven by other applications
Distribution of context sensing network
Remote context sensing devices Eg. Indoor infrared positioning system
Multiple applications use same context information
Heterogeneous platforms for collecting context
Interoperability of context widgets and applications.
Context Abstraction
Need for interpretation to make context usable Transparency of low-level layers needed
Extension of existing mechanisms
Aggregation – Applications need to connect to only one component for each entity
Aggregation Improved maintainability and efficiency
Persistence and History
Independent execution of context widgets
Persistence required at all times
Maintenance of history necessary Storage of history on applications not possible always
Architecture Requirements Requirements summary
Allow applications to access context information from distributed machines in the same was that input information is accessed
Support execution on different platforms and the use of different programming languages
Support for the interpretation of context information
Support for the aggregation of context information
Support for independence and persistence of context widgets
Support for storage of context history
Architecture
Application
ServerInterpreter Interpreter
Widget Widget
Sensor Sensor ContextArchitecture
Context Widgets Attributes
Interface provided to other components Accessed via polling and subscribing
Callbacks Events used to notify subscribing components
Methods sendToSubscribers() – notifies concerned subscribers about
change in context state store() – stores historical data for future reference
(mechanism can be modified)
Context Server Single point of access/subscription to all widgets of
interest – proxy behavior Further separation, simpler design
In/Out Board
Building Aggregatio
ns
LocationWidget
LocationWidget
ID to Name
InterpreterFace
Recognition
Smart Card
Reader
Context Interpreter Convert or interpret context to higher level of
information and representation Context not available for appropriate level
In/Out Board
Location Widget
Location WidgetID to name
interpreter
Face Recognitio
n
Smart Card Reader
Callback Model
Transparent communications, always available
SensorLocationWidget
BaseObject
BaseObject
Application Handle
a.Subscribe Gregoryin Room 343
b.Sensor Dataarrives
c.Callback if dataMatches
Gregory in 343:
d.Callback deliveredto a handler
Conference Assistant
Application
Recommender/InterpreterUser
ServerPresentation
Server
QuestionWidget
ContentWidget
LocationWidget
MemoWidget
RegistrationWidget
Applications
In/Out Board
Serendipitous Meetings/Whiteboard
Aware home
Conference Assistant
Conclusions Context …
Enables context-aware applications to build smart environments
Treats context like user input Makes it easer for applications to deal with context Provides reusable solutions(widgets) for context
handling Achieves separation of concerns between context-
sensing and application semantics