Extending the Java Context Awareness Framework for Android

sizzledgooseSoftware and s/w Development

Nov 3, 2013 (3 years and 8 months ago)

163 views

Extending the Java Context Awareness Framework for
Android
K´aroly Sz´ant´o
IT University of Copenhagen
Rued Langgaards Vej,Copenhagen S,DK 2300
ksza@itu.dk
(140785)
ABSTRACT
Context-aware computing is central to mobile devices.A
programming framework must allowinteraction of these de-
vice in a volatile environment using platform-independent
communication mechanisms.In our work we extend the
Java Context Awareness Framework (JCAF),to support
the development of context-aware applications on the An-
droid platform.We present an alternative implementation
of JCAF’s RMI based communication,using RESTful web
services.We also describe a RESTful API which supports
interoperability with the Android platform.We evaluate the
extended framework by building a context-aware Android
application based on JCAF.The evaluation showed that the
extended JCAF provides a reliable,intuitive and easy to use
programming framework for the Android platform.
Author Keywords
Context-awareness,ubiquitous computing,web services,
RESTful,RMI,mobile,Android
1.INTRODUCTION
As the digital world started to embrace more and more
Weiser’s vision [
18
],ubiquitous environments have been
emerging rapidly,computers being seamlessly integrated
into our everyday life.
One of the key concepts developers have to rely on when
trying to achieve ubiquity,is context-awareness.The con-
cept of context-aware computing and the definition of con-
text were introduced in the world of ubiqitous computing
1
in 1994 by Schilit [
5
].Dey and Abow in [
9
] refine the con-
cept who consider the context being the location,identity
and state of people,groups and computational and physical
objects.
Context-Aware applications make use of the context infor-
mation to adapt to specific situations and take specific ac-
1
UbiComp;also referred to as pervasive computing
Paper submitted for evaluation in the Pervasive Computing Course,Fall
2010.The IT University of Copenhagen.
tions.For example,a context-aware phone book on a mo-
bile phone would attach an indicator to a contact that has
its phone on silent mode.Thus suggesting the contact
does not want to be disturbed.In order to achieve such
a context-aware behavior,a developer must model entities,
their context information and relations between them.This
can be easily carried out using a programming framework
for context-aware applications.Such a framework needs to
provide means for the developer to model context as well as
to provide mechanisms for context aquisition and manage-
ment.
The Java Context Awareness Framework is a framework ad-
dressing the above mentioned needs.The purpose of JCAF
is to create an extensible framework in order to help in devel-
oping context-aware applications [
7
].The ContextService is
the key point of JCAF knowing about the entities,their con-
text items and the relations between them.Monitors,Clients
and Actuators are connected to the context service modify-
ing the context information or awaiting context changes to
take proper actions.All these components can run on differ-
ent machines communicating in a distributed manner.From
a UbiComp perspective there are,however,two main prob-
lems in the current implementation:
1.
The first one is the distribution mechanism’s implementa-
tion which is based on Java Remote Method Invocation
(RMI) application programming interface (API).Using
RMI as the cornerstone of the interoperation mechanism
does not represent only the impossibility to communicate
with components running on the Android platformbut,as
discussed in [
17
],it is considered harmful for ubiquitous
systems.In these highly volatile systems,software com-
ponents must be able to interoperate with one another as
entities move,fail or spontaneously appear.An implicit
assumption underlying RMI is that interoperating compo-
nents are designed to work together in a specific system
or application and that changes to the set of interoperat-
ing components is less probable.These assumptions are
invalid in UbiComp systems [
4
].
2.
The second problem is that JCAF currently runs only on
the Java standard SDK(J2SE).Limiting JCAF to run only
on a personal computer and by forcing the communication
to happen only between personal computers is a serious
drawback.Valuable context information could be gath-
ered,for example,from mobile devices.They represent
a great pervasive computational platformhaving access to
1
location information (GPS),different types of connectiv-
ity (Bluetooth,infrared,WiFi),personal information of
the user and they are most of the time on.
In our work we address the above described problems by
extending JCAF to run on the Android platform.A ma-
jor challenge is caused by the different serialization mech-
anisms employed by the Java virtual machine (VM) and the
VMin Android,Dalvik,which result in no RMI support in
Android.Therefore,we have to address the communication
problemfirst.
An example of a systemthat successfully achieved a high de-
gree of interoperability,through a fixed interface,is the Web
[
4
].In [
15
] the authors manage to point out the fast growth
of the Web towards an ubiquitous environment.They pro-
pose an architectural style for this distributed,volatile envi-
ronment:the REpresentational State Transfer (REST).It is
a set of principles that,when correctly applied,help build-
ing software architectures and applications that benefit from
all the qualities of the Web.Those qualities include greater
scalability,efficient network usage and independent evolu-
tion of clients and servers – also called loose coupling.This
led us to adopt the REST architectural style and integrate it
in JCAF’s interoperation mechanism.The entities used to
communicate over REST are represented in the Extensible
Markup Language (XML) encoding.This design choice en-
sures loose coupling and a reliable communication between
components,making JCAF easily extensible and opened for
communication even with components written in other pro-
gramming languages.
We demonstrate this work with an Android application writ-
ten on top of the extended framework,reusing the idea of
the ContextContacs presented in [
16
] as an application built
upon the ContextPhone prototyping platform.The appli-
cation lets users automatically represent and exchange con-
text information.For example,the application will not au-
tomatically block incoming calls for a device which is in
silent mode,rather it notifies the devices aware of its con-
text,which will display a relevant icon on the contact’s entry
in the phone book.
Section
2
briefly describes the projects and papers address-
ing the same issues as we do.Section
3
presents the distribu-
tion mechanism implemented as RESTful web services and
section
4
describes the current implementation status and fu-
ture work.Section
5
presents how we tested and evaluated
our work.In section
6
we carry out a discussion about what
worked,what can be improved and what we have learned
fromthis research.Finally,section
7
concludes the paper.
2.RELATED WORK
Throughout the years the UbiComp research community
continuously tackled the subject of supporting the develop-
ment of context-aware applications.Their research resulted
in frameworks and middlewares satisfying requirements of
a context-aware system,as discussed in [
9
] [
8
].A survey
of existing context-aware frameworks and middlewares was
carried out in [
6
] [
19
].
In [
17
] the authors discussed in detail the harmful effects of
using RPC and RMI in UbiComp systems.Their work is the
closest to our solution for the first problem.They propose
an event-based architecture supporting features like generic
interfaces for event registration,conditional notification of
events,QoS
2
support for event delivery and mobility support
for event notification.JCAF already embodies a general-
purpose,event-based architecture which we have extended
with the ability to register and notify remote event listers.In
our design we have adopted the first two features and came
up with conceptual solutions for the latter ones,which will
remain an open issue for future work.
We would like to mention Hewlett-Packard’s CoolTown
project [
14
] which offers a web model for supporting no-
madic users,based on the convergence of web technology,
wireless networks and portable devices.In the design they
interconnect physical objects and places with laptops,mo-
bile devices,virtual resources etc.Each entity in the sys-
tem is represented as a web resource identified by an URL.
The communication mechanism is based on XML encoded
messages over HTTP.This work introduces the vision of
web presence
3
for any element that a context-aware system
should be aware of,even physical ones.We have partially
adopted the idea of web presence for the Android phones in-
teracting with our system.But in the current implementation
the mobile devices are reachable only in a WLAN.The idea
of continuous availability remains an open issue,being a hot
research subject.
The Context Toolkit [
9
] provides a programmatic support for
the development of context-aware applications,incorporates
various services related to the gathering and supply of con-
text,including an encapsulation of context,access to context
data,context storage,and a distributed infrastructure.It has
a simple object communication mechanism based on HTTP
and XML encoding of messages,supporting a wide range
of devices,including mobile devices.Although the Context
Toolkit addresses both issues described in the introduction,
it has some fundamental differences fromour work:

