RestContext
A Service Framework for Context Retrieval
Leon O. Burkard, Andreas C. Sonnenbichler and Andreas Geyer-Schulz
Karlsruhe Institute of Technology, Institute of Information Systems and Marketing,
Kaiserstrasse 12, 76131, Karlsruhe, Germany
Keywords:
Context Service, Distributed, Autonomous, Restful, XMPP, Dynamic Software Architecture, Interoperability.
Abstract:
Todays context frameworks provide solutions for context mechanisms for individual applications only: context
aware working spaces, easier mobile development frameworks or higher-level context abstractions. RestCon-
text solves this problem with a service logically separating context as a set of information that can characterize
a situation from further context interpretation mechanisms. RestContext is a resource oriented architecture
which manages sensors of different types. A context may consist of sub-contexts as well as sensors that are
linked to one or many contexts. With the help of RestContext it is possible to create topologies of contexts.
Sensors can interact with context instances by push and pull mechanisms. We demonstrate how RestContext
can be used in a distributed weather forecasting example.
1 INTRODUCTION
Today’s mobile (and internet) services depend in-
creasingly on context information. A context is the
characterisation of a situation which consists of data
that in sum describes the situation. Contexts can
change over time due to changes in the data describ-
ing the situation. Based on the context, predictions
about future behaviour can be made. A context can
be described as a vector space C
s,t
that describes a sit-
uation s related to time t. Each vector v
i,t
stands for
the values of sensor device i ∈ I at time t. The value
of v
i,t
can be of any type:
C
s,t
=
v
1,t
v
2,t
v
i,t
...
v
I,t
For example, sensor 5 measures a temperature of 28.8
◦
C and a humidity 70% at t = 0. This results in
v
5,0
= (28.8;0.7). Agent-based systems can be used
to describe the process of collecting data and acting
upon the situation. According to Russel and Norvig,
an agent is “anything that can be viewed as perceiving
its environment through sensors and acting upon that
environment through actuators” (Russell et al., 1999,
p.34). From this definition we see that agents receive
input from so-called sensors. Various agents may re-
ceive data from different sensors. Sensors retrieve dif-
ferent kinds of data (e.g. geo-location, speed, temper-
ature, humidity) as v
i,t
. All (relevant) data received
from the sensors i ∈ I for an entity s in a time period
t we call “context” C
s,t
. Agents process information
they receive from sensors and other agents. Addition-
ally, agents may relay information to other agents and,
thus, can be used for building up structured agent net-
works (with certain topologies). Depending on their
internal agent’s logic, actuators can then be used to
influence the environment.
A definition of a topology is given by Bourbaki
(Bourbaki, 1998, p. 17): A topology on a set X is a
structure given by a set D ∈ P (X) with
∀d
1
, d
2
∈ D : d
1
∪ d
2
∈ D ∧ d
1
∩ d
2
∈ D
In reference to agent-based systems the set of all sen-
sors x
i
is X. A context is then a subset d
i
of D with D
being a topology on X. Topologies are especially use-
ful in distributed environments where a high number
of elements (e.g. sensors) is used.
Context data from sensors is an important fea-
ture for mobile devices like smartphones. E.g. geo-
location information is used for services like restau-
rant and hotel recommendations, navigation or addi-
tional information for search queries. Another ex-
ample is the collection of weather data. Let us con-
sider the infrastructure necessary to collect weather
data for a certain area like the federal state of Baden-
Wuerttemberg. Baden-Wuerttemberg is split into sev-
221
O. Burkard L., C. Sonnenbichler A. and Geyer-Schulz A..
RestContext - A Service Framework for Context Retrieval.
DOI: 10.5220/0004505502210232
In Proceedings of the 4th International Conference on Data Communication Networking, 10th International Conference on e-Business and 4th
International Conference on Optical Communication Systems (ICE-B-2013), pages 221-232
ISBN: 978-989-8565-72-3
Copyright
c
2013 SCITEPRESS (Science and Technology Publications, Lda.)
eral counties. In each county, at certain locations
weather data is measured (temperature, wind speed,
wind direction, humidity, air pressure, ...). These
sensor data are reported through certain hubs (e.g.
county-wise) to a central data storage (for the whole
of Baden-Wuerttemberg). The data collection of all
sensor data at all locations is then used to create lon-
gitudinal data rows in order to forecast the weather. In
this example, each specific sensor matches the general
sensor definition of Russel and Norvig.
In practice, sensors and agents use proprietary and
specialized implementations to communicate with
each other. No abstraction layer or generalized com-
munication infrastructure is used. In the worst case
this requires a specialized communication infrastruc-
ture and protocol for each type of sensor. This ap-
proach is error-prone and limits applications to benefit
from a broader usage of distributed data.
Context frameworks are abstractions that help to
generalize the communication: The introduction of
a context framework standardizes the communica-
tion between sensors, hubs, and agents. In our
weather data example, a temperature sensor uses the
same communication protocol to communicate with a
county hub as the hub does to communicate with the
state hub. The same is true for a humidity sensor. Fur-
ther, sensor data can be organized in contexts. E.g. all
weather data collected at weather station ”Karlsruhe-
Center”.
Instead of a direct communication with each sen-
sor, a context is defined. The context is utilized for
further communication. This abstraction omits de-
tailed and specialized knowledge necessary if only
proprietary communication is used. E.g. each sen-
sor type requires a different protocol. Without a con-
text framework it would be necessary to implement
these individual communications for every new re-
quest type like wind, air pressure, etc. If a new gener-
ation of temperature sensors is introduced in the field
without a context framework, each individual com-
munication with the new sensor has to be adapted. By
using a context framework, the communication stays
the same, only internally the communication with the
new sensor type has to be adapted. Thus context
frameworks are useful to increase the usability on the
device and the service side.
On the sensor side, a generic interface to trans-
mit data from sensors reduces faults, overhead in
development and platform specific implementations
regarding the communication with the environment.
New services like location-based emergency services
(Geyer-Schulz et al., 2011) are also possible by using
context-enabled applications.
As the amount of data that has to be processed
can become large e.g. for weather forecasting, a con-
text framework should provide the ability to build up
topologies in order to balance the load. Therefore,
agents should operate individually and offer the pos-
sibility to link them together. Additionally, as the
definition of context is based on the collection of
data forming information to characterize a situation,
a generic approach to define a context is preferred.
For example, to create a weather forecast for the fed-
eral state of Baden-Wuerttemberg we need to request
information from many weather stations with various
sensor types. The same infrastructure should also be
usable for flood forecasting which uses other sensors.
In most cases, context frameworks provide only
the ability to listen for updates from sensors and do
not give the ability to request sensors for updates or
status information like battery voltage. A possibility
to control sensor nodes is desirable.
We present a context framework, that enables a
distributed context service which communicates via
Extensible Messaging and Presence Protocol (XMPP)
(Saint-Andre, 2011) messages with sensors. It is pos-
sible to push sensor data from the sensor device to one
or many context-service instances as well as to pull
requests from context-service instances to the sensor
node in order to get updates. On the sensor node an
abstraction layer to the hardware is executed. It runs
a XMPP-client that registers to the service-context
and communicates via Extensible Markup Language
(XML) based messages with the context-service in-
stance. On the context-service side a RESTful web-
interface (Representational state transfer, see section
4.2 for a more detailed explanation) offers the flexibil-
ity to combine subscribed sensors to contexts. Com-
munication from the application side to the context
utilizes Hypertext Transfer Protocol (HTTP) requests.
Multiple context service instances can be linked to-
gether within contexts in order to achieve distributed
sensor data handling. Each context service instance
runs autonomously.
Our paper is structured as follows: In section 2
a definition of the term context-awareness is intro-
duced. Also a classification of abstraction levels be-
tween a sensor and an agent are presented. Section 3
highlights context frameworks that inspired the work
on our RestContext service. The main concepts of
the new context service are introduced in section 4
followed by the implementation of our prototype in
section 5. At last we discuss in section 6 possible en-
hancements for the RestContext service.
ICE-B2013-InternationalConferenceone-Business
222
2 CLASSIFICATION OF
CONTEXT SERVICES
In this section we define the term “context-awareness”
and give a short overview about different architectures
for context-aware systems.
2.1 Context and Context-awareness
M. Baldauf (Baldauf et al., 2007) describes differ-
ent design principles and context models for context-
aware systems and compares several frameworks and
middleware technologies. At first he discusses defi-
nitions of the term context. One of the most accurate
definitions in his point of view is given by Dey and
Abowd: ”We define context as any information that
can be used to characterize the situation of an entity,
where an entity can be a person, place, or physical or
computational object” (Dey and Abowd, 2000, p. 3).
We follow this definition: Our RestContext service
perceives a context as a collection of different sensor-
data at time t which can be enhanced by further infor-
mation and sub-contexts that are contexts themselves
as introduced in section 1.
Dey and Abowd also define context-awareness or
context-aware computing ”as the use of context to
provide task-relevant information and/or services to a
user” (Dey and Abowd, 2000, p. 11). To summarize,
Dey and Abowd define ”context” simply as a collec-
tion of information. In contrast, ”context-awareness”
refers to the application utilizing contexts.
Our RestContext service follows the definition of
”context-awareness”. Additionally, it offers advanced
functionality: it also enables the definition of a con-
text as a collection of sensors or other contexts. This
allows to create hierarchies of contexts and/or sen-
sors. These contexts may be of different types and
types may be mixed. In our prototype implementa-
tion, each contexts is represented by a uniform re-
source locator (URL).
2.2 Architectures for Context-aware
Systems
According to H. Chen (Chen, 2004, pp. 16 – 18),
three architectural styles can be distinguished to ac-
quire contextual information:
Direct Sensor Access. In this style, a sensor is ac-
cessed directly by an agent through a proprietary
protocol making not utilizing an abstraction layer.
Advantages are high performance for gaining and
processing sensor data. Hardware requirements
are low. Direct sensor access requires a device-
driver and a communication protocol for each ver-
sion of a sensor type for each manufacturer.
Middleware Infrastructure. This architectural style
encapsulates hardware access in a common soft-
ware interface for easier requests for sensor data.
Middleware components are ”typically built into
the hosting devices or platform on which the
context-aware applications operate” (Chen, 2004,
p. 17). A middleware infrastructure has higher
resource requirements for the hosting service.
Context Server. Multiple clients may access a re-
mote data source via a context server. The con-
text server need not be located on the sensor host-
ing hardware. It is an extension to a middle-
ware infrastructure located on the sensor node re-
sponsible for the communication with the sensor.
Clients access the context server in order to re-
trieve sensor data, resource intensive operations
are done by the context server. Concurrent access
by many users is possible because of less hard-
ware resource limitations which also results in an
improved scalability.
The decision for one architectural style depends on
the location of sensor units, amount of possible
users, hardware requirements and extensibility (Bal-
dauf et al., 2007).
3 RELATED WORK
In this section, we describe existing middle-
ware frameworks, context servers and a protocol
for weather data that inspired the work on our
RestContext-service.
The Gaia Project. The Gaia project (Roman et al.,
2002) builds up an operating system ”but at another
level of abstraction” (Roman et al., 2002, p. 75). It
distinguishes between ”physical” and ”active” spaces.
Physical spaces are geographic regions containing
physical objects like network devices. Active spaces
are extended physical spaces coordinated by context-
based software in a geographic region. Sessions in
active spaces allow mappings between applications
and user data, supplied by an own context file system
(CFS).
The Gaia system uses a three layer architecture as
depicted in figure 1: the ”Gaia kernel”, an ”applica-
tion framework” and ”active space applications”. Ac-
cess to the hardware is accomplished by the compo-
nent management core, offering basic services to the
layer above. These basic services are called the ”Gaia
RestContext-AServiceFrameworkforContextRetrieval
223
Figure 1: Gaia Architecture.
Kernel” and are part of the Gaia operating system. An
application may query and register for particular con-
text information to adapt to user behaviour and activ-
ities. ”Active space applications” adapt applications
to an active space like a conference room. Focus of
Gaia is the execution of user-centric applications like
a multi-device presentation tool adapting to the cur-
rent users location and devices. Roman et al. (Roman
et al., 2002) present as an application of the Gaia oper-
ating system a presentation manager: Each presenter
has an own profile. This profile is loaded as soon as
the person enters a Gaia enabled presenter room. With
the help of the profile personal shares are mounted as
one example.
Although the Gaia system fits into the definition
of context and context aware systems, it has a fun-
damentally different focus as a RestContext architec-
ture. Gaia’s aim is to create context aware working
places that add an adaptive environment in relation to
users. The objective of RestContext on the other hand
is the efficient distribution and aggregation of sensor
data.
The Context Toolkit. Another solution is sug-
gested by Salber et al. (Salber et al., 1999) and Dey
et al. (Dey et al., 2001): As smartphones and ubiq-
uitous computing in general have given users the ex-
pectation that information should be accessible every-
where at every time, the main objective of the “Con-
text Toolkit” is the support of such context-aware
computing systems. With the help of the “Context
Toolkit”, context-aware applications should be devel-
oped in an easier way. Therefore, the three layer ar-
chitecture shown in figure 2 is used:
Widgets. They have a mediator role between users
and an environment containing sensors. By pro-
viding an uniform interface to the underlying
hardware, details of the context-sensing mecha-
nisms are hidden. Polling and subscribing mech-
anisms are available.
Aggregators. These are called meta-widgets by Sal-
ber et al.. They are an extension to widgets by
providing all features of widgets plus aggregation
mechanisms for context information.
Interpreters. In this architectural part low-level
sensing data is combined in order to produce high
level information e.g. location or identity. Enrich-
ment or creation of new information is also pos-
sible. The following example is given by Dey et
al. (Dey et al., 2001): To detect if a meeting is
taking place in a conference room, a combination
of a sound level, identity and locations sensor is
necessary as a combined entity.
Communication is done via HTTP by all components
of the architecture. The main focus of the Context
Toolkit focus are context-aware applications like spe-
cial mailing lists mailing only to subscribers being lo-
cated in a specific building.
Although composition of contexts to a new con-
text is possible, the Context Toolkit is less feasible
than RestContext. Widgets as mediators are compiled
entities that can not be changed without a new roll-out
of a new compiled version. In RestContext a context
is created by adding XMPP ids or URLs of other con-
texts to a list. This offers the possibility to create and
change contexts in an easy way even while the system
is running. Also the Context Toolkit is missing func-
tionality to control sensors e.g. adjusting parameters
in a measuring unit by the design of their widgets.
Hydrogen. Hydrogen (Hofer et al., 2003) uses a
three layer architecture as presented in figure 3.
The bottom layer is the ”Adaptor Layer” which is
responsible for getting sensor value data and to com-
municate with the ”Management Layer”. It offers si-
multaneous access to the hardware through one con-
text instance instead of direct sensor access that uses
locking mechanisms. Sensors are directly connected
to this layer. The ”Management Layer” provides
and retrieves contexts by interacting with the ”Adap-
tor Layer”. In the ”Management Layer” the context
server is located. It offers asynchronous (querying
Figure 2: The Context Toolkit Architecture.
ICE-B2013-InternationalConferenceone-Business
224
specific contexts) and pull-based interaction. Appli-
cations that use the context server in the ”Manage-
ment Layer” are part of the ”Application Layer”. To
be robust against network connection difficulties, all
three layers are deployed on the sensor hardware. To
exchange contexts with the environment, a peer-to-
peer mechanism is used. For each type of context
(located in the ”Adaptor Layer”) an extended version
of a ”Context Object” class being the base class for
all context objects has to be developed. This is done
by implementing two abstract methods toXML() and
fromXML() for non-Java applications to ensure inter-
operability.
Having located all three layers on the mobile de-
vice Hydrogon’s approach is problematic in terms
of data distributed systems like weather forecasting.
Due to this fundamental design decision to focus on
local mobile hardware, Hydrogen is lacking the pos-
sibility of different views on one sensor e.g. one view
on a water level sensor that does updates of its values
every hour and is free to use and another view that
updates every minute but isn’t for free.
CASS Middleware. The CASS-Middleware
(Context-awareness sub-structure)(Fahy and Clarke,
2004) is a server based middle-ware with focus on
support for ”higher-level context abstractions and
is both flexible and extensible in its treatment of
context” (Fahy and Clarke, 2004, p. 1).
Applications communicate with the CASS mid-
dleware and not directly with sensors. The CASS
is a centralized service. Sensor nodes (located on
the sensor hardware or computers directly attached
to them) are connected, as depicted in figure 4, to a
server-based middleware that can offer more memory
and processor resources. CASS offers caching abili-
ties for applications to reduce temporary connection
issues. A ”knowledge base” contains rules to map
sensor values to context-aware keys, e.g. weather sen-
sor data indicating bad weather to recommend indoor
activities. In the CASS middleware a ”sensor lis-
tener” is responsible for getting low-level sensor data
from a pushing mechanism on the sensor node side.
A ”change listener” is connected to the SensorLis-
tener to inform subscribed hand-held computers on
Figure 3: The Hydrogen Architecture.
Figure 4: CASS Architecture.
changed contexts.
The CASS framework lacks the possibility of
building up topologies of sensor and other middle-
ware nodes as by design the CASS middleware is pro-
vided by a single server instance. In the presented ver-
sion of the CASS middeleware only pushing of values
from sensor nodes to a SensorListener instance is sup-
ported, pull mechanisms to retrieve data and control
sensors are missing.
OpenWeather. A. Yanes suggests a peer-to-peer
weather data protocol (OpenWeather) to provide a
standardized way to transmit weather data (Yanes,
2011). OpenWeather is a protocol based on TCP us-
ing the protocol’s features such as error and flow de-
tection. Its aim is to break bottlenecks in scenarios
of these days automated weather stations (AWS) that
use proprietary or standard protocols like Server Mes-
sage Block (SMB) (Microsoft Corporation, 2013) and
FTP for the transfer of weather data to remote destina-
tions. Problems are e.g. the missing real-time transfer
of weather data, intermediary conversion steps before
data transfers, performance issues regarding fetching,
transmitting as wells as manipulating data and in gen-
eral that no protocol takes advantage of the capabil-
ities of AWS. However, OpenWeather “does not im-
plement an aggregation technique between the nodes”
(Yanes, 2011, p.87), although the author states that
OpenWeather can be extended in such a way. Al-
though OpenWeather presents the possibility of rout-
ing HTTP requests through a protocol bridge, Open-
Weather is limited in terms of creating contexts using
wide spread standard protocols, because the applica-
tion domain is restricted to weather stations and not
sensors in general. The objective of RestContext is
to present a generic approach of generating and dis-
tributing contexts while using any kind of sensor and
being a basis for specific adaptations.
4 ARCHITECTURE OF THE
RestContext SERVICE
In this section we present a generic layout for a con-
text service. We provide requirements followed by a
RestContext-AServiceFrameworkforContextRetrieval
225
Table 1: Comparison of the presented projects and RestContext.
Gaia Project Context Toolkit Hydrogen CASS RestContext
Requirements Operating sys-
tem for context
aware working
spaces
Support of con-
text aware com-
puting systems
Context aware-
ness for devices
with limited re-
sources
Server based
middleware
that support
context aware-
ness
Efficient distri-
bution and
aggregation of
sensor data
Lightweightness
Extensibility
Robustness n.i.
Distribution
Interoperability
Genericity n.i. n.i. n.i.
Two-way com-
mmunication
n.i.
Different Lev-
els of Precision
Interpretation
of the context
– not satisfied – partly satisfied – completely satisfied n.i. – no information
generic architecture and the underlying main concepts
of the RestContext service. In section 5 we present
details about the concrete implementation of a proto-
type of the RestContext architecture.
4.1 Requirements for a Context Service
We determined the following set of requirements for
building a generic context service by analyzing the
following context-aware systems from the literature:
the CASS middleware (Fahy and Clarke, 2004), Hy-
drogen (Hofer et al., 2003), ContextToolkit (Salber
et al., 1999). The first three requirements are from
(Hofer et al., 2003). (Fahy and Clarke, 2004) share
the requirement of robustness. The requirements
distribution, interoperability, genericity and two-way
communication were identified by evaluating the ex-
isting architectures. Altough not all systems identified
these requirements explicitely. The Context Toolkit
(Salber et al., 1999) is missing a dynamic approach
for adding and removing elements. On the other hand
the CASS middleware (Fahy and Clarke, 2004) does
not offer the possibility to pull values from a sensor
node.
Lightweightness. The architecture has to deal with
limited resources and low hardware requirements
on the sensor hardware side.
Extensibility. New context elements should be
added and removed easily to existing contexts.
Connections to several remote sensors should be
possible.
Robustness. Disconnections, temporary connection
issues or other disruptions of a few sensor devices
should not break the context service.
Distribution. Since collecting and managing sensor
data of a large amount of sensors requires high re-
sources on the server side, a distributed architec-
ture with autonomic instances of a context-service
is preferred.
Interoperability. Standard communication proto-
cols should be supported to achieve uniform ac-
cess by different applications to the context ser-
vice.
Genericity. Context adding and removing ought to
be done while running the system. The architec-
ture should not be limited to special types of con-
text.
Two-way Communication. Sensor data should be
delivered both by push and pull mechanisms.
Rudimentary sensor management can be provided
by a managing instance on the context service
side.
Different Levels of Precision. One sensor ought of-
fer different levels of precision e.g. for various
use-cases, pricing-models or security settings. For
example the National Association of Securities
Dealers Automated Quotations (NASDAQ) offers
different pricing models regarding the time reso-
lution of stock market prices. Another example is
the former used selective availability
1
feature of
1
http://www.gps.gov/systems/gps/modernization/sa/
ICE-B2013-InternationalConferenceone-Business
226
the U.S. government that degraded the GPS sig-
nal “for national security reasons”.
A comparison of the support of the requirements by
the Gaia project, the context toolkit, hydrogen, the
CASS middleware and RestContext is presented in ta-
ble 1.
4.2 Architecture
To achieve lightweightness of the architecture, com-
munication with the sensor hardware takes place
via the Extensible Messaging and Presence Protocol
(XMPP) (Saint-Andre, 2011). For this protocol, many
client-libraries are available
2
. They can also be used
in embedded systems with low hardware resources.
Because of these features, XMPP can be used for the
communication between a context service and sensor
hardware. XMPP is a protocol standardized by the
Internet Engineering Task Force (IETF) that results
in a non proprietary protocol stack. It is a mature
mechanism to exchange messages (nearly) in real-
time. Messages are based on XML, so standard toolk-
its can process them easily. XMPP has a broad indus-
trial base (e.g. Google, Facebook). By using names-
paces custom data messages can be created. There are
various open source XMPP servers availabe
3
that can
be used to build up a private network of clients which
is not accessible to everyone.
Interoperability is achieved by the usage of the
HTTP protocol on the node-side in a resource ori-
ented way (REST). REST is an abbreviation for ”Rep-
resentational State Transfer” and was introduced in
the dissertation of Roy T. Fielding (Fielding, 2000).
All communication between distributed context ser-
vices as well as client applications to the context ser-
vice is done through HTTP requests. Caching mecha-
nisms (e.g. saving the last sensor value each) and sta-
tus codes of the HTTP protocol help to achieve the
requirement of robustness sufficiently.
Figure ?? gives an outline of the RestContext ar-
chitecture: A SensorView is a layer on top of the di-
rect sensor access mechanism. It is responsible for
delivering sensor data to a RestContext instance and
receiving XMPP commands. Commands are sent by
chat-messages that follow the pattern
command pa-
rameters/data
. A SensorView registers to one or
more RestContext instances by the
hello
command
via the XMPP protocol. The parameter of the
hello
command is a
session-Id
, identifying the view on
the sensor. On the one hand, it offers the possibil-
ity to have different views on one sensor e.g. one id
2
http://xmpp.org/xmpp-software/libraries/
3
e.g. , http://www.ejabberd.im/
for temperature with a precision of five degrees, an-
other id for an accuracy to a tenth (requirement Dif-
ferent levels of precision). On the other hand it is a
shared secret between the SensorView and a RestCon-
text instance of trust to ban foreign access to the Sen-
sorView. Further parameters to the
hello
command
are the type of the sensor and a meta data field for
details and status about the sensor hardware. Each
request to the SensorView instance has the shared se-
cret as parameter. The sessionId can be updated by
the
helloupdate
commmand.
To support the requirement of two-way communi-
cation from section 4.1, a SensorView may push val-
ues by the
myvalues
command and react on pull re-
quests by the
getcurrentvalues
command. To get
current information about the sensor device the
get-
info
command is used.
The RestContext instance has two communication
interfaces: The XMPP communication interface with
SensorView instances and the communication inter-
face via HTTP for communication with other Rest-
Context instances and applications. There are two
main tasks for a RestContext instance:
1. Offer communication abilities over HTTP from
applications and RestContext instances to Sen-
sorView instances and other RestContext in-
stances.
2. Manage a collection of contexts that consists of
local or remote contexts and SensorViews. Local
means that the SensorView instance or context is
located on the RestContext instance in question.
Remote contexts and SensorViews on the other
hand are not located on the related RestContext
instance and therefore have a different base URL.
RestContext owns a pool of registered Sen-
sorView instances accessible by an URL. Over the
unique URL of the sensor other RestContexts may ac-
cess the SensorView instance and both get data from
the device and send requests (e.g. to update sensor
value data) to it. For each SensorView instance, cur-
rently the last sensor value is saved in the RestContext
instance. The technical implementation of a context
is a collection of URLs. These URLs can be hyper-
links to local or remote SensorView instances. They
can also be hyperlinks to local or remote contexts be-
ing part of RestContext instances that manage own
collections. By using lists of links, different Rest-
Contexts can be composed in tree structures to fulfill
the requirements of distributed contexts, extensibility
and genericity. The link structure can return current
values of all context elements by using recursive re-
quests to all sub-hyperlinks. Also recursive updating
of all data is possible. To prevent cycles in RestCon-
texts that are linked together, each sub-request adds its
RestContext-AServiceFrameworkforContextRetrieval
227
!""###
!"###
! $"
"!
%!
&
!
'
(
)
*+
,$$
+
-%
.&,$
/0''
! !/0''"
& !/0''"
%!
""
"+""
!"!
1'
2
,,$
3$
%!$
3,$
-,$
3
(
)
,
!1'
) )
,
!/0''
,3
4!
) )
,
!1'
!""###
!""###
!"###
! $"
"!
%!
&
!
'
(
(
)
)
*+
*+
) )
,$$
+
-%
.&,$
/0''
! !/0''"
& !/0''"
%!
""
"+""
!"!
1'
2
,,$
3$
%!$
3,$
-,$
3
(
(
)
,
!1'
!1'
) )
)
,3
4!
)
!"
Figure 5: The RestContext Architecture.
URL to a list in the request body of the HTTP request.
Each instance of RestContext checks the list to detect
loops in the request chain. If a cycle occurs, instead
of a value structure, an error message is returned.
Context-aware applications can access and mod-
ify the RestContext service by HTTP requests. Ad-
vantage of using the HTTP protocol are the wide-
spread and robust HTTP-client implementations (e.g.
Apache HttpComponents
4
). A robust implementation
of an HTTP-client is available for nearly all devices,
especially smart phones and embedded systems.
5 PROTOTYPE
In section 4.2 we outlined the architecture and main
concepts of RestContext. In this section we present
a concrete implementation of the context service as a
prototype.
The URL interface structure of our RestContext
implementation is presented in table 2. The imple-
mentation follows the RestContext architecture (pre-
sented in section 4), shown in figure 5.
Each SensorView instance is accessible by its own
URL, can return values via the HTTP-GET command
and also update values by HTTP-POST requests.
4
http://hc.apache.org/
The update mechanism works as follows: A POST
request is received by the RestContext instance. The
instance sends an update request via XMPP to the cor-
responding sensor (with the known session-id param-
eter). While no updated values are received, a GET
request to the update values resource returns a status
information. Once the SensorView instance updated
its values, the status information changes as demon-
strated in figure 6. A context under a given {id} can
be modified by POST requests to add items, DELETE
requests for deleting items and GET requests to re-
trieve items.
All resources have a representation in the JSON
data format. Each resource has various links to pos-
sible further actions e.g. by requesting a SensorView
instance by an id. Links to the
updateinfo
,
updat-
evalues
and
values
resources are also returned.
The prototype has been implemented in the pro-
gramming language Python by usage of the Python
frameworks web.py
5
and jabberbot
6
. A modified ver-
sion could also be deployed to the Google App En-
gine
7
(using their xmpp-library), so RestContext in-
stances may be executed on a cloud infrastructure.
5
http://webpy.org/
6
http://thp.io/2007/pythonjabberbot/
7
https://developers.google.com/appengine/
ICE-B2013-InternationalConferenceone-Business
228
Table 2: URL interface structure of RestContext.
URL Description
http://host/registeredsensor List of all registered SensorView instances.
http://host/registeredsensor/{id} URL of a SensorView with id {id}.
http://host/registeredsensor/{id}/values Representation of current values.
http://host/registeredsensor/{id}/updateinfo Sending request for sending updated status and meta infor-
mation of the sensor over XMPP.
http://host/registeredsensor/{id}/updatevalues Sending request to SensorView instance for updating val-
ues (pull-request) over XMPP.
http://host/information Common information about the RestContext service in-
stance like XMPP-id, uptime, status. etc.
http://host/context List of all created contexts.
http://host/context/{id} URL of context with id {id}.
http://host/context/{id}/elements Managing structure for all elements associated with this
context.
http://host/context/{id}/values List of all cached values of the associated context.
http://host/context/{id}/updatevalues Sending an update sensor data request to all elements asso-
ciated with this context.
http://host/context/{id}/updateinfo Sending an update sensor information request to all ele-
ments associated with this context.
5.1 Use Case
Figure 7 shows a use-case scenario for the Rest-
Context service. Based on this use-case we will
demonstrate our implementation of the RestContext
architecture. The use-case offers meteorological
services for the federal state Baden-Wuerttemberg
with two counties. Each county has locations,
shown by location circles in the figure. There
exist sensors that belong to geographical regions.
There is also a storm forecasting service with
its own sensors, a sensor registered at the loca-
tion 2 RestContext instance and a sensor temper-
ature 4 that has registered to two RestContext in-
stances. All circles with no background color run
instances of the RestContext service and are reach-
able by the dummy URL
http://nameofcircle/
and XMPP-Id
xmpp:nameofcircle
for example
http://location1/
resp.
xmpp:location1
. Sen-
sors are all filled circles and addressable by the
XMPP-ID
xmpp:nameofsensor
.
Setting Up the Infrastructure.
•
xmpp:temperature1
registers to
xmpp:lo-
cation1
with a message hello 123 temperature
somemetadata.
• All other instances of SensorView are doing the
same to their corresponding RestContext ser-
vice. The sensor
temperature4
registers to both
RestContext instances
xmpp:stormforecast
and
xmpp:location3
.
• A context (e.g.
http://stormfc/context/1/
)
on the storm forecast node adds sen-
sor temperature 3 by adding the url
http://location2/registeredsensor/tem-
perature3
to one or many of its contexts.
• In order to build up a topology, a context on node
county1 (e.g.
http://county1/context/2
)
adds the context of location 1 (e.g.
http://location1/context/3
) that refers
to temperature 1 (
xmpp:temp1
). The next level of
the topology is constructed by adding the context
url (e.g.
http://county1/context/2
) of county
1 to a context url of
http://bawue/context/id
.
• If the storm forecast context doens not require
the sensor temperature 3 any more, it erases the
url of the context refering to temperature 3 (e.g
http://location2/registeredsensor/tem-
perature3
) from its list of elements (e.g.
http:// stormfc/context1/
).
Requesting the Infrastructure.
• If you are interested in the current tempera-
ture value of location 1, you request the url:
http://location1/context/
{
1
}
/values
• The sensor temperature 1 pushes current values to
the RestContext location1 periodically.
• To update sensor values aperiodically of the sen-
sor temperature 1, you do a POST request to
RestContext-AServiceFrameworkforContextRetrieval
229
Push values to a RestContext instance (Update values)
Pull values of a SensorView instance (Get cached values)
Update values of a sensor in a RestContext instance
Figure 6: Sequence diagram of communication between a client and a RestContext and SensorView instance.
Ba de n-W ue rt t em be r g
Location 1 Location 2
Location 3
County 1
County 2
temp erature 1 temp erature 2 temp erature 3
Storm forecast
barometric
pressure
wind strenght
temp erature 4
Figure 7: Use-case scenario for the RestContext service.
the url:
http://location1/registeredsen-
sor/
{
temperature1-id
}
/updatevalues
• To get all temperature values of the country (get-
ting all four temperature sensors) a GET request
to the following URL is sufficient:
http://country/context/
{
1
}
/values
• A request to the storm forecast service for val-
ues does a further GET request to the location 2
RestContext service instance. Four sensor values
(barometric pressure, wind strength, temperature
3 and temperature 4) are returned.
• Modifications (adding, changing or remov-
ing contexts resp. sensors) are implemented
by changing the list of the resource ele-
ments of context id (URL:
http://host/con-
text/
{
id
}
/elements)
.
ICE-B2013-InternationalConferenceone-Business
230
6 CONCLUSIONS AND FUTURE
WORK
In section 3 we presented some middleware and con-
text frameworks that inspired the work on the Rest-
Context service. Especially the Context Toolkit archi-
tecture with its widget and aggregate layers proposed
the separation of an instance running on or nearby
the sensor hardware and a second layer with sufficient
hardware resources on the internet.
Our RestContext service is an architecture for dis-
tributed contexts in order to deal with a high num-
ber and types of sensors and different settings of con-
texts. Based on standard communication protocols
it offers interoperability between different operating
systems. Due to its resource oriented design, it can be
extended to further communication activities to and
from the sensor devices like controlling and manag-
ing the sensor hardware by resources. However, Rest-
Context is missing event based notifications such as
the Context Toolkit. Also RestContext is static in the
way of defining contexts. A definition of a context
that is self-changing based on its environment needs
further work e.g. , a context that contains nodes of
elements that are within an area. RestContext is cur-
rently in a prototype state and missing the functional-
ity to remove registered SensorView instances from
one or many RestContext instances. Currently, we
do not address advanced authentication and authoriza-
tion mechanisms as presented by Sonnenbichler (Son-
nenbichler and Geyer-Schulz, 2012) for distributed
requests across multiple RestContext instances.
Future work includes the development of a con-
text inference mechanism as introduced by the CASS
framework (Fahy and Clarke, 2004) and a persistence
mechanism to archive sensor data e.g. by extend-
ing the values resource structure. Automatic match-
ing, conversion and merging of values e.g. automatic
conversion of degree Fahrenheit to Celsius could be
achieved by combining ontologies with RestContext.
Aggregation techniques like average out values (e.g.
air pressure) of various SensorView instances are de-
sirable as well. Also a prioritization of nodes, e.g. to
prefer nodes from local hardware rather than exter-
nal information should be implemented in future ver-
sions of RestContext. Another improvement would
be an automatic registration of a SensorView instance
to one or many RestContext instances. This automatic
registration could draw on concepts used by the Dy-
namic Host Configuration Protocol (DHCP) (Droms,
1997).
Further research is required to allow anony-
mous communication between RestContext and Sen-
sorView instances. This objective is useful for set-
tings where the identity of the sensor should be hid-
den. Reasons may be privacy or security concerns e.g.
in the field of traffic jam prediction where only the
presence of a car on a route is important, not its iden-
tity itself. One attempt for privacy concerns might use
the possibility of the XMPP protocol to allow anony-
mous login to XMPP servers. Asynchronous com-
munication handling like notifications to applications
working with RestContext instances can be developed
by using the upcoming WebSocket protocol described
in the RFC 6455 (Fette and Melnikov, 2011).
REFERENCES
Baldauf, M., Dustdar, S., and Rosenberg, F. (2007). A sur-
vey on context-aware systems. International Journal
of Ad Hoc and Ubiquitous Computing, 2(4):263–277.
Bourbaki, N. (1998). General Topology: Chapters 1 –
4. Springer, Berlin/Heidelberg, Germany. Originally
published as
´
El
´
ements de Math
´
ematique, Topologie
G
´
en
´
erale 1–4.
Chen, H. (2004). An Intelligent Broker Architecture for Per-
vasive Context-Aware Systems. PhD thesis, University
of Maryland, Baltimore, USA.
Dey, A. and Abowd, G. (2000). Towards a better under-
standing of context and context-awareness. In Pro-
ceedings of the Workshop on The What, Who, Where,
When, and How of Context-Awareness, as part of the
2000 Conference on Human Factors in Computing
Systems, The Hague, Netherlands.
Dey, A. K., Abowd, G. D., and Salber, D. (2001). A concep-
tual framework and a toolkit for supporting the rapid
prototyping of context-aware applications. Human–
Computer Interaction (HCI), 16(2):97–166.
Droms, R. (1997). Dynamic Host Configura-
tion Protocol. RFC 2131 (Draft Standard).
http://www.ietf.org/rfc/rfc2131.txt.
Fahy, P. and Clarke, S. (2004). CASS –a middleware for
mobile context-aware applications. In Workshop on
Context Awareness, MobiSys, Boston, USA.
Fette, I. and Melnikov, A. (2011). The Web-
Socket Protocol. RFC 6455 (Proposed Standard).
http://www.ietf.org/rfc/rfc6455.txt.
Fielding, R. (2000). Architectural styles and the design
of network-based software architectures. PhD thesis,
University of California, USA.
Geyer-Schulz, A., Ovelg
¨
onne, M., and Sonnenbichler, A. C.
(2011). A social location-based emergency service
to eliminate the bystander effect. In E-Business and
Telecommunications, Communications in Computer
and Information Science, pages 112 – 130. Springer,
Berlin/Heidelberg, Germany.
Hofer, T., Schwinger, W., Pichler, M., Leonhartsberger, G.,
Altmann, J., and Retschitzegger, W. (2003). Context-
awareness on mobile devices - the hydrogen approach.
In Proceedings of the 36th Annual Hawaii Interna-
tional Conference on System Sciences, Hawaii, USA.
IEEE.
RestContext-AServiceFrameworkforContextRetrieval
231
Microsoft Corporation (2013). [ms-smb]: Server message
block (smb) protocol. http://msdn.microsoft.com/en-
us/library/cc246231.aspx. last accessed: 2013-03-01.
Roman, M., Hess, C., Cerqueira, R., Ranganathan, A.,
Campbell, R. H., and Nahrstedt, K. (2002). A middle-
ware infrastructure for active spaces. Pervasive Com-
puting, 1(4):74–83.
Russell, S. J., Norvig, P., and Russell, S. J. (1999). Artificial
Intelligence: A Modern Approach. Prentice Hall, New
Jersey, USA, 2 edition.
Saint-Andre, P. (2011). Extensible Messaging and Presence
Protocol (XMPP): Core. RFC 6120 (Proposed Stan-
dard). http://www.ietf.org/rfc/rfc6120.txt.
Salber, D., Dey, A. K., and Abowd, G. D. (1999). The
context toolkit: aiding the development of context-
enabled applications. In Proceedings of the SIGCHI
conference on Human Factors in Computing Systems,
CHI ’99, pages 434–441, Pittsburgh, USA. ACM.
Sonnenbichler, A. and Geyer-Schulz, A. (2012). ADQL: A
flexible access definition and query language to define
access control models. In Samarati, P., editor, Pro-
ceedings of the International Conference of Security
and Cryptography, Rome, Italy.
Yanes, A. (2011). Openweather: a peer-to-peer weather
data transmission protocol. CoRR, abs/1111.0337.
ICE-B2013-InternationalConferenceone-Business
232
