Interoperating Context Discovery Mechanisms
*
Tom Broens
1
, Remco Poortinga
2
and Jasper Aarts
1
1
Centre for Telematics and Information Technology, ASNA group, University of Twente
P.O. Box 217, 7500 AE Enschede, The Netherlands
2
Telematica Instituut, PO Box 589, 7500 AN Enschede, The Netherlands
Abstract. Context-Aware applications adapt their behaviour to the current
situation of the user. This information, for instance user location and user avail-
ability, is called context information. Context is delivered by distributed con-
text sources that need to be discovered before they can be used to retrieve con-
text. Currently, multiple context discovery mechanisms exist, exhibiting het-
erogeneous capabilities (e.g. communication mechanisms, and data formats),
which can be available to context-aware applications at arbitrary moments dur-
ing the application’s lifespan. In this paper, we discuss a middleware mecha-
nism that enables a (mobile) context-aware application to interoperate transpar-
ently with different context discovery mechanisms available at run-time. The
goal of the proposed mechanism is to hide the heterogeneity and availability of
context discovery mechanisms for context-aware applications, thereby facilitat-
ing their development.
1 Introduction
The Service-Oriented Architecture (SOA) paradigm provides a promising approach to
develop distributed applications. In this paper, we are concerned with (distributed)
context-aware applications, which are applications that use the current situation,
called context, to adapt their behaviour [1]. There are numerous examples of possible
types of context, depending on the goal of the application. Examples of context are
user location and availability, room temperature, and available bandwidth on a com-
munication link. Context-aware applications use information on the context to adapt
their functionality with the aim of improving the quality of the service offered to the
user. For example, a context-aware ’buddy navigation application’ that can offer
quick and personalized navigation to available buddies, based on the location of the
user and his buddies, correlated with the availability of the buddies. Context is usu-
ally provided by various distributed context sources (e.g. GPS sensors for location
information, calendar for scheduling or availability information, MSN messenger for
buddy information, weather stations for current weather conditions). The application
*
This work was partly supported by the Freeband AWARENESS Project. Freeband is sponsored by the
Dutch governm
ent under contract BSIK 03025. Additionally, this work was partly supported by the Euro-
pean Commission as part of the IST-IP AMIGO project under contract IST–004182.
Broens T., Poortinga R. and Aarts J. (2007).
Interoperating Context Discovery Mechanisms.
In Proceedings of the 1st International Workshop on Architectures, Concepts and Technologies for Service Oriented Computing, pages 75-84
DOI: 10.5220/0001348400750084
Copyright
c
SciTePress
environment may contain several useful context sources at any point in time, how-
ever, due to for example the mobility of the application or the context sources, the
number and identity of context sources may change over time. This requires mecha-
nisms to discover context sources before an application can retrieve context informa-
tion. Currently there is a trend towards middleware mechanisms that facilitate the
development of context-aware applications [2]. Major contributions in this area are
context management systems that facilitate the context exchange process, including,
amongst others, the discovery of context sources. Consequently a vast amount of
context discovery mechanisms exist, which have different capabilities and scope [2-
5]. We believe it is unlikely that there will be one future commonly adopted context
discovery mechanism. As implied by the diversity of currently available context dis-
covery mechanisms, different application environments (e.g. ad-hoc environments,
telco environments) require different mechanisms to exchange their context informa-
tion. Therefore, the mechanisms, which context-aware applications have to use to
discover context sources from these environments, will be diverse. Consequently,
(mobile) context-aware applications are likely to be exposed to multiple and changing
context discovery mechanisms during their lifespan. Without supporting mechanisms
to cope with this aspect, developers have to design and incorporate interoperability
mechanisms or consider every possible mechanism statically in their application.
Besides the required, substantial, programming effort, this also distracts from the
primary task of developing context-aware applications.
In our view, there are three approaches to interoperate context discovery mecha-
nisms:
Standardisation: every environment that wants to offer context discovery uses
one standard context discovery mechanism. However, as already indicated, due
to the heterogeneity and different requirements of the application environ-
ments, this is not feasible or likely.
Bridging: every environment has a different discovery mechanism that is inter-
nally bridged to other discovery mechanisms by bridging components or code.
Homogenising: every environment has different discovery mechanisms that are
homogenized by a generic middleware layer, optionally co-located with the ap-
plication (see Figure 1 for a comparison of the bridging and homogenising ap-
proach).
Fig. 1. Comparison of the bridging and homogenising approach.
76
In this paper, we explore the homogenising approach and propose a middleware
mechanism that enables a context-aware application to interoperate transparently with
different context discovery mechanisms that are available at run-time. The goal of the
proposed mechanism is to hide the heterogeneity and availability of context discovery
mechanisms for context-aware applications, thereby facilitating their development.
We envision the proposed homogenising approach as part of a comprehensive SOA
infrastructure to support composable context-aware services. The AWARENESS
project (http://awareness.freeband.nl) also explores the bridging approach which is
discussed in [3, 6]. The remainder of this paper is structured as follows: section 2
discusses a motivating scenario of a context-aware application that uses multiple
context discovery mechanisms. Section 3 presents an analysis of current context dis-
covery mechanisms. This analysis is used to derive requirements for our interopera-
bility mechanism. Section 4 discusses our contribution towards interoperability of
context discovery mechanisms. Section 5 presents our proof-of-concept prototype and
gives an initial qualitative evaluation. Finally, in section 6, we will end with some
conclusions.
2 Scenario
In this section, we reconsider the context-aware ‘buddy navigation application’ and
use it to identify key difficulties that application developers face when developing
context-aware applications.
Dennis is a young adult, always wanting to be in contact with his friends. He
has a mobile device running the ‘buddy navigation application’. This application
is able to navigate to available buddies by using location and availability context
information of him and his friends. Dennis notices that Monica is in the mall and
available for a cup of coffee. He decides to visit her. He instructs the ‘buddy navi-
gation application’ to help him find her. Inside Dennis’ home, a RFID based loca-
tion context source, found by his home context discovery mechanism, provides
accurate location of Dennis. From Monica no precise location source is available
in Denis’s home, it is only known that she is somewhere in the mall. The ‘buddy
navigation application’ instructs Dennis to take the car to the mall. When Dennis
leaves his home, to go on his way to Monica, his home discovery mechanism be-
comes unavailable. The application switches to a cell based location context
source found by the context discovery mechanism of his telecommunication pro-
vider. On entering the mall Monica is in, accurate context information on
Monica’s location becomes available, offered by a Bluetooth beacon context
source found by the context discovery mechanisms of the mall. The buddy naviga-
tion application pops up a map of the mall, to instruct Dennis how to walk to the
book store where Monica is currently shopping.
From the scenario, we can identify the following difficulties, related to context dis-
covery that application developers face when developing context-aware applications:
Finding of context sources through different context discovery mechanisms
(e.g. ‘home’, ‘telecommunication’, and ‘mall’ context discovery mechanisms).
77
Fluctuating availability of context discovery mechanisms (e.g. when Dennis
leaves his home his home context discovery mechanism is not available any
more).
In this paper, we propose a middleware mechanism that has the goal to support con-
text-aware applications to interoperate with multiple heterogeneous context discovery
mechanisms, considering their availability during the lifetime of the application.
3 Analysis of Current Context Discovery Mechanisms
As indicated, many context discovery mechanisms exist. We analysed a subset of
these mechanisms consisting of four approaches developed in the AWARENESS
project (CMF, CCS, CDF, JEXCI)[3], and one approach developed in the AMIGO
project (CMS)[7] and four external approaches (Context Toolkit [5], PACE [2], Solar
[8], and JCAF[4]). The result of our analysis is presented in Table 1. The analysis
consisted of reviewing the following aspects of the different discovery mechanisms:
Interaction mechanism: what interaction mechanisms do the analyzed discov-
ery mechanisms support?
Interaction syntax: what information is expressed in the context discovery re-
quest?
Interaction format: what is the data format of the request and response?
Table 1. Context discovery mechanisms analysis results.
Interaction format
Frameworks Req-Resp Sub-Not Entity Type QoC
CMF v v v v v RDF
CCS v v v v v SQL/PIDF
CDF v v v v v RDF/PIDF
Jexci v v v v v Negotiable (PIDF/java objects)
CMS v v v v v RDF
Context Toolkit v v v v - XML
Pace v v v v v Context Modelling Language
Solar v v v v - ?
JCAF v v v v - Java objects
Interaction syntaxInteraction mechansism
We distinguished the following common aspects in the analysed approaches,
which pose requirements on the capabilities our interoperability mechanism should
offer to context-aware applications it supports:
The ‘request-response’ and ‘subscribe-notify’ interaction mechanisms are of-
fered.
Requests for context minimally specify an entity and context type (e.g. ‘Loca-
tion’ of ‘Tom’).
Requests for context may contain Quality of Context [9, 10] criteria.
We distinguished the following uncommon aspects in the analysed approaches,
which pose requirements on the heterogeneity our interoperability mechanisms
should have to overcome:
Data models (syntax and semantics) of the request and response (ontology,
simple strings, binary).
Communication technologies (e.g. web services, jini).
78
Intelligence inside the context discovery mechanism (e.g. reasoning, selec-
tion).
4 Context Discovery Interoperability Mechanism
The scenario in section 2 and the analysis in section 3 indicate the type of difficulties
a context-aware application may typically encounter. A viable context discovery
interoperability mechanism will have to hide these difficulties or, at least, diminish
the burden placed on the context aware application and its developer to overcome
these difficulties.
Summarizing, the problems such an interoperability mechanism has to solve can
roughly be divided into the following categories:
(Un)availability of context discovery mechanisms.
Heterogeneous interaction behaviour and communication mechanisms.
Heterogeneous data syntax and semantics.
In this paper, we mainly focus on the first two aspects and syntactic interoperability.
We acknowledge the importance of having both syntactic and semantic interoperabil-
ity; however, this is out of the scope of this paper and we consider this future work.
The pivotal requirement is the ability for a context discovery interoperability
mechanism to dynamically adapt to different context discovery mechanisms appear-
ing and disappearing. Based on the knowledge of which context discovery mecha-
nisms are currently available, the interoperability mechanism should then change the
way it discovers and retrieves context information on behalf of the applications it
supports. By concentrating the specific functionality of the specific discovery mecha-
nism in individual components that can be loaded and unloaded dynamically, the
interoperability mechanism does not need to support all separate discovery mecha-
nism simultaneously, and at the same time it is able to abstract from the specifics of
individual discovery mechanisms, since this is hidden in the components itself. We
call these environment specific components context discovery adapters (see Figure
2). For storing and retrieving these adapters at run-time, an adapter supplier is de-
fined, which is a repository for discovery adapters. By allowing multiple adapter
suppliers to co-exist (e.g. multiple environments), and not prescribing where these
suppliers should be located (i.e. not restrict a repository to be co-located on the same
host running the context-aware application), specific context discovery environments
may provide their own adapter supplier, without losing the ability to use preferred
adapters present in the co-located repository. The remaining item to be addressed is
the monitoring of the availability of known context discovery mechanisms. Analo-
gous to environment specific adapters, environment specific monitors are defined,
which are responsible for detecting whether a particular context discovery mechanism
is currently (still) available. Adapter suppliers present in a context discovery envi-
ronment also provide these monitors; next to the discovery adapters mentioned ear-
lier. The adapter supplier co-located on the same host as the context aware applica-
tion also provides monitors for a set of predefined context discovery mechanisms.
An adapter supplier thus has the following responsibilities:
79
Provide adapters for the specific context discovery mechanism within its envi-
ronment.
Provide monitors for the same specific context discovery mechanism, which
allow the context discovery interoperability mechanism to detect its availabil-
ity.
The latter responsibility of the adapter supplier also implies that for the first detection
of context discovery mechanisms that can be used with the interoperability mecha-
nism, it is sufficient to detect the presence of an adapter supplier. In order to leverage
this approach, rather than creating a new discovery problem, the method to discover
such a supplier should be standardised.Next to the different components, additional
logic is necessary for the orchestration of the different adapters, monitors, and suppli-
ers. This logic is provided by the Discovery Coordinator.
Fig. 2. High-level design of the proposed Context Discovery Interoperability mechanism.
The proposed discovery interoperability mechanism is part of a more comprehen-
sive effort towards a context binding transparency [11]. This transparency hides the
complexity from the application developer of discovering, selecting, and binding to
context sources, which he requires for his context-aware application. Furthermore, it
maintains the binding with a context source, thereby coping with their dynamic avail-
ability. All these responsibilities are shifted to a middleware layer, coined CACI,
which is co-located with the application. For more information on CACI see [12, 13].
Therefore, we integrated the presented interoperability mechanism with the CACI
middleware. A typical scenario of the use of the discovery interoperability mecha-
nism is as follows (see Figure 2 and 3): on start-up of the application and CACI, the
Discovery Coordinator initiates a discovery of available adapter suppliers (1); this is
done continuously e.g. by passive service discovery. When a supplier is found its
available adapter/monitor combinations are downloaded (2). The monitor is started
(3) to check the availability of the discovery mechanism (4). If it is indeed available,
then the corresponding adapter is registered to the Discovery Coordinator, and passed
on to CACI, which in turn will use the adapter to discover context sources (5 & 6).
The monitor is continuously keeping track of the availability of the discovery mecha-
nism it supports (7). If discovery mechanisms become unavailable, their adapters are
deregistered with the coordinator, and indirectly with CACI. Although the figures
suggest that only one monitor and adapter is active, multiple monitors and adapters
can co-exist at the same time and can become active or inactive during the lifespan of
the application.
80
5 Implementation
Summarising, the architecture contains the following components with their respec-
tive responsibilities:
Context Discovery Adapter: component that translates between a specific con-
text discovery framework and a context-aware application in the form of the
CACI layer.
Monitor: component that keeps track of the availability of a specific context
discovery mechanism.
Adapter Supplier: component that provides the Context Discovery Adapter
and the Monitor to the Discovery Coordinator.
Discovery Coordinator: component that orchestrates the interactions between
the different components.
We made a proof-of-concept implementation of the discovery interoperability mecha-
nism using an implementation of the OSGi component framework specification.
OSGi implementations offer ‘a service-oriented, component-based environment for
developers and offers standardized ways to manage the software lifecycle’ (see
http://www.osgi.org). The open source OSGi implementation ‘Oscar’ was used as the
basic implementation platform (http://oscar.objectweb.org). However, the prototype
is also tested on the Knopflerfish OSGi (http://www.knopflerfish.org) implementa-
tion. For communication and discovery mechanisms the middleware of the IST
Amigo project (http://www.amigo-project.org) was used, which amongst other things,
provides components for easy Web Service communication (for both server and client
side) and Web Services Dynamic Discovery (WS-Discovery), which uses multicast to
discover web services of specific type and scope in the network. More specifically,
the WS-Discovery mechanism, available from the Amigo project, was used as the
‘standard’ discovery mechanism for finding adapter suppliers. Every component in
the architecture was implemented as a separate OSGi bundle (the OSGi name for a
component), which has the added benefit that the bundle id can be used for identify-
ing component instances. The OSGi framework is service-oriented and also deploys
the concept of service listeners, which means that components can register themselves
as being interested in services of a specific type. If a component that offers a specific
type of service is installed and activated, all interested service listeners will be in-
formed of that event. In the prototype implementation the service listener pattern is
used by CACI to get notified whenever new Context Discovery Adapters become
active after being downloaded by the discovery coordinator. A sequence diagram (see
Figure 3) will help to derive the detailed functions of the different components and
their respective interfaces. In the text below, italic text in brackets will indicate the
interface name that is relevant for the mentioned interaction. In order to be discover-
able by a Discovery Coordinator, an Adapter Supplier registers itself with a scope of
‘urn:CADC’ and a service type of ‘IAdapterSupplier’. After an adapter supplier is
discovered, the Discovery Coordinator needs to retrieve the list of components pro-
vided by the adapter supplier (IAdapterSupplier), typically consisting of one Monitor
and one or more Context Discovery Adapters. The Discovery Coordinator will
download (using OSGi’s component downloading capabilities via http or file system)
the components returned by the Adapter Supplier and start the Monitor by activating
81
the Monitor component. If the Monitor successfully detects the context discovery
mechanism supported by the adapters, it will start the adapter(s) and indicate the
availability of the context discovery mechanism to the Discovery Coordinator (IDis-
coveryCoordinator). The CACI framework will be notified of this since the started
adapters provide a specific service, for which CACI has registered as a service lis-
tener. CACI will call the Context Discovery Adapters for performing Context Source
Discovery (IDicoveryAdapter). The Monitor will keep checking the availability of its
Context Discovery Mechanism. If it becomes unavailable, the Monitor will inform
the Discovery Coordinator (IDiscoveryCoordinator) by deregistering and stopping
the relevant adapters. Since stopping the adapters automatically means that the OSGi
service they are offering disappears, CACI (as a service listener) will be notified of
this event by the OSGi framework. Next to the Monitor, the Discovery Coordinator
will continuously check for the availability of the Adapter Supplier via a straightfor-
ward heartbeat mechanism; essentially a dummy method call on the Adapter Supplier
(IAdapterSupplier). If the supplier becomes unavailable, the coordinator will respond
by stopping the Monitor belonging to the supplier that disappeared (IMonitor).
Fig. 3. Time-sequence of a scenario of loading and unloading of a context discovery adapter.
The following code snippets give interface definitions in pseudo-code of the
different described components. These where already referred to in the text above.
IAdapterSupplier
String heartBeat(void)
Adapter[] listAdapters(void)
URL getAdapterReference(adapterID)
IDiscoveryAdapter
String getFriendlyName(void)
[] discoverContextProducers(request)
IMonitor
String getFriendlyName(void)
Long getComponentID(void)
IDiscoveryCoordinator
newMonitor(IMonitor)
monitorGone(IMonitor)
frameworkAvailable(IMonitor)
frameworkGone(IMonitor)
82
Implementations of the Adapter and Monitor components were made for the CCS,
CMS, [3], and SimuContext [14] context management frameworks. They are cur-
rently being evaluated. For supporting other discovery mechanisms than the ones
already implemented for the prototype, new Monitors and Adapters have to be devel-
oped. Since a large part of the functionality of the Monitor is equal for every type of
context discovery mechanism, a new one can be implemented by deriving from the
reference monitor component and implementing the template parts for the specific
needs of the targeted context discovery mechanism. The specific Context Discovery
Adapters are less generic than the Monitor, and should at least implement the IDis-
coveryAdapter interface. The Discovery Coordinator and Adapter Supplier are ge-
neric and do not have to be (re-) implemented for new context discovery mechanisms,
although the Adapter Supplier will have to be configured with the appropriate infor-
mation for the context discovery mechanism it has to support (i.e. URLs of monitor
and adapters).
6 Conclusions
This paper discusses work in progress towards a context discovery and delivery inter-
operability mechanism. In this paper, we focus mainly on the interoperability of con-
text discovery mechanisms. By using the context discovery interoperability mecha-
nism, application developers are relieved from programming mechanisms in their
application to interoperate with different context discovery mechanisms that can ap-
pear and disappear at arbitrary moments during the life-span of the application. The
mechanism actively searches for context discovery mechanisms and when found adds
them to the scope of the interoperability mechanism by downloading discovery adapt-
ers made available by the discovery mechanisms. Furthermore, it continuously moni-
tors the availability of discovery mechanisms and if one disappears, it removes the
adapter from the interoperability mechanism. However, we acknowledge some as-
pects that are not addressed in this paper and which we consider possible future re-
search:
Interoperable context delivery: this paper focuses on the first step of the con-
text discovery and delivery process, namely context (source) discovery. After
context discovery, the actual context has to be transferred from the context
source to the application, which poses a similar interoperability issue. The
chosen dynamic adapter-based approach is designed for both discovery and
delivery of context. However, in this paper the approach is only detailed for
interoperating context discovery mechanisms. Therefore, we plan to further
extend this mechanism with context delivery interoperability.
Security: downloading ‘unknown’ code is considered a security risk. How-
ever, mechanisms exist to overcome this issue, such as code signing and fire-
walling [15].
Semantic interoperability: in this paper, we focus on functional interoperabil-
ity. However, interoperating the different data models used by the context dis-
covery mechanisms is similarly important. Mechanisms exist to get semantic
83
interoperability, which could be used to extend the current mechanism (e.g.
ontologies [16]).
84
References
1. Dey, A., Providing Architectural Support for Context-Aware applications. 2000, Georgia
Institute of Technology.
2. Henricksen, K., et al., Middleware for Distributed Context-Aware Systems, in DOA 2005.
2005, Springer Verlag: Agia Napa, Cyprus.
3. Benz, H., et al., Context Discovery and Exchange, in Freeband AWARENESS Dn2.1, P.
Pawar and J. Brok, Editors. Freeband AWARENESS Dn2.1, 2006.
4. Bardram, J., The Java Context Awareness Framework (JCAF) - A Service Infrastructure
and Programming Framework for Context-Aware Applications, in Pervasive Computing.
2005: Munchen, Germany.
5. Dey, A., The Context Toolkit: Aiding the Development of Context-Aware Applications, in
Workshop on Software Engineering for Wearable and Pervasive Computing. 2000: Limer-
ick, Ireland.
6. Hesselman, C., et al. Interoperating Context Managment Systems for Pervasive Computing
Environments. in forthcomming. 2007.
7. Ramparany, F., et al. An Open Context Management Information Management Infrastruc-
ture. in Intelligent Environments (IE'07). 2007. Ulm, Germany.
8. Chen, G. and D. Kotz. Solar: An open platform for context-aware mobile applications. in
International Conference on Pervasive Computing. 2002. Zurich, Zwitserland.
9. Buchholz, T., A. Kupper, and M. Schiffers. Quality of Context: What it is and why we
need it. in 10th Workshop of the HP OpenView University Association (HPOVUA03).
2003. Geneva, Switzerland.
10. Sheikh, K., M. Wegdam, and M.v. Sinderen. Middleware Support for Quality of Context in
Pervasive Context-Aware Systems. in IEEE International Workshop on Middleware Sup-
port for Pervasive Computing (PerWare'07). 2007. New York, USA.
11. Broens, T., D. Quartel, and M.v. Sinderen. Towards a Context Binding Transparency. in
13th EUNICE Open European Summer School. 2007. Enschede, the Netherlands: Springer.
12. Broens, T., et al., Dynamic Context Bindings in Pervasive Middleware, in Middleware
Support for Pervasive Computing Workshop (PerWare'07). 2007: White Plains, USA.
13. Broens, T., A. Halteren, and M.v. Sinderen. Infrastructural Support for Dynamic Context
Bindings. in 1st European Conference on Smart Sensing and Context (EuroSSc'06). 2006.
Enschede, the Netherlands.
14. Broens, T. and A. van Halteren. SimuContext: simulating context sources for context-aware
applications. in Intl. Conference on Networking and Services (ICNS06). 2006. Silicon Val-
ley, USA.
15. Rubin, A.D. and D.E. Geer, Jr., Mobile Code Security. IEEE Internet Computing, 1998.
2(6): p. 30-34.
16. Blackstock, M., R. Lea, and C. Krasic. Towards Wide Area Interaction with Ubiquitous
Computing Environments. in 1st European Conference on Smart Sensing and Context (Eu-
roSSc'06). 2006. Enschede, the Netherlands.
85