it is distributed on a very low level of details and there
is no way of collecting related context data and services
into logical bundles.The disadvantage of multi-casting
context information around is increasing computation and
communication thereby paying a scalability penalty [
7
]

it offers support with interaction with mobile device but it
does not have a concrete implementation for Android.
PACE
4
presented in [
12
] by Henricksen and Induska,aims
at facilitating the development of context-aware applications
provision generally required programming functionality like
context gathering,context management,and context dissem-
ination.The context management systemwas written in Java
and consists of a distributed set of context repositories which
offer RMI interfaces for interoperability.In addition to in-
2
Quality of Service
3
The representation of entities on the web
4
The Pervasive,Autonomic,Context-aware Environment
2
voking methods on repositories using Java RMI,clients can
also use a Web interface based on XML and HTTP.This
might seemclose to our solution but the loosely coupled in-
teraction through Web interfaces is possible only with the
context management system,the programming toolkit using
RMI for communication with remote components.There-
fore there is no development support for mobile devices.
Hydrogen [
13
] is a framework based on a layered archi-
tecture,with a context acquisition mechanism specialized
for mobile devices.Except JCAF,and the majority of dis-
tributed context-aware systems,it tries to avoid the existence
of a centralized component,exchanging context information
with other devices in a peer-to-peer manner through WLAN,
Bluetooth,etc.Not having a centralized server it has the in-
capacity of storing a vast amount of context history.The
communication is based on an XML over TCP/IP.Although
this approach offers heterogeneity,all communication issues
like opening a port,sending data and listening on ports to
receive answers must be handled by the application itself.
They partially overcome this drawback by offering a Con-
textClient abstraction for the supported programming lan-
guages (J2ME),which provides the above mentioned com-
munication functionality.
The Service-oriented Context-Aware Middleware (SOCAM)
project [
10
] [
11
] is an architecture for building and rapid
prototyping of context-aware mobile services.It is built
on top of Open Service Gateway Initiative (OSGi)
5
offer-
ing a service-oriented approach which supports context ac-
quisition,interpretation,discovery and dissemination.The
frameworks main feature is its support for context reasoning
through which high-level implicit contexts can be derived
fromlow-level explicit contexts.Contexts are represented as
predicates written in Web Ontology Language (OWL) which
makes it flexible.Context interpreter acquires context data
from distributed Context Providers and offers it to clients,
the various distributed components communicating through
Java RMI.The approach presented in this work uses seman-
tic representation to model context making it more expres-
sive and more general than many other approaches.The
communication mechanism between components is based
on RMI,making SOCAM hardly extensible for communi-
cation with other platforms.
The drawback of SOCAMis the communication mechanism
between distributed components,as earlier discussed in this
work,which is not addressed at all.
Even though many of the related context-awareness
frameworks adopted a flexible communication mechanism
through HTTP,only a few offer support for development
and deployment on mobile devices,and none of them has
implemented explicit support for the Android platform.In
our work we have implemented a communication mecha-
nism based on RESTful web services and development and
deployment support for the Android platform.Moreover,
we have the possibility to generate development support for
JCAF context clients also for other platforms.
5
www.osgi.org
3.RESTFUL JCAF
In this section we will describe the architectural decision and
design considerations we made in order to allowJCAF com-
ponents to communicate via RESTful web services.We will
also cover some implementation details.
3.1 Background
RESTis an architecture style for distributed hypermedia sys-
tems.Aweb service is an API which is accessed through the
HyperText Transfer Protocol (HTTP) and executed on a re-
mote system,hosting the requested service.A RESTful web
service is a web service implemented using HTTP and the
principles of REST.The RESTful web service is defined by
a collection of resource,each of which is defined by three
main characteristics:

the base URI identifying the web service

the MIME
6
type of the data supported by the web service
(JSON,XML,etc.)

the web service’s interface defined against the HTTP sup-
ported methods like POST,GET,PUT,DELETE etc.
The REST architectural style imposes a client-server archi-
tecture,which fits well JCAF’s architecture,which is also
based on a client-server approach.
3.2 The Framework
As a first step towards implementing the RESTful extension
of JCAF,we decided to build upon a REST framework for
Java,which makes it easy for us to build RESTful web ser-
vices.We took into consideration the following frameworks:
Restlet
7
and Jersey
8
.We have decided upon Restlet because
of its explicit support for Android.
We have gained technical background about the Restlet
framework from[
15
] and the project’s documentation repos-
itory [
1
].Some of the main features of Restlet are:

suitable for both client-side and server-side web applica-
tions,using the same API

it has many editions supporting development for J2SE,
J2EE,GWT
9
,GAE
10
and Android

representation of resources,through extensions,in many
formats like XML,JSON etc.

extensive and flexible security support (authentication and
authorization)
The complete list of features can be found at [
2
].
6
Multipurpose Internet Mail Extensions
7
http://www.restlet.org/
8
http://wikis.sun.com/display/Jersey/Main
9
Google Web Toolkit
10
Google AppEngine cloud computing platform
3
3.3 RESTful extension for JCAF
As in the current implementation the ContextService API is
defined with references to RMI classes we decided,for this
version,not to base our implementation on this interface.
Rather,we defined a new API with operations similar to the
ContextService.The architecture of the RESTful communi-
cation is illustrated in Figure
1
.
Figure 1.
Architecture of the RESTful API.a - Anatomy of the server
side Restlet application.b - Anatomy of the REST client and interac-
tion with the RESTful ContextService API.
3.3.1 The Server
It is based on a Restlet application (restlet app.) imple-
mented according to the newly defined interface.It acts as
a facade in respect to the existing implementation of Con-
textService.The main responsibilities of the restlet app.are:

define routings from URIs to web services,which will
handle the requests

handle client listener notifications

start the web server.
After the current ContextService service is started,an in-
stance of the restlet app.is created with a reference to the
already running server (reference server).The web services
will intercept the client request and execute them against
the reference server,reusing the already implemented func-
tionality.Table
1
depicts the mapped resource for each
URI path,which are expressed relatively to the root path
http://address:8185.Although the client interacts with the
server throughout a Java interface,we have to mention that
in some cases the URIs or the handling resources names are
not very suggestive.They will be refined as development is
continued.
Relative URI path Mapped Resource
/entities
all
ids AllEntityIdsResource
/entities
all AllEntitiesResource
/entities
context
items/fentityIDg EntitiesContextItemsResource
/entity/fentityIDg EntityResource
/listener/entity AddEntityListenerResource
/remove/entity/listener RemoveEntityListenerResource
/context ContextResource
Table 1.
Routings fromURIs to resources.
All the resources extend the BaseResource abstraction,de-
rived fromServerResource defined in the Restlet framework,
which gives access to the underlying restlet app.,the ref.ser-
vice and a factory for creating encoding/decoding strate-
gies.The serialization mechanism will be described later
in this section.Each resource can define operations of the
REST API either by annotating methods with restlet annota-
tions (@GET,@POST,@PUT or @DELETE),or by over-
riding one of the inherited methods.
The server also acts as a listener manager.Therefore,the
AddEntityListenerResource delegates the add listener task
to the rest app.which creates a local listener,with the spec-
ified preferences,for each request,and maps it to the clients
address.When the local listener is notified,the notification
is forwarded to the mapped REST client using a POST re-
quest.
3.3.2 The Client
It is represented by RestContextClient,which is also a rest
app.,holding a reference to the RestClientContextService.
Calls to the rest context service are mapped to requests to
the server.This process is not visible to the developer.As
we said before,the REST context service API defines only
part of ContextService’s functionality,the client being able
to performthe following operations:

