A Study of Context-Awareness:
Gaia & SOCAM
2008.07.24
Presented by Dongjoo Lee
IDS Lab., Seoul National University
Gaia: A Middleware Infrastructure to Enable
Active Spaces
Manuel Roman, Christopher Hess, Renato Cerqueira, Anand
Ranganathan, Roy H. Campbell, Klara Nahrstedt
Department of Computer Science, University of Illinois at
Urbana-Champaign, USA
A Service-oriented Middleware for Building
Context-aware Services
Tao Gua,b, Hung Keng Punga, Da Qing Zhangb
Systems and Services Laboratory, Department of
Computer Science, National University of Singapore,
Singapore
bContext-Aware System Department, Institute for Inforcomm
Research, Singapore
aNetwork
Contents


Gaia

Introduction

Architecture

Services

Application Framework
SOCAM

Introduction

Context Modeling and Reasoning

Architecture

Components

Performance Evaluation

Comparison

Discussion
Copyright  2008 by CEBT
2
Gaia: Introduction

Active Space

an extension to physical space
–


Homes, offices, and meeting rooms capable of sensing user actions and
equipped with a large variety of devices will assist users with different tasks.
require a middleware infrastructure that supports the development and
execution of user-centric mobile applications
Gaia

a distributed middleware infrastructure that coordinates software
entities and heterogeneous networked devices contained in a physical
space

encapsulates the heterogeneity of active spaces, and presents them as
a programmable environment, instead of a collection of individual and
disconnected heterogeneous devices

Similar to traditional OS
Copyright  2008 by CEBT
3
Physical and Active Space
Copyright  2008 by CEBT
4
Gaia Architecture

Component Management Core


dynamically loads, unloads, transfers, creates, and destroys all the
components and applications of Gaia
Gaia components are distributed objects so that require
communication middleware to support remote interaction

uses CORBA to communicate with each other
Copyright  2008 by CEBT
5
Services

Event service




Context service

allows applications to query and register for particular context information so that they may
adapt to their environment.

consists of context providers that provide information about the current context.
Presence service

detects digital and physical entities present in an active space.

four basic types of entities: application, service, device, and person.
Space repository


distributes events in the active space and implements a decoupled communication model
based on suppliers, consumers, and channels.
stores information about all software and hardware entities contained in the space (e.g.,
name, type, and owner) and provides functionality to browse and retrieve entities based on
specific attributes.
Context file system

incorporates context into the traditional file system model to provide support for mobile users,
device heterogeneity, and data organization.

/type:/papers/current:

/location:/RM2401/situation:/meeting
Copyright  2008 by CEBT
6
Application Framework

Distributed component-based infrastructure



Model View Controller
–
model
–
presentation
–
controller
–
coordinator
Mapping mechanism

customizes applications to different active spaces

application description file
–
Application Generic Description (AGD)
–
Application Customized Description (ACD):
generated by specialization mechanism using AGD
Policies

customize different aspects of the applications

define different sets of rules to customize several aspects of applications including
instantiation, mobility, reliability, and composition (number of components and
their bindings)
Copyright  2008 by CEBT
7
Lua: Gaia’s Scripting Language


LuaOrb

high level scripting language based on the Lua

used to program and configure active spaces and to coordinate the active entities they
contain

simplifies management and configuration tasks

allows for rapid prototyping and testing
Example: instantiate and assemble an MP3 application
Copyright  2008 by CEBT
8
SOCAM: Introduction

Context

any information that can be used to characterize the situation of an entity
[Dey and Abowd, 2000]

A context-aware service is a network service which uses various
contexts and adapts itself to the change of environment dynamically and
automatically

Architectural Requirements

A common context model that can be shared by all devices and services

A set of services that perform context acquisition, context discovery, context
interpretation and context dissemination
Copyright  2008 by CEBT
9
Context Modeling and Reasoning



An ontology-based context modeling using OWL

formal context model represented as first-order predicate calculus

