A Comparison of ContextAware Application Development Infrastructures and Context Representation

1
A Comparison of Context-Aware Application
Development Infrastructures and Context
Representation

• Dev Oliver, Nikhil Yadav
• CISE Department, University of Florida,
  Gainesville, Florida, USA

2
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
• Conclusions

3

• 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

4
Introduction

• Numerous middleware infrastructures and prototype
  systems for developing context-aware 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

5

• 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

6
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

7

• Problem Obsolete Concepts
• Concepts become obsolete over timee.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.

8

• 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

9
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 supportto help in full
  Semantic Exploitation (aggregating context for
  instance)
• (Middleware Infrastructures follow next)

10

• 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

11
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

12
The GAIA Architecture
13
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

14
Decoupled Communication Model

• Event Manager provides this. Based on suppliers,
  consumers and channels
• Forwarding of suppliers events to consumers
  registered with the channel
• Fault tolerant Supplier replaced with replica in
  case of failure

15
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

16
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 heartbeatsno 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

17
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

18
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

19
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.

20

• 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

21
Service Oriented Context-Aware 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.

22
SOCAM Architecture
23
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.

24
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.

25

• 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.

26
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.

27
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.

28
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.

29
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 context-aware service
  providers.

30
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

31

• 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

32

• 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

33
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

34
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

35
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

36
Proactive and reactive context introspection

• Achieved by abstracting resources in network via
  object oriented model
• Three abstractions made
• Resources
• Resource descriptors
• Resource observation reports

37
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

38
Object-oriented modeling of resources
39
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

40
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

41
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

42
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

43
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

44
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

45
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

46
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.

47

• 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

48
A Middleware based on Application Packages and
the Kernel Runner

• Features include
• Kernel Runner
• Application Packages
• Several useful components for providing common
  functionalities

49
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

50
Kernel Runner Architecture
51
Kernel Runner

• Comprised of 3 elements
• Interface
• Used to link with other kernel runners or
  pre-existing applications in the network
• Applications cache
• Used to store the applications to be executed
• Execution engine
• Responsible for running previously cached
  programs

52
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

53
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

54
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

55
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

56

• 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

57
Middleware Infrastructures Comparison
58
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

59
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

60
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 well-tested in OSGI approaches
• OSGI approaches provide the standardized
  primitives that allow applications to be
  constructed from small, reusable and
  collaborative components

61
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

62

• 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

63
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

64
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

65
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.