add/get/remove entity

add/remove entity listener

add a context itemto a specific entity (specified by its ID)

get all entity IDs

get all entities

get the context items of an entity (specified by its ID).
The client rest app.starts a web server which
defines a web service,for listener callback,on
”http://address:8186/entity/fIDg”.The requests are
handled by the EntityListenerCallbackResource.
RestEntityListener represents the absctraction for an entity
listener.It contains a reference to an EntityListenerInfo and
defines a contextChanged() abstract method.When a client
wants to add a listener it has to create an entity listener info
which specifies its current address and the type of listener
(listen for a specific entity,specified by ID,or for a whole
class of entities,specified by class type).This is registered
with the local client context service which assigns a unique
ID to the listener info.Only the EntityListenerInfo is trans-
mitted to the server,because the callback will occur as a
POST request to the web service running on the client.The
diagram in Figure
2
depicts the notification process for an
entity listener.We will discuss and propose a solution for
the drawbacks of this design.
4
::RestClientContextService
::ContextServiceWebServer
::ContextService
::Client
addEntityListener(listener)
assignUniqueID
POST entityListenerInfo
create local listener
add local entity listener
contextChanged
notify local listener
POST context event
get listener for ID
notify listener
Figure 2.
Interaction diagram for RESTful listener registration and
notification.
3.3.3 Serialization
Restlet represents all the resources as a Representation ab-
straction,offering specialized representations as extensions
libraries:JSON,XML,etc.We have decided to serialize all
our data into XML representation using the XStream tech-
nology [
3
].For future development we consider extending
the supported representations.
4.IMPLEMENTATION AND ONGOING WORK
We have built upon JCAF version 1.5,implemented using
J2SE 1.4,without altering any of the source classes
11
.Our
work extended the remote communication with a RESTful
API,which is in version 1.0 and is implemented using J2SE
1.6 and the Restlet framework.In order for clients to com-
municate with the server they have to know the server’s ad-
dress.The RESTful interface supports only part of the Con-
textService API,but it proved to be helpful and developer
can rely on it,as demonstrated in section
5
.The fact that
we could not use the ContextService interface as abstraction
for the RESTful communication indicates a design flaw in
JCAF’s initial design.In our future work the first step will be
to investigate this flaw.The goal is to have interfaces which
are not dependent on any concrete implementations leaving
an open space for extensions.This way we will be able to
use the same interface for both RMI and RESTful commu-
nication.Once we achieve this generalization we will finish
implementing the rest of the operations for RESTful com-
munication.
All the restlet references are coded against the J2SE restlet
library,but at build time we generate separate deployments:
one for J2SE and one for Android.When we compile the
project for Android,we compile the client code against the
android restlet library.If required,we could deploy JCAF
libraries for all the platforms restlet has support for (GAE,
GWT,Google AppEngine and J2EE) by simply compiling
the client code against the proper restlet edition.
In JCAF there are some abstraction meant to ease the de-
velopment by offering some basic functionality,like Gener-
icEntity and AbstractContextItem.We could not use themas
11
The code for the new communication mechanism is in the
dk.pervasive.java.rest package
abstractions for the RESTful communication because they
have references to RMI classes,therefore we had to imple-
ment new abstractions,resulting in parallel hierarchies,as
shown in Figure
3
.We had to take this measure because,in
Android,trying to load a class which has references to un-
supported types (e.g.RMI classes) will fail the verify step
and will not be loaded.
«interface»
Entity
GenericEntity
GenericRestEntity
Person
Place
RestPerson
RestPlace
«interface»
ContextItem
AbstractContextItem
AbstractRestContextItem
Location
RestLocation
Figure 3.
Paralel hierarchies of the Entity and ContextIteminterfaces.
Security is implemented in JCAF using an authentication
mechanism based on a digital signature using the Java Au-
thentication and Authorization Service (JAAS),which is a
part of J2SE,and it is used only for context clients.We have
not implemented any security in the current version of the
RESTful communication but the restlet framework offers a
JAAS extension.We intend to use this extension to imple-
ment the security mechanism as it is implemented for the
RMI communication.
Another issue we ran into is the dynamic class loading.We
need this feature on the server side so that modeled entities,
relationships and items can be loaded at runtime,without
the need of restarting the context service.For J2SE RESTful
clients we have successfully solved this problem employing
the static file serving feature of the Restlet framework.This
means that on the client side we have an HTTP server which
makes accessible either a directory or a jar file containing
the classes,which are loaded by the context service using
a URLClassLoader.For Android this solution is not appli-
cable because the Dalvik virtual machine does not use Java
bytecode,therefore the classes are not compatible with,and
cannot be loaded at runtime by,the standard Java VM.At
the moment,modeled elements have to be deployed on both
the server and client side.More than that,the classes have
to be present before starting up the context service and must
be specified in its classpath.
5
5.EVALUATION
We have decided to evaluate our programming framework
by implementing a context- aware application on the An-
droid platformusing the extended JCAF framework.For this
purpose we have chosen,as a model,the ContextContacts
application which was implemented on top of the Context-
Phone prototyping platform [
16
].This project is meant to
be a proof-of-concept application demonstrating that JCAF’s
RESTful programming model is useful and easy to use.
Therefore,we will discuss only issues regarding the inter-
action with JCAF,anything else being outside the scope of
our research.
5.1 The ContextContacts Application
The application helps users share context information,like
current audio profile,user engaged or not in a call and lo-
cation.When changes in the context of a user occur,the
users interested in the changes will receive context updates.
They are interpreted and hints are given based on the current
context (e.g.if the user tries to contact another user that has
its device on silent,the ContextContact will suggest to send
him a message,because the context information show the
user does not want to be disturbed),but the decision is left
up to the user.
Figure 4.
The ContextContacts user interface.
Figure
4
shows the user interface of the ContextContacts ap-
plication.It displays all the contacts in the phone,as en-
tries in a list,augumenting them with available context in-
formation.The layout is modeled after the standard phone
book in Android,helping the user to faster familiarize with
the application.First,we display a photo of the contact,if
available,and right next to it we place the name and phone
number.Bellow the photo we place the context information
illustrated as icons,each with a unique meanining:
no context information available
context information is available for the contact
normal audio profile
silent audio profile
silent audio profile (with vibration enabled)
contact is currently engaged in a call
location information
Ashort press on one of the contact entries will issue a call to
the selected contact.A long press on a contact will bring up
a list of actions based on the available context information.
For a contact with no context information,a N/A (Not Appli-
cable) message is displayed (Figure
5(a)
).If the user tries to
execute an action on a contact that has a silent audio profile
two ordered actions will be displayed:message,call (Figure
5(b)
),thus suggesting not to disturb the contact.Otherwise,
if an action is triggered on a contact that has a normal audio
profile,the first option will be call (Figure
5(c)
).
(a)
(b)
(c)
Figure 5.
Different actions based on available context information.
5.2 Implementation using JCAF
We have modeled the phone as a ContextPhoneEntity which
can be in a PhoneStatusChanged relationship with a Phon-
eStatusItem context item.An overview of the modeled ele-
ments and the relation between themis depicted in Figure
6
.
All these elements had to be deployed together with both the
framework and the client.
GenericRestEntity
ContextPhoneEntity
AbstractRestContextItem
PhoneStatusItem
Context
1 1
«interface»
Relationship
1 *
1 1
PhoneStatusChanged
Figure 6.
Class diagramfor Entities,Relationships and ContextItems.
When the application starts up,creates a ContextPhoneEn-
tity instance,representing the device its running on,and adds
6
it to the ContextService.It also creates and entity listener
to listen for context changes on ContextPhoneEntities.We
gather context information from using services offered by
the Android platform,changing the entities context accord-
ingly.Whenever a ContextEvent notification is received,
context information is updated,giving the user an easily un-
derstandable feedback.In listing
1
we have depicted a code
snippet demonstrating howcontext information can be man-
aged using the RestClientContextService API.
mBoundService.addEntity(new ContextPhoneEntity(
identity,"contact_name",identity));
mBoundService.addContextItem(identity,
new PhoneStatusChange(),
new PhoneStatusItem(
identity +"_initial_status",
myDeviceStatus
));
Listing 1.Context management using JCAF.
ContextPhoneEntity,PhoneStatusChange and PhoneSta-
tusItem are custom classes defined while implementing the
ContextContacts application.The first one models a context
entity,the second one a relation and the latter one a context
item.In this code listing we show how the device is added
to the ContextService as a context item and how we can as-
sociate a context items to it using a relation.We have found
the modeling of entities and context management intuitive
and easy to use.Also,the operations in the context client
hide the implementation details from the developer,making
communication with the context server as easy as calling a
method.
6.DISCUSSIONS
Building our RESTful communication mechanismon top of
the Restlet framework proved to be a good choice in many
aspects:ease of creating web services and handling requests
in an object-oriented manner,ability to support development
of context clients on many platforms based on the same
code,ease of extending the supported features (e.g.secu-
rity) using the framework’s extensions and the possibility to
offer support for a big variety of encodings for the messages
used for communication.One drawback is that the Rest-
let framework is poorly documented and,although we have
managed to get the necessary technical background in order
to get started,we feel the need of future development.This
is due to the fact that in the development process we have
encountered exceptions and flaws we could not identify,be-
ing forced to take some poor design decisions in some situa-
tions.For example,in a situation when a substantial number
of requests were issued to the server,the number of threads
handling requests rapidly grewover the limit,resulting in the
server refusing other requests.We have found a workaround
for this problemby increasing the number of simultaneously
allowed connections to 512.We are not satisfied with this
solution because the requests are handled rapidly and the
server should be able to carry out all of them.
While implementing the ContextContacts application all the
features implemented in JCAF worked,finding it intuitive
and easy to manage context entities,relations and items.
However,we have encountered a couple of limitations.One
of them was that not all the JCAF’s features were given a
RESTful implementation.For example,our RESTful client
on the Android platform can retrieve only a list of all the
context items a specific entity is in relation with,while we
only need items that are in a specific relation with the entity.
This issue will be solved once all the features of JCAF will
be available in the RESTful API.
Asecond limitations was encountered in the listener mecha-
nism.In order for the ContextService to be able to notify the
client of changes,the server must be aware the client’s ad-
dress.Thus,the event management,in the current version,
is guaranteed only in a WLAN.An obvious problem with
the listener mechanism is that the mobile device’s address
changes frequently.In the WLAN environment,this prob-
lem can be solved by notifying the server that the devices
address changed,updating the callback information.In our
future work we want to support event notification for devices
without the need of knowing their addresses.In our opinion,
this can be achieved by implementing the event management
mechanism based on event polling – instead of giving the
server the responsibility to callback the client for an event
occurrence,the client will have the responsibility of asking
the server for event occurrences.This way the client device
will not have to run a web server anymore.In Figure
7
a
conceptual sequence diagramfor our solution.When a client
wants to register a listener,the server create a unique IDand
an event queues for the client.The client can than ask the
server for events based on its associated ID.This solution
would introduce the latency problem (the notifications are
not delivered the moment they event has occurred),but we
consider it is a more reliable solution and it is not dependent
on the clients frequently changing address.
::ContextServiceWebServer
::Client
::RestClientContextService
registerListener
POST create listener request
create unique listenerID
assign event queue to ID
respond with listenerID
GET events for listenerID
respond with ContextEvents[]
notify with occured events
map ID to client
poll events at given periods of time
Figure 7.
Interaction diagramfor proposed RESTful listener manage-
ment mechanism.
7.CONCLUSIONS
Context-awareness is a key concept in ubiquitous computing
and the need for frameworks to help carrying out the tasks
of context-management is imminent.Moreover,the volatile
7
nature of UbiComp systems and the variety of interacting
devices arise the need for flexible communication mecha-
nisms and programming support for context-management on
a multitude of platforms.In this paper we have presented
solutions for two problems identified in the Java Context-
Awareness Framework:a rigid communication mechanism
based on Java RMI and no programming support for other
platforms than J2SE.We have described in detail the ar-
chitectural decisions,design considerations and the imple-
mentation.The extended version of JCAF was evaluated by
extending it on the Android platform,in order to create a
context-aware application.
In section
5
we have demonstrated that JCAF is easily ex-
tensible and usable on the Android platform,helping de-
velopers easily and intuitively carrying out the tasks of
context-management.Downloadable releases of JCAF,in-
cluding demo applications,are available at
https://
sourceforge.net/projects/jcaf
.
REFERENCES
1.
http:
//www.restlet.org/documentation/
.
2.
http:
//www.restlet.org/about/features
.
3.
http://xstream.codehaus.org/
.
4.
Distributed Systems Concepts and Design.Addison
Wesley,2005.
5.
Schilit B.,Adams N.,and Want R.Context-aware
computing applications.First Workshop on Mobile
Computing Systems and Applications (WMCSA),1994.
6.
Matthias Baldauf and SchahramDustdar.A survey on
context-aware systems.International Journal of AD
HOC and Ubiquitous Computing,2004.
7.
Jakob E.Bardram.The java context awareness
framework (jcaf) a service infrastructure and
programming framework for context-aware
applications.Lecture Notes in Computer Science,2005.
8.
Ricardo Couto A.da Rocha,Markus Endler,and
Thiago Senador de Siqueira.Middleware for ubiquitous
context-awareness.2008.
9.
Anind K.Dey and Gregory D.Abowd.A conceptual
framework and a toolkit for supporting the rapid
prototyping of context-aware applications.2001.
10.
Gu,Pung,and Zhang.Toward an osgi-based
infrastructure for context-aware applications.IEEE
Pervasive Computing,2004.
11.
Tao Gu,Hung Keng Pung,and Da Qing Zhang.A
middleware for building context-aware mobile services.
Vehicular Technology Conference,2004.
12.
Karen Henricksen,Jadwiga Indulska,Ted McFadden,
and Sasitharan Balasubramaniam.Middleware for
distributed context-aware systems,2005.
13.
Thomas Hofer,Mario Pichler,Gerhard
Leonhartsberger,Josef Altmann,and Werner
Retschitzegger.Context-awareness on mobile devices
the hydrogen approach,2002.
14.
TimKindberg and John Barton.A web-based nomadic
computing system,2000.
15.
Jerome Louvel,Thiery Boileau,and Philippe Mougin.
Rethinking web development with rest and restlet.
Green Paper from Restlet in Action,pages 76–107,
2010.
16.
Mika Raento,Antti Oulasvirta,Renaud Petit,and
Hannu Toivonen.Contextphone:a prototyping
platformfor context-aware mobile applications.IEEE
Pervasive Computing,2005.
17.
Saif U.and Greaves D.J.Communication primitives for
ubiquitous systems or rpc considered harmful.In 21st
International Conference on Distributed Computing
Systems Workshops,2001.
18.
Mark Weiser.The computer for the 21th century.
Scientific American,1991.
19.
Alexander Zimmermann.Context Management and
Personalisation:A Tool Suite for Context- and
User-Aware Computing.PhD thesis,Aachen
University,2007.
8