extendable to complex context or a set of contexts by combining the predicate
and Boolean algebra
Two-layer hierarchical approach

Common upper ontology

Domain-specific ontologies
Context classification and dependency


Direct Context
–
sensed context: acquired from physical sensors -> sensed
–
defined context: defined by a user -> defined
different reliability
Indirect Context -> deduced
–
derived by interpreting direct context through context reasoning
–
(Person,Location,Bathroom)˄(WaterHeater,Status,On)˄(Door,Status,Closed)
=> (Person,Status,Showering)
Copyright  2008 by CEBT
10
Common Upper Ontology

defines basic concepts


person, place, physical or computational object
14 classes, 6 properties
Copyright  2008 by CEBT
11
Domain Specific Ontology
 defines the details of general concepts and their properties
 Example: IndoorSpace
Copyright  2008 by CEBT
12
SOCAM Architecture
 Context providers, Context interpreter, Context database,
Context-aware services, and Service locating service
Copyright  2008 by CEBT
13
Service Components


Context providers

abstract useful contexts from heterogeneous sources—External or Internal.

convert them to OWL representations so that contexts can be shared and reused by
other service components.
Context interpreter

provides logic reasoning services to process context information.

Tasks
–
deriving high level contexts from low level contexts
–
give querying capability of context knowledge
–
maintaining the consistency of context knowledge
–
resolving context conflicts
–
provide deduced contexts

Context Reasoner, Knowledge Base

Reasoning
–
Ontology reasoning
–
User defined rule based reasoning: forward chaining, backward chaining, and hybrid execution
model
Copyright  2008 by CEBT
14
Service Components (cont’d)

Context database


stores context ontologies and past contexts for a sub-domain.
Context-aware services

agents, applications, and services

make use of different level of contexts and adapt the way they behave according to the
current context.

pre-defined rules that specify actions triggered by a set of rules whenever the current
context changes
Copyright  2008 by CEBT
15
Service Components (cont’d)


Service locating service

provides a mechanism where context providers and the context interpreter
can advertise their presence and enables users or applications to locate
these services.

Implementation [Gu et al. (2003)]: features
–
scalability
–
dynamism
–
multiple matching capability
Communication and interaction between components

Java RMI
–
interoperability between heterogeneous platforms
–
security
Copyright  2008 by CEBT
16
Performance Evaluation

Implementation

SOCAM Middleware: J2SE1.3.1

Context Interpreter: Jena2-HP’s Semantic Web Toolkit

Ontology: OWL


–
Home domain: 89 classes, 156 properties
–
Vehicle domain: 32 classes, 57 properties
Context provider: emulated in laptop
Performance Evaluation
The reasoning performance
Reasoning comparison
Average time for concurrent requests
Overhead of the two-layer
ontology design

Logic reasoning is a bottleneck

It is acceptable for running non-time-critical context-aware applications
Copyright  2008 by CEBT
17
Comparison
Gaia
SOCAM
• Middleware infrastructure (OS)
• Service oriented middleware
• Active space
• Semantic space
• No common context model
• Ontology based model (OWL)
• Deduced context
Context Storing
• Context File System
• Knowledge Base, Context database
App. Framework
• Partitioned App. based on MVC
• n/a
Supporting
Heterogeneity
• App. description file (AGD, ACD)
• Java
• CORBA
• JAVA RMI
• Depends on implementation of App.
• Pre-defined rule
• Future work
• partially with Java RMI
• n/a
• need to be improved
• acceptable for running non-time-critical
context-aware applications
Architecture
Target
Context Model
Communication
among Components
Service Triggering
Security
Performance
Evaluation
Copyright  2008 by CEBT
18
Discussion
 There are already many good architectures for enabling context
aware services. Therefore we have to refer them profoundly.
 SOCAM is much similar to our approach

Service locating service

Ontology based context model
–
reasoning
 Needs more consideration about

Personalization

Security & Privacy

Distributed control
–

cf) centralized control
Synchronization of context information among devices
Copyright  2008 by CEBT
19