Embed Size (px)
Citation preview
A Study of Context-Awareness: Gaia & SOCAM
2008.07.24
Presented by Dongjoo Lee
IDS Lab., Seoul National University
Gaia: A Middleware Infrastructure to En-able Active Spaces
Manuel Roman, Christopher Hess, Renato Cerqueira, Anand Ranganathan, Roy H. Campbell, Klara Nahrst-
edtDepartment of Computer Science, University of Illi-
nois at Urbana-Champaign, USA
A Service-oriented Middleware for Building Context-aware Services
Tao Gua,b, Hung Keng Punga, Da Qing Zhangb
aNetwork Systems and Services Laboratory, Depart-ment of Computer Science, National University of
Singapore, SingaporebContext-Aware System Department, Institute for In-
forcomm Research, Singapore
Copyright 2008 by CEBT 2
Contents
Gaia
Introduction
Architecture
Services
Application Framework
SOCAM
Introduction
Context Modeling and Reasoning
Architecture
Components
Performance Evaluation
Comparison
Discussion
Copyright 2008 by CEBT 3
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 phys-ical space
encapsulates the heterogeneity of active spaces, and presents them as a programmable environment, instead of a collection of in-dividual and disconnected heterogeneous devices
Similar to traditional OS
Copyright 2008 by CEBT 4
Physical and Active Space
Copyright 2008 by CEBT 5
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 6
Services
Event service
distributes events in the active space and implements a decoupled communication model based on suppliers, consumers, and channels.
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
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 7
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 in-cluding instantiation, mobility, reliability, and composition (number of compo-nents and their bindings)
Copyright 2008 by CEBT 8
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 9
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 vari-ous 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 discov-ery, context interpretation and context dissemination
Copyright 2008 by CEBT 10
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
Indirect Context -> deduced
– derived by interpreting direct context through context reasoning
– (Person,Location,Bathroom)˄(WaterHeater,Status,On)˄(Door,Status,Closed)=> (Person,Status,Showering)
different reliability
Copyright 2008 by CEBT 11
Common Upper Ontology
defines basic concepts
person, place, physical or computational object
14 classes, 6 properties
Copyright 2008 by CEBT 12
Domain Specific Ontology
defines the details of general concepts and their proper-ties
Example: IndoorSpace
Copyright 2008 by CEBT 13
SOCAM Architecture
Context providers, Context interpreter, Context data-base, Context-aware services, and Service locating ser-vice
Copyright 2008 by CEBT 14
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 15
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 ac-cording 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 16
Service Components (cont’d)
Service locating service
provides a mechanism where context providers and the context in-terpreter can advertise their presence and enables users or appli-cations 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 17
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
Logic reasoning is a bottleneck
It is acceptable for running non-time-critical context-aware applications
Overhead of the two-layer ontology design
The reasoning performance Reasoning comparisonAverage time for concurrent requests
Copyright 2008 by CEBT 18
Comparison
Gaia SOCAM
Architecture • Middleware infrastructure (OS) • Service oriented middleware
Target • Active space • Semantic space
Context Model• 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 Het-erogeneity
• App. description file (AGD, ACD) • Java
Communication among Compo-
nents
• CORBA • JAVA RMI
Service Trigger-ing
• Depends on implementation of App. • Pre-defined rule
Security • Future work • partially with Java RMI
Performance Evaluation
• n/a • need to be improved• acceptable for running non-time-criti-cal context-aware applications
Copyright 2008 by CEBT 19
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
