Transcript A Comparison of Context-Aware Application Development

A Comparison of ContextAware Application
Development Infrastructures
and Context
Representation
Dev Oliver, Nikhil Yadav
CISE Department, University of Florida,
Gainesville, Florida, USA
Outline
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
•
Middleware Architectures
– GAIA Meta-operating System
– Service-oriented Context Aware Middleware
(SOCAM)
– Context-Aware Middleware Utilizing
Asynchronous Communication
– Middleware based on Application Packages and
the Kernel Runner
Comparisons
• Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
Middleware Architectures
– GAIA Meta-operating System
– Service-oriented Context Aware Middleware
(SOCAM)
– Context-Aware Middleware Utilizing
Asynchronous Communication
– Middleware based on Application Packages and
the Kernel Runner
•
Comparisons
•
Conclusions
Introduction
• Numerous middleware infrastructures and
prototype systems for developing contextaware applications
• Need for Middleware and Standards for
decoupling programming and application
development from physical space
construction and integration
• TCP/IP, client-server models, distributed
OS for networked computers. Similar
concepts needed for Pervasive computing
environments
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
Middleware Architectures
– GAIA Meta-operating System
– Service-oriented Context Aware Middleware
(SOCAM)
– Context-Aware Middleware Utilizing
Asynchronous Communication
– Middleware based on Application Packages and
the Kernel Runner
•
Comparisons
•
Conclusions
Problems and Proposed solutions
• Problem: Non-scalable integration
Low level information on sensors and actuators required.
Time consuming to integrate and test for conflicts.
Solution: Self Integration
Allow automatic integration within the space; preferable to
view elements as software services and space as runtime
environment
• Problem: Closed world Assumption
New technologies from 3rd Party vendors cannot be added
that easily as technology evolves over time.
Solution: Standard Adoption
Adoption of standards like OSGi and UPnP by maximum
number of vendors, so addition of third party elements
becomes easy
• Problem: Obsolete Concepts
Concepts become obsolete over time…e.g. context
awareness and service gateways
Solution: Semantic Exploitation and Intelligent
Middleware design
Allow added services to advertise their presence and
register services. Service definition + integration are added
in. Middleware for appliances e.g. smart plugs. Combining
these, functionality can develop over time.
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
• Middleware Goals
•
Middleware Architectures
– GAIA Meta-operating System
– Service-oriented Context Aware Middleware
(SOCAM)
– Context-Aware Middleware Utilizing
Asynchronous Communication
– Middleware based on Application Packages and
the Kernel Runner
•
Comparisons
•
Conclusions
Middleware Goals
• Presenting sensors and actuators as
software services in a runtime
environment (Smart space)
• Faster prototyping using service views and
dynamic libraries
• Browsing and learning support…to help in
full Semantic Exploitation (aggregating
context for instance)
(Middleware Infrastructures follow next)
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
• Middleware Architectures
–
GAIA Meta-operating System
–
Service-oriented Context Aware Middleware
(SOCAM)
Context-Aware Middleware Utilizing
Asynchronous Communication
Middleware based on Application Packages and
the Kernel Runner
–
–
•
Comparisons
•
Conclusions
The GAIA Meta-operating System
• Features Include:
– Distributed OS/ components
– Decoupled communication model
– Context Registry and Query services
– Component presence detection
– Browsing facilities
– Virtual Directory Hierarchy for files
– Application Partitioning among Devices
The GAIA Architecture
Distributed OS/ Components
• GAIA is based on distributed
components (sensors and actuators)
and applications
• CMC responsible for managing these
i.e. loading, unloading, transferring
and creating all GAIA components
Decoupled Communication
Model
• Event Manager provides this. Based
on suppliers, consumers and
channels
• Forwarding of supplier’s events to
consumers registered with the
channel
• Fault tolerant: Supplier replaced with
replica in case of failure
Context Registry and Querying
services
• Applications allowed to register and
query a particular context service
• Allows application adaption
• Context registry can be looked up by
applications to find out what service
they require
Component Presence Detection
• Presence Service responsible for this.
• Maintains updated information about active space
components i.e. devices, applications and services
• Digital Entity Presence subsystem: applications
and services send heartbeats…no heartbeat
received => Entity has left the active space
• Physical Entity presence subsystem acts as a
proxy implementing a beaconing mechanism.
Open Infrastructure, can employ different device
drivers and algorithms
Browsing Facilities
• The space repository stores all HW
and SW entity information e.g. by
name, type, owner
• Applications allowed to browse and
retrieve an entity based on specific
attributes
• Applications can learn about entities
entering and leaving the active space
thru the presence service channels
Virtual Directory Hierarchy for
Files
• Context File system responsible for this.
• Users given access to context whenever they need it
• Makes personal data available to applications; organizes
data to facilitate locating relevant material for applications
and users; retrieve data based on user preferences or
device characteristics
• CFS Aware of different types of context defined and allows
mounting of different contexts into one main application
space
• Virtual Directory Hierarchy:
e.g. /location:/RM2401/situation:/meeting
Architecture composed of mount and File servers
Application Partitioning among
devices
• Application framework responsible
for this
• Allows users to adapt how to
input/output data to and from the
application.
• lets users construct, run or adapt
existing applications to active spaces.
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
• Middleware Architectures
–
GAIA Meta-operating System
–
Service-oriented Context Aware Middleware
(SOCAM)
–
Context-Aware Middleware Utilizing
Asynchronous Communication
Middleware based on Application Packages and
the Kernel Runner
–
•
Comparisons
Service Oriented ContextAware Middleware (SOCAM)
• Features Include:
– OSGi based; uses JVM => platform
independence
– Context Registry and Query services
– Service Location (component detection)
– Ontology based Context reasoning
– Support for multiple home networking
technologies
– Hosting of Multiple services from different
providers on a single gateway platform
– Various levels of system security, digital
signing of downloaded services and object
access control.
SOCAM Architecture
OSGi based
• SOCAM is proposed on top of service
oriented OSGi open standard.
• OSGi defines a lightweight framework for
delivering and executing service-oriented
applications. Management functionalities
include: installing, activating, deactivating,
updating and removing services.
• Can provide a robust and potentially
interoperable infrastructure for building,
provisioning and managing context-aware
services in smart homes and beyond.
Context Registry and Query
services
• SLS, allows advertisement of services by CP and CI for easy
location
• Context Providers registers with SLS to be discovered by
others. They can be either external or internal based on
where context is obtained from
• Context Interpreters are composed of a context reasoner
and a context knowledge base.
– Reasoner uses preloaded inference rules etc. to make decisions.
– Context Knowledge base uses Tbox, Abox, predefined
instances loaded during system initiation and sensed context
instances loaded during runtime. Event triggering mechanism
used to update particular context instances.
• Context-aware services: Applications
using different levels of context
information, adapting their behavior
according to the current context.
• Queries SLS to find context it requires. A
common way of developing context-aware
applications is to specify actions in
response to context changes. Application
developers can specify rules and specify
method to invoke when the condition
becomes true.
Service Location (component
detection)
• SLS...wide area discovery of context providers is allowed for.
Tracks and adapts to changes induced when
adding/removing sensors or reconfiguring contexts.
• Multi. matching mechanism allowing advertisement of
context in various forms. (locatedIn John ?x) is a query
example.
• The service will first load the context ontologies stored in
the database and the context instances advertised by
different context providers, and then apply semantic
matching to find out which context provider provides this
information. If a match is found, it sends the application the
reference to the CP.
Ontology based Context
reasoning
• Supports ontology and rule based
reasoning. The OWL reasoning system
supports constructs for describing
properties and classes, including
relationships between classes. RDF
schema rules required to perform RDF
schema reasoning- for example. User
defined rule-based reasoning. Forward +
backward chaining + hybrid execution
mode to perform reasoning is used.
Support for multiple home
networking technologies
• OSGi compliant residential gateway,
enabling and managing
communications to and from various
local networks.
• Java embedded server connects both
wide-area and local networks.
Hosting of Multiple services
from different providers on a
single gateway platform
• Various types of networked devices,
electronic appliances and sensors can
be attached to the residential
gateway via different home
networking technologies. Hosts’
context aware services are
downloaded from various contextaware service providers.
Various levels of system security,
digital signing of downloaded services
and object access control.
• The gateway operator manages and
maintains residential gateways and their
services.
• Its functionalities include monitoring the
gateway to detect malfunctions and
security attacks and installing services to
and from gateway. Service aggregator and
protection against conflicts.
• Developers design a context aware
application as a set of services and combine
them into bundles that can be downloaded
to the gateway
• SW stack embedded in the OSGi compliant
residential gateway.
• Contains Service-hosting environ + common APIs
to develop application bundles. SOCAM
Middleware built on top of this.
• Each SOCAM component can be constructed as an
independent bundle i.e. SLS bundle. OSGi adopts
Java 2 security model
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
Middleware Architectures
–
–
GAIA Meta-operating System
Service-oriented Context Aware Middleware
(SOCAM)
–
Context-Aware Middleware Utilizing
Asynchronous Communication
–
Middleware based on Application Packages and
the Kernel Runner
•
Comparisons
•
Conclusions
Context-Aware Middleware
Utilizing Asynchronous
Communication
• Features include:
– OSGI based
– Uses asynchronous communication
– Proactive and reactive context introspection
– Tracking and selection of resources
– Introspection of the local system
– Introspection of the network neighborhood
Asynchronous Communication
• Messages stored temporarily on certain hosts
while being routed
– Forwarded later when circumstances permit
• Any message sent in the network should be
maintained as long as possible in a local cache
by as many devices as possible
– So it can remain available for those devices that could
not receive it at the time it was originally sent
• Implemented in Java as an OSGI service
Asynchronous Communication
• Messages are sent over the network either
as serialized Java objects or as formatted
XML
• Message dissemination is performed by
broadcasting UDP data grams
Proactive and reactive context
introspection
• Achieved by abstracting resources in
network via object oriented model
• Three abstractions made:
– Resources
– Resource descriptors
– Resource observation reports
Proactive and reactive context
introspection
• Resource object implements functionalities
to use and control the resource it defines
• Resource descriptor provides static
information about the resource
• Resource observation report gives
information about the current state of the
resource
Object-oriented modeling of
resources
Tracking and selection of resources
• Resources can appear and disappear frequently in the
environment
– necessary to have a means by which to keep track of currently
available resources
• Accomplished through resource objects and a resource
•
•
register
All resources are designed to register a description of
themselves with the register at creation time
Possible for an adaptive service deployed on a mobile
device to obtain information about its local execution
context by polling the register periodically
Tracking and selection of resources
• Occasionally necessary to focus only on specific
resources in the system at certain times
– E.g. when a given service is awaiting the appearance
of another service on the network
– Requires the middleware to select resources based on
pre-defined criteria
• Achieved by resource pattern
– Implements a function isMatchedBy() that takes a
resource descriptor object as a parameter and returns
a boolean indicating whether this object satisfies the
predefined criteria or not
Introspection of the local system
• Services should have information about
the local devices on which they are
running
• Achieved by obtaining a description of the
local resources from the resource register
and by monitoring the local resources
• Resources are monitored both
synchronously and asynchronously
Introspection of the local system
• Synchronous monitoring refers to the
implementation of a callback mechanism in
resource objects
– Each resource can admit several listeners
– When a variation occurs the resource can detect it
based on the registered listeners
• Unfortunately, all resources cannot be
monitored using this synchronous approach
– E.g. access to the CPU is not achieved by calling
methods directly
Introspection of the local system
• Asynchronous approach deals with CPU
resources such as system memory and
network interfaces
• Achieved by checking the state of a given
resource explicitly every now and then in
such a way that the time of the
observation does not coincide with the
time of an attempt in resource utilization
Introspection of the network
neighborhood
• Discover what resources are available in the
•
•
physical environment
More complicated mechanism by which to
automatically discover available resources
E.g. discovering close wireless networks,
configuring the wireless communication interface
of mobile devices automatically and identifying
what hosts can be reached on these networks
Introspection of the network
neighborhood
• In current implementation of this middleware,
•
•
this service relies on the system commands of
the Linux operating system (wireless tools)
Asynchronous communication is used to discover
neighboring hosts and remote services
Discovery of resources can be made:
– Proactively by sending requests in the network
– Reactively by analyzing unsolicited advertisements
sent by other devices in the network
Introspection of the network
neighborhood
• Discovery of remote services:
– Proactively
• Middleware sends XML document containing service request
described by a resource pattern
• Service providers who have matching services whose
descriptor fits the pattern that the request specifies respond
with an XML document containing a description of the
services they can offer
– Reactively
• Service providers send unsolicited advertisements or service
descriptors.
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
Middleware Architectures
–
–
GAIA Meta-operating System
Service-oriented Context Aware Middleware
(SOCAM)
Context-Aware Middleware Utilizing
Asynchronous Communication
–
–
Middleware based on Application Packages
and the Kernel Runner
•
Comparisons
•
Conclusions
A Middleware based on
Application Packages and the
Kernel Runner
• Features include:
– Kernel Runner
– Application Packages
– Several useful components for providing
common functionalities
Kernel Runner
• Handles the mobility and adaptation of
applications in the system
• Enables loading, execution, updating and
stopping of applications or components
• Platform-dependant
– Components executed in the kernel runner
are also platform-dependant
Kernel Runner Architecture
Kernel Runner
• Comprised of 3 elements:
– Interface
• Used to link with other kernel runners or preexisting applications in the network
– Applications cache
• Used to store the applications to be executed
– Execution engine
• Responsible for running previously cached
programs
Application Packages
• Analogous to OSGI bundles
• Facilitates distribution of the applications through
•
different nodes
XML file containing
– Configuration information
– Application executables
• Stores required files in a serialized format as part of the
•
XML file parameters
Benefit is that all running files needed can be sent in this
XML formatted file so that they can be extracted and run
in different kernel runners
Several useful components for
providing common functionalities
• Can be thought of as glue components that
•
allow the whole system to come together
Application repository
– Stores application information and classifies it based
on the platform it has been developed for
• Configuration repository
– Similar to the application repository in that it holds
configuration information in XML file format
Several useful components for
providing common functionalities
• Resource repository
– Holds information about music, videos, etc
– This information can be asked to be served online
from an external component
• Context sensor
– Used by the system to inform of the state of the
environment and any changes that occur
– Information such as location, temperature, alarm, etc
is notified to the subscribed components
Several useful components for
providing common functionalities
• Mobility and configuration manager
– Responsible for the different kernel runners on the
network
– Has the ability to move, stop or launch applications in
the kernel runner
• Context manager
– When any context sensor notifies a change, the
context manager uses its inference system to decide
what action it must perform
– Inference ranges from simple if then statements to
more deductive mechanisms based on probabilities or
on artificial intelligence techniques
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
Middleware Architectures
– GAIA Meta-operating System
– Service-oriented Context Aware Middleware
(SOCAM)
– Context-Aware Middleware Utilizing
Asynchronous Communication
– Middleware based on Application Packages and
the Kernel Runner
• Comparisons
•
Conclusions
Middleware Infrastructures
Comparison
Middleware Infrastructures
Comparison
• One disadvantage of the application package approach is
that it is not machine independent
– It is anchored on a machine specific kernel runner responsible
for supporting mobility and adaptation of applications in the
system
• One advantage that the application package approach
•
has over the OSGI based frameworks is that the OSGI
mechanism does not ensure the correct running of
difference bundles while this approach does
If dependencies between bundles fail, the OSGI bundles
cannot run but application packages will run
Middleware Infrastructures
Comparison
• Bundles in the OSGI framework must be
launched in a specific order if there are
dependencies
– Application package can always be started and will
begin to work correctly as soon as a service on which
it relies appears in the network
• GAIA and application packages approach are
distributed, OSGI approaches are generally not
– There can exists a limitation in a distributed
environment in the sense that not all devices are
capable of supporting the JVM
Middleware Infrastructures
Comparison
• OSGI approaches have advantage with platform
•
•
•
independence based on the fact that they are based on
Java
Less overhead for developers in developing bundles in
OSGI approaches
Many standard component interfaces for common
functions like HTTP servers, configuration, logging,
security, user administration, XML are available and welltested in OSGI approaches
OSGI approaches provide the standardized primitives
that allow applications to be constructed from small,
reusable and collaborative components
Middleware Infrastructures
Comparison
• GAIA is machine specific unlike OSGI approaches
• GAIA uses a config file to load devices at boot time, so
•
•
•
devices cannot be discovered automatically
OSGI based approaches present richer ways of
reasoning context, GAIA is more limited
GAIA is based on distributed OS principles, OSGI
components usually reside on a single platform
Context information is represented as directories in GAIA,
while it is represented as software bundles in OSGI
based approaches
•
Introduction
•
Problems and proposed solutions in Pervasive
Computing Infrastructures
•
Middleware Goals
•
•
Middleware Architectures
– GAIA Meta-operating System
– Service-oriented Context Aware Middleware
(SOCAM)
– Context-Aware Middleware Utilizing
Asynchronous Communication
– Middleware based on Application Packages and
the Kernel Runner
Comparisons
• Conclusions
Conclusions
• We presented four context aware middleware
•
•
applications that assist in the development of pervasive
applications and services
We found that the best middleware is dependent on the
application it is being used for
OSGI-based middleware boasts less overhead for
developers in implementing bundles and platform
independence based on the fact that OSGI is based on
Java
– Good option for pervasive spaces where all actuators and
sensors can be connected to a single platform running the OSGI
framework
Conclusions
• The two OSGI based frameworks that we analyzed were
not distributed and this turned out to be a limiting factor
• GAIA and the middleware based on application packages
and the kernel runner turned out to be better in terms of
portability and their ability to exist in distributed
environments
– Good options if sensors and actuators existing in different
networks need to communicate with each other
– The drawback here is the development overhead that has to
take place to get systems like these off the ground
References:
• 1. Sumi Helal: Standards and Emerging Technologies – Programming
Pervasive Spaces, IEEE Pervasive Computing Magazine, 2005
• 2. Gu, T. Pung, H.K. Zhang, D.Q: Towards an OSGi-based infrastructure for
context-aware applications, Pervasive Computing IEEE Volume 2, Issue 3,
July-Sept. 2003 Page(s):72 - 79.
• 3. Roman, M. Hess, C. Cerqueira, R. Ranganathan, A. Campbell, R.H.;
Nahrstedt, K.: A Middleware Infrastructure for Active Spaces, Pervasive
Computing, IEEE Volume 1, Issue 4, Oct.-Dec. 2002 Page(s):74 – 83
• 4. Nicolas Le Sommer, Frédéric Guidec, Hervé Roussain. A context-aware
middleware platform for autonomous application services in dynamic
wireless networks. ACM International Conference Proceeding Series; Vol.
138. Proceedings of the first international conference on Integrated internet
ad hoc and sensor networks (InterSense). 2006.
• 5. Aitor Uribarren, Jorge Parra, J. P. Uribe, Maider Zamalloa, Kepa Makibar.
Middleware for distributed services and mobile applications. ACM
International Conference Proceeding Series; Vol. 138. Proceedings of the
first international conference on Integrated internet ad hoc and sensor
networks (InterSense). 2006.