Context-awareness and Heterogeneity in Pervasive Computing Environments
Kashif Imran
Ravi Tiwari
Overview
Pervasive computing Requirements for ubiquitous and adaptive
collaboration Middleware to provide heterogeneity and
context-awareness in pervasive computing environments Model for adaptive collaborative mechanisms
in heterogeneous environments A generic framework for context-awareness Middleware providing network heterogeneity
Pervasive Computing
Computing appliances seemly integrated into our lives, providing any time anywhere information.
Vision of digital life style Early work at Palo Alto Research Center Intelligent doorknobs to toilet-paper holders
Pervasive Computing Environments
Handheld Devices
Pervasive computing devices communicate and take actions.
Laptops
Atlas nodes
Network camera
Requirements for ubiquitous and adaptive collaboration Dynamic application adaptation to contextual
changes, such as changes in users’ interest, location, communication bandwidth etc
Platform-independent application descriptions to support multiple platform deployment
Heterogeneous service and device discovery Support of heterogeneous data formats e.g.
by not sending a high quality video stream to a low resolution screen
Role of Middleware
To analyze the role of middleware in context-aware application development for heterogeneous pervasive environments.
Application adaptation to multiple platforms Networked, heterogeneous devices Interoperability among heterogeneous networks
Middleware for heterogeneous context-aware applications
Kernel Runner, KR Application Package, AP Application Repository, AR Configuration Repository, CR Resource Repository, RR Context sensor, CS Mobility and Configuration Manager, MCM Context Manager, CM
Kernel Runner
Responsible for mobility and adaptation of apps Enables loading, execution, updating and stopping of
the applications or components Composed of three elements
The Interface Application Cache
ExistApp, UploadApp Execution Engine
StartExecution, StopExecution, CheckRunning and OnlineReloadParameters
Application Package
Facilitates the distribution of the applications through the different nodes
The AP is an XML file with two kinds of information Configuration parameters Application executables
Separates the application files from the execution parameters achieving platform independent description of application
Able to send all the running files needed in an XML formatted file, to extract and launch them in the different KRs
Application Package
Other Components
Application repository, AR An application repository on the network Stores each application developed as XML file SearchApp, DownloadApp, UploadAdd There can be many AR in a network
Configuration repository, CR Similar to the AR, the CR holds information in XML file
format related with the application configurations Resource repository, RR
Holds information in XML file format on music, photos, videos, etc. and information can be served online to an external component.
Other Components
Context sensor, CS components that inform of the state of the environment
and any changes to the same Mobility and configuration manager, MCM
responsible for the discovery and control of the different KRs on the network
has the ability to move, launch, or stop the applications in the different KRs
moves the correct version of application from the AR to the KR along with required configuration file with the
application’s last execution parameters from the CR Context Manager, CM
On context change the CM uses its inference system to decide what action it must perform.
Comparison with OSGi
Intermediary between different bundles Bundles provide service to other bundles OSGi limitation: Interoperability is ensured in
the same machine between different bundles. It does not ensure correct running of different bundles in an open, distributed system using different devices such as PC, PDA, smartphones etc.
AP can be launched without partner AP.
WILDCAT
Generic framework to ease the development of context-aware applications
Provides dynamic model to represent application’s execution context
Facilitates the acquisition and aggregation of contextual data to create reusable objects to represent aspects of execution context relevant to many applications
Logical Data Model
Context class Facade of whole system from client’s view One instance per application Context is made of several domains
Sys: local hardware, net: topology, geo: geophysical info (location, temperature..), user: preference (activity, mood..)
ContextDomain Object representing each domain of context Tree of named resources each being described by
attributes (simple key/value pair) Separates different aspects of execution context and
allow custom implementation
Logical Data Model
Logical Data Model
Events Each change occurring in the context model is
represented by an event RESOURCE_ADDED RESOURCE_REMOVED ATTRIBUTE_ADDED ATTRIBUTE_REMOVED ATTRIBUTE_CHANGED EXPRESSION_CHANGED CONDITION_OCCURED
Logical Data Model
Addressing URI inspired syntax to denote elements A resource
sys://storage/memory An attribute
sys://storage/disks/hda#removable Input devices
Sys://devices/input/* Mouse attributes
sys://devices/input/mouse#*
External Interfaces
Context class offers two interfaces Synchronous requests (pull mode) Asynchronous notification (push mode)
Synchronous requests (pull mode)
public class Context {String[] getDomains();Path[] getChildren(Path res);Path[] getAttributes(Path res);boolean exists(Path path);Object resolve(Path attr);
}
//Returns the list of all disk drives currently knowncontext.getChildren(new Path("sys://storage/disks"));
//Returns the amount of memory currently availablecontext.resolve(new Path("sys://storage/memory#free"));
Asynchronous notification (push mode)public class Context {long register(ContextListener listener,int eventKinds, Path pp);long registerExpression(ContextListener listener,int eventKinds, String expr);void unregister(long regId);}
//Get notified each time a new input device is plugged or unpluggedcontext.register(myListener,RESOURCE_ADDED | RESOURCE_REMOVED,new Path("sys://devices/input/*"));
//Get notified when the room temperature goes beyond 30 Ccontext.registerExpression(aListener, CONDITION_OCCURED,"geo://location/room#temperature > 30");
Internal Design
The ContextDomain interface
public interface ContextDomain {void initialize(Context ctx);String getName();boolean exists(Path path);Object resolve(Path attr);Path[] getAttributes(Path res);Path[] getChildren(Path res);void register(ContextListener listener,int eventKinds, Path path);void unregister(ContextListener listener,int eventKinds, Path path);void update(Path path, Path cause);}
Sensor Management
SensorManager class organizes all the sensors
Active sensors implement directly the Sensor interface and run in their
own threadpublic interface Sensor {
String getName();void setListener(SamplesListener listener);void start();void stop();boolean isStarted();}
Sensor Management
Passive sensors created by associating a Sampler and a Schedule to
create a SamplingSensor
public interface Sampler { SampleSet sample();
}
XMLCommandSensor class Make it easier to integrate WildCAT with existing
systems
Example Application
Network Heterogeneity in Pervasive App Environments Involvement of heterogeneous networks in
pervasive computing environments Infrastructure network, Ad-hoc network,
Sensor network
Example Scenarios
Forest Firefighting Group communication service Publish-subscribed service
Example Scenarios
Environmental informatics Data retrieval service Event service
Limitations of current middleware solutions Network-style centric Support individual network dependent
services (RPC, publish-subscribe etc) Static middleware services
Gridkit Middleware
Addresses two key requirements within the pervasive application domain Service deployment
Suitable middleware service for developers Dynamic reconfiguration
Adapt to changing network heterogeneity
Gridkit Architecture
Extensive services on top of overlay networks Overlay of overlays
Gridkit Architecture
Structure of Overlay Plug-in
Deployment and Reconfiguration of Middleware Services Policy-based deployment of middleware
services Appropriate stack of software on each node Roles of a node: Participant or Facilitator
Leveraging Facilitators
Deployment configurator Work for the nodes in the same overlay
Gridkit Deployment Service
Bridging Overlays
Conclusion
Middleware can ease the development of context-aware applications and provide transparency in heterogeneous pervasive computing environments
Qustions…
???