The document discusses the design of a framework for handling context information. It first reviews existing context-aware platforms and their approaches to context modeling, reasoning, and other features. It then outlines some general design principles for the framework, including layered architecture, service management, interoperability, and support for context retrieval, quality of context, scalability and user-centered design. Finally, it examines potential technologies and functionalities for the framework, comparing options for messaging, context modeling, and system architecture.
[MADRINET'09] Designing a framework to handle context information
1. Grupo de Procesado de Datos y Simulación
ETSI de Telecomunicación
Universidad Politécnica de Madrid
Designing a framework to handle
context information
MADRINET’09
Ana Hristova, Josué Iglesias, Ana M. Bernardos, José R. Casar
{ana.hristova, josue, abernardos, jramon}@grpss.ssr.upm.es
2. presentation content
context-aware platforms review
general design principles
functionalities & technologies
architecture proposal
conclusions
future work
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 2 / 13 2
7. general design principles
layered approach decoupling:
sensing / acquisition infrastructure
processing mechanisms
service management application logic
interoperability to get:
reusability
extendibility
context retrieval
etc.
quality of context (QoC)
scalability
user-centered
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 7 / 13 7
8. general design principles
layered approach formal (semantic) service description
services discovery mechanisms
service management
to keep track of available resources
dynamic sources of context information
interoperability
context retrieval
quality of context (QoC)
scalability
user-centered
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 8 / 13 8
9. general design principles
layered approach
service management common
service interfaces
interoperability modelling languages
communication protocols
context retrieval motivate service integration
inside enterprises architecture
quality of context (QoC) on the Internet
scalability
user-centered
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 9 / 13 9
10. general design principles
layered approach
service management
interoperability
delivery of context data from acquisition
platform to upper layers
context retrieval
(processing and final applications)
quality of context (QoC)
two basic modes of context retrieval:
scalability
PUSH: enables automatic context delivery
(continuous, periodic, event-based, etc.)
user-centered
PULL: enables on demand context retrieval
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 10 / 13 10
11. general design principles
layered approach
service management
interoperability
context retrieval QoC
context-aware
applications
quality of context (QoC)
user experience
scalability context-information + QoC-information
user-centered
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 11 / 13 11
12. general design principles
layered approach
service management
interoperability
to maintain response times in terms of
number of users
context retrieval
operation load
quality of context (QoC) able to dynamically add:
new sensors
new algorithms (inference,
scalability
discovery, etc.)
new client applications
user-centered etc.
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 12 / 13 12
13. general design principles
layered approach
service management
interoperability
context retrieval
quality of context (QoC)
scalability user does not adapt to the system
system transparently adjust to the user
behaviour and preferences
user-centered privacy constraints
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 13 / 13 13
14. [functionalities] architecture
servlets
messaging
Java classes
dynamically process HTTP requests
context context construct XML responses
modeling reasoning
easy to implement
architecture universal client (just http, no matter
implementation)
architecture no service registry or discovery
technological platform
service-oriented approach
input parameters unknown
scalability
interoperability
number of users
response times
reusability
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 14 / 13 14
15. [functionalities] architecture
servlets
messaging web services
Java classes
dynamically process HTTP requests
machine – machine interaction over
context context construct XML responses
networks
modeling reasoning well-established standards: XML, SOAP,
easy to implement
WSDL and UDDI
architecture universal client (just http, no matter
implementation)from language and platform
independent
architecture
description language: WSDL
no service registry or discovery
dynamic service discovery: UDDI
technological platform
service-oriented approach
no automatic context data aggregation
scalability XML-HTTP are not most appropriate for
interoperability
number of users real-time applications
response times
reusability
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 15 / 13 15
16. [functionalities] architecture
servlets
messaging web services
Java classes
OSGi
dynamically process HTTP requests
machine – machine interaction over
context context construct XML responses
networks component framework for Java
dynamic
modeling reasoning well-established standards: unit SOAP,
XML,
bundle: reusable software
easy to implement
WSDL and UDDI
architecture universal client (just http, no matter
reusability of components
implementation)from language and platform
independent
(bundles/services)
description language: WSDL
architecture aggregation of context data
no service registry or discovery
dynamic service discovery: UDDI
technological platform
service-oriented approach
HW platform independence (Java-based)
no automatic context data aggregation
scalability
service discovery in framework
no automatic context data aggregation
interoperability
number of users
specific client for testingother non-Java
not interoperable with purposes
response times frameworks
reusability
no remote service discovery
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 16 / 13 16
17. [functionalities] messaging
socket
messaging end point of a communication link
IP-based networks
context context easy implementation
modeling reasoning low network traffic
no client or server language restrictions
architecture
no standardized message format
raw data packets client/server
messaging
context data access process
(on-demand, subscription, etc.)
PUSH paradigm
API technologies
scalability
interoperability
speed
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 17 / 13 17
18. [functionalities] messaging
socket
XML/HTTP
messaging end point of a communication link
IP-based networksquery
HTTP web server
XML web server response
context context easy implementation
modeling reasoning low network traffic
platform-independent
no client choice of XML tags restrictions
flexible or server language
architecture security already implemented (HTTPs)
no standardized message format
XML advantages (flexibility, validation, ...)
raw dataHTTP & XML management tools
several packets client/server
messaging
context data access process
(on-demand, subscription, etc.) HTTP not the fastest protocol
PUSH paradigm
API technologies XML itself lacks semantic
scalability no intrinsic data type support
interoperability
speed
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 18 / 13 18
19. [functionalities] messaging
socket
XML/HTTP
messaging end point of a communication link
SOAP
IP-based networksquery
HTTP web server
XML web server typed data exchange
structured and response
context context easy implementation
modeling reasoning operates in decentralized and distributed
low network traffic
platform-independent
environments
no client choice of XML tags restrictions
flexible or server language
architecture security already implemented (HTTPs)
platform & language independent
no standardized message format
XML advantages (flexibility, validation, ...)
based on XML
raw dataHTTP & XML management tools
several packets client/server (HTTP,
messaging transport protocol independent
context data access process
SMTP, etc.)
(on-demand, subscription, etc.) HTTP not the fastest protocol
PUSH paradigm
API technologies XMLmention of semantic
no itself lacks security mechanism
scalability no intrinsic data type support objects
no state reference to remote
interoperability
speed
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 19 / 13 19
20. [functionalities] context modeling
key-value
messaging
low complexity
easy to manage
context context high applicability to existing
modeling reasoning environments
architecture lack of formality
no algorithms to support efficient
access to information
context modeling no validation possible
context data integration from
multiple heterogeneous
difficult to add meta information to
sources context information (quality, etc.)
structured information
store & retrieved
compute
share
reuse
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 20 / 13 20
21. [functionalities] context modeling
key-value
messaging mark-up schemes
low complexity
easy to manage
can be partially validated
context context high applicability to existing
several management tools exist
modeling reasoning environments to existing infrastructures
applicability
based on mark-up languages (as web
architecture lack of formality
services)
no algorithms to support efficient
access to information ambiguity to be
incompleteness and
context modeling no validation possible
context data integration from handled on the application level
multiple heterogeneous
difficult to add meta information to
not fully scalable (hierarchical structure
sources context information (quality, etc.)
but not inherence)
structured information
store & retrieved
compute
share
reuse
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 21 / 13 21
22. [functionalities] context modeling
key-value
messaging mark-up schemes
low complexity
ontologies
easy to manage
can be partially validatedobjects, concepts and
context context addsapplicability to existing
high semantics when defining
several management tools exist
their properties and relations
modeling reasoning environments to existing infrastructures
applicability
combine object-oriented and logic-based models
advantages
based on mark-up languages (as web
architecture not of formality to model context data, but also
lack only applicable
services)sensors, etc.
services,
no algorithms to support efficient
access to information formal descriptions
incompleteness and ambiguity to be
structured, explicit and
context modeling high scalable possible
no validation
context data integration from handled on the application level
multiple heterogeneous
knowledge share meta information to
difficult to add & reuse
not fully scalable (hierarchical structure
partial validation
sources context information (quality, etc.)
but not inherence)
meta-information integration
structured information able to infer new information (logic)
store & retrieved
compute
share high design complexity
reuse high reasoning complexity
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 22 / 13 22
23. [functionalities] reasoning
rule-based reasoning
messaging
to reason about policies, restrictions,
preferences, alarms, etc.
context context
modeling reasoning scalable (easy to add/change rules)
simple and human-understandable
architecture complements other types of reasoning
no uncertainty support
context reasoning difficult automatic rules acquisition
context data relevant
information
pre-processing rules definition languages: SWRL,
sensor data fusion RuleML, etc.
inference
monitoring (decision making) rule engines: Jess, Pellet, FaCT, etc.
etc.
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 23 / 13 23
24. [functionalities] reasoning
rule-based reasoning
messaging bayesian networks
to define policies, restrictions,
preferences, alarms, etc.
combine probability & graph theory
context context different approaches: DBN,
scalable (easy to add/changeHMM, etc.
modeling reasoning rules)
simple and human-understandable
consistent mathematical
complements other types tool (probability)
architecture of reasoning
able to handle uncertainty and
incompleteness
no uncertainty support
context reasoning can be
difficult automatically created from
automatic rules acquisition
context data relevant observation
information
pre-processing rules definition languages: SWRL,
need to be
sensor data fusion RuleML, etc. trained
inference often not practical for large systems
rule engines: Jess, Pellet, FaCT, etc.
monitoring (decision making)
etc.
several tools: BNT(Matlab), MSBNx, etc.
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 24 / 13 24
25. architecture proposal
main objective
context acquisition –
context-aware applications
decoupling
(standardized APIs) web browser / Java application
context provider
encapsulates sensor data
acquisition processes HTTP XML
messaging servlets
sockets (raw data)
XML/HTTP
architecture
servlets
web browser or Java sockets [raw data]
applications key-value
model
context modelling
key-value
context reasoning
rule-based (applications)
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 25 / 13 25
26. architecture proposal
main objective sensors services
context acquisition – WiFi heartrate location services presence
context-aware applications Bluetooth Zigbee registry activity recognition
decoupling accelerometers etc. ambiental monitoring (ºC,light,...)
(standardized APIs)
context provider
encapsulates sensor data
acquisition processes
messaging
sockets (raw data)
XML/HTTP
architecture
servlets
web browser or Java
applications
context modelling
key-value
context reasoning
rule-based (applications)
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 26 / 13 26
27. conclusions and future work
conclusions
1. in spite of the various proposals presented to date, there is not an
agreed methodology to cope with context information and to easily
develop context-aware applications
2. the variety of sensors types, with different specifications and
interfaces, claim for the development of new or existing sensor
modelling standards
future work
1. improve proposed platform
architecture: service-oriented, based on OSGi
context modelling: ontologies
context reasoning: from application to context platform
probabilistic reasoning (bayesian networks)
2. Quality of Context management
3. Design of a lightweight context management platform for mobile devices
(mobile OSGi?)
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 27 / 13 27
28. any question?
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 28 / 13 28
29. context reasoning techniques
Approach Advantages/Disadvantages Tools
Rule-based + New rules can be added in a simple, incremental fashion, - Bossam: inference engine with native support for
reasoning without rewriting the whole system reasoning over OWL ontologies and SWRL/RuleML
+ Knowledge is represented in an explicit and intelligible rules [19]
way - Jess: small, light and fast rule engine for the Java
+ Easy to integrate with other reasoning methods (as platform where rules can be defined in XML [20]
ontologies) - Other tools: Pellet, FaCT, RacerPro, etc.
- Contextual information can’t be effectively managed
- Automatic rules acquisition is difficult
Bayesian + Are based on probability theory, a consistent mathematical - Bayes Net Toolbox: open source Matlab package
Networks tool for directed graphical models that supports
+ Can readily handle incomplete data sets probability distributions, inference and structure
+ Able to build complex systems from simpler ones learning [26].
+ The belief is automatically kept updating when new data - MSBNx (Microsoft Bayesian Network Editor): a
item arrives component-based application for creating, assessing,
+ Learning about causal relationships and evaluating Bayesian Networks [25].
- Bayesian networks need to be trained - WEKA: a collection of machine learning
- Highly dependent on prior knowledge reliability algorithms for data mining tasks [24].
- No universally accepted method for constructing a network - Other tools: BNJ, JavaBayes, BayesiaLab, BUGS,
from data etc [27].
- Often not practical for large systems
Fuzzy Logic + Mimic human decision-making to handle vague concepts - Matlab’s Fuzzy Logic Toolbox: extends the
+ Ability to deal with imprecise or imperfect information Matlab computing environment with tools for
+ Improved knowledge representation and uncertainty designing systems based on fuzzy logic [28].
reasoning - Other tools: FuzzyCOPE, fuzzyTECH, etc [29].
- Highly abstract and heuristic
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 29 / 13 29
30. messaging tecniques
Technology Description Advantages Disadvantages
XML/HTTP One of the simplest ways of - Platform-independent and standard – based - There exist fasters protocols than HTTP
messaging: Internet HTTP protocol is technologies - XML itself lacks semantic
used to query web servers, getting back - Flexible choice of XML tags and structure - No intrinsic data type support
server information in XML format - HTTP itself offers security mechanisms
- XML allows validation using DTD or XML-Schemas
- Many tools for HTTP and XML management already
developed for almost every platform
Java Message Java Message Service is a JAVA - Asynchronous sending and receiving data -Slower communication
Service messaging standard that allows -Supports point-to point and publish and subscribe -Increased network traffic due to sending header and other
applications to create, send, receive, and mechanism information together with the message content
read messages [12] - Provides different levels of message delivery reliability
- Provides standard message formats
- Loose coupling
- Can be used by non-JMS clients
Sockets A socket is an end point of a - Easy implementation -No standardized message format
communication link between two - Low network traffic -Send only packets of raw data, that should further on be
programs in an IP based network - Client and server can be written in different languages handled on the client and server-side
Pushlet Pushlet is a servlet-based JAVA -Continuous sending of new HTML content - The client has to be a web browser
mechanism that enables pushing content -Small protocol overhead; -Scalability: As the number of users increases, the number of
from server-side JAVA objects to a client -Uses standard HTTP ports and protocols resources that are hold increases (threads, sockets etc)
browser [11] -Light-weight client side (no need for browser plug-ins) -A web server is not designed for long-lived connections
-DHTML is not compatible across browsers
Remote Method Remote Method Invocation is a - Handles threads and sockets -Uses non standard ports that might be blocked by firewalls
Invocation distributed Java technology that enables - Its communication falls back to sockets and if restricted -Requires a dedicated server
executing computations remotely [13] by a firewall, falls back into HTTP communication -It can be only used by JAVA clients
-Supports distributed architectures for context acquisition -Vulnerable security
and reasoning, as it allows communicating different -Tightly coupled. Requires that the client has a pre-
virtual machines knowledge of the methods to be called
- It is supported in few browsers
SOAP SOAP provides mechanisms for - Simple and extensible - SOAP contains no mention of security facilities
(Simple Object Access exchanging structured and typed - Platform and language independent - SOAP clients do not hold any stateful reference to remote
Protocol) information between peers in a - Based on XML objects
decentralized, distributed environment -Transport protocol independent (HTTP, SMTP, etc.)
[14] - SOAP allows you to get around firewalls
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 30 / 13 30
31. examples
geo-referenced messaging
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 31 / 13 31
32. examples
contextual
agenda finder
Designing a framework to handle context information – MADRINET’09josue@grpss.ssr.upm.es
Prototyping of context-aware mobile services – CISTI 2008 josue@grpss.ssr.upm.es 32 / 13 32
Notas do Editor
Hello, good morning. I’m Josué Iglesias, I work for the GPDS group in the UPM, there in Madrid, and I’m going to talk about the designing of context aware platforms.
After going over (=reviewing) some of the most important context-aware frameworks, i want to focus this presentation FIRST on the main design principles, functionalities and technologies applying to context-aware platforms, and LATER on our own architecture proposal, FINISHING with some conclusions and future works.
We have selected 4 of the most important and well-known context-aware platforms and here I just want to highlight, very quickly, some of their key contributions. Context Toolkit is one of the first proposals in this regard. It introduces the concept of widget , as a software component that encapsulates sensors specific details, offering a common way of accessing sensor data. It also develops some general concepts related with context-aware frameworks, as discoverers, aggregators, etc. CoBrA implements an inference engine based on rules (ContextToolkit didn’t implement any engine), modelling context data using ontologies . SOCAM maintain some of the characteristics of CoBrA, but applying a service-oriented architecture based. and finally Gaia and CMF contribute with uncertainty support using also probabilistic reasoning. ---------------------------------------------------------------------------------------------------------------------------------------------- Well/OK, now, after this review, we are going to try to draw some general principles that should be taken into account when designing this kind of platforms.
First, it is necessary and architecture able to separate the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
First, it is necessary and architecture able to separate the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to maintain registries of available resources and to use dynamic sources of context information. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneity of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
First, it is necessary and architecture able to decouple the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy.
First, it is necessary and architecture able to separate the sensing infrastructure from the processing mechanisms and the final applications. In this way we can get reusability of software blocks and an extendible system. Inside of each of the different layers defined, a formal description of services together with discovery mechanisms permit to use dynamic sources of context information and to maintain registries of available resources. This service-oriented approach, using common services interfaces, modelling languages and communication protocols, are nowadays motivating interoperability, that is, service integration, inside the enterprises architecture and also between enterprises over the Internet. Due to the heterogeneous kind of final applications, the delivery of context information from lower to upper layers should be enough flexible and several modes of context retrieval should be supported, permitting PUSH and PULL context retrieval. The quality of the context information obtained affects directly to the performance of final context-aware applications (and, of course, user experience), so it is necessary to calculate the correctness of the acquired and the inferred information in order to ensure the expected quality of service. In order to maintain the response times in terms of number of users or operation load, these context-aware platforms should be able to dynamically add new sensors, algorithms or client applications. Finally, they should be designed thinking in the final user. Users don’t adapt to the system, but the system to them, adjusting the user’s behaviour and preferences, and always taking into account their privacy. -------------------------------------------------------------------------------------------------------------------------------------- And NEXT, we are going to identify some alternatives to implement context-aware systems that follow these principles.
Talking about architecture, there exist several technological platforms that implements a service-oriented approach: servlets are java classes, that process dynamically HTTP returning XML code. They are easy to implement and can be used from any client, just implementing HTTP. But, on the other hand, they do not implement services registry or discovery mechanisms so the input parameters are initially unknown
Talking about architecture, there exist several technological platforms that implements a service-oriented approach: servlets are java classes, that process dynamically HTTP returning XML code. They are easy to implement and can be used from any client, just implementing HTTP. But, on the other hand, they do not implement services registry or discovery mechanisms so the input parameters are initially unknown web services allow machine-machine interaction over networks using well-established standards. They are independent from the programming language and platform. Services are formally described using WSDL and can be discovered using UDDI ( Universal Description, Discovery and Integration ).
Talking about architecture, there exist several technological platforms that implements a service-oriented approach: servlets are java classes, that process dynamically HTTP returning XML code. They are easy to implement and can be used from any client, just implementing HTTP. But, on the other hand, they do not implement services registry or discovery mechanisms so the input parameters are initially unknown. web services allow machine-machine interaction over networks using well-established standards. They are independent from the programming language and platform. Services are formally described using WSDL and can be discovered using UDDI ( Universal Description, Discovery and Integration ). OSGi is a dynamic framework for Java that uses “bundles” as software unit. One or several bundles conform a service, and both, bundles and services, can be easily shared and reused. It is platform independent and it offers several service-management mechanisms. One of the main drawback of OSGi is that the service management mechanisms just work locally.
As we said before, there’s a need of exchanging context data from lower to upper levels, so here we present several technologies that ca be used to handle messaging between components of context-aware systems. sockets are easy to implement, generate low network traffic and have no client or server language or platforms restrictions. On the other hand, they don’t specify an standard message format so clients and servers should process raw data packets.
As we said before, there’s a need of exchanging context data from lower to upper levels, so here we present several technologies that ca be used to handle messaging between components of context-aware systems. sockets are easy to implement, generate low network traffic and have no client or server language or platforms restrictions. On the other hand, they don’t specify an standard message format so clients and servers should process raw data packets. XML/HTTP Another technique is to user HTTP and XML as query and response to a web server. It is also platform independent. XML has several advantages as flexibility or partial validation. Security can be partially supported using HTTPs. An there exist a lot of HTTP & XML management tools. As drawbacks we can say that: HTTP is not the fastest protocol XML lacks semantics.
As we said before, there’s a need of exchanging context data from lower to upper levels, so here we present several technologies that ca be used to handle messaging between components of context-aware systems. sockets are easy to implement, generate low network traffic and have no client or server language or platforms restrictions. On the other hand, they don’t specify an standard message format so clients and servers need to process raw data packets. XML/HTTP Another technique is to user HTTP and XML as query and response to a web server. It is also platform independent. XML has several advantages as flexibility or partial validation. Security can be partially supported using HTTPs. An there exist a lot of HTTP & XML management tools. As drawbacks we can say that: HTTP is not the fastest protocol XML lacks semantics. SOAP Allow to exchange data in a structured way. It is also platform and language independent based on XML and also independent of the transport protocol (HTTP, SMTP, etc.) However, it doesn’t mention any security mechanism.
A context modelling is also needed in order to integrate context data from multiple sources. The key-value model is the easiest way to model context information but, on the other hand, it doesn’t offer mechanisms to manage the information.
A context modelling is also needed in order to integrate context data from multiple sources. The key-value model is the easiest way to model context information but, on the other hand, it doesn’t offer mechanisms to manage the information. Mark-up schemes models do offer several tools manage information, and are used in many architectures but still cannot deal with incompleteness or ambiguity, that has to be handle at application level. Also it is not totally scalable.
A context modelling is also needed in order to integrate context data from multiple sources. The key-value model is the easiest way to model context information but, on the other hand, it doesn’t offer mechanisms to manage the information. Mark-up schemes models do offer several tools manage information, and are used in many architectures but still cannot deal with incompleteness or ambiguity, that has to be handle at application level. Also it is not totally scalable. Ontologies combine the advantages of object-oriented and logic-based models adding semantic when defining objects, concepts and their relations. This definitions are done in a structured, explicit and forma way being highly scalable allowing knowledge share and reuse partial validation of the model the inference of new information The main disadvantage of ontologies is their high complexity
The context-reasoning functionality is in charge of inferring new relevant information from the acquired context data. One of the most used method is the rule-based reasoning mainly used to reason about policies, restriction, alarms, etc. here it is easy to add or change rules rules are in general simple and understandable this kind of reasoning is usually used to complement other kinds of reasoning However, it does not support uncertainty modelling and it’s quite difficult to learn rules automatically. There exist several rules definitions languages and rules engines.
The context-reasoning functionality is in charge of inferring new relevant information from the acquired context data. One of the most used method is the rule-based reasoning mainly used to reason about policies, restriction, alarms, etc. here it is easy to add or change rules rules are in general simple and understandable this kind of reasoning is usually used to complement other kinds of reasoning However, it does not support uncertainty modelling and it’s quite difficult to learn rules automatically. There exist several rules definitions languages and rules engines. To finish with this section, bayesian networks , are able to handle uncertainty, ambiguity and incompleteness combining probability and graph theory these kind of models can be created automatically from observations so the need to be trained before being operational and are not practical for large systems. --------------------------------------------------------------------------------------------------------------------------- Well, then now we have translate these general principles, these functionalities and technologies into our own architecture proposal.
The main objective of the proposal is to decouple the context acquisition part from the context-aware applications. This is done by this middle layer called “Context Provider”, that encapsulates sensor data acquisition processes. For messaging we have used sockets, between sensor level and context provider and HTTP/XML between context provider and final applications The architecture is built over servlets, using web browsers or java applications as clients. Context modelling is stored in a database following a key-value model. Context reasoning is based on rules, but no inference engine is used, rules are defined at application level.
With this architecture, and using as sensors: WiFi and Bluetooth access points Zigbee motes accelerometers or heartrate monitors we are now able to develop -location or presence services -services of ambiental monitoring or -of activity recognition, for example