SerenA Android Development and WebSockets

A large proportion of the SerenA design and development effort in
recent weeks has focused on specifying and implementing a prototype
user interface to the SerenA system. Mobile, Web, desktop and pubic
space interfaces are all potential mediums through which users may
interact with the system. For the first prototype we decided to
concentrate on mobile development and build a SerenA Android client,
which among other things, allows us to investigate the integration of
spatial-temporal information within the context of our goal of
facilitating serendipitous discovery.

One of the important requirements of the SerenA system is that
information must be able to be relayed to users in a timely
manner. For time- and location-specific information SerenA must be
able to notify a user of a potentially serendipitous encounter while
the opportunity exists, otherwise, a valuable opportunity may be
missed.

Behind the scenes, SerenA is an RDF-based multi-agent system,
currently implemented as a Jade agent platform and making
extensive use of the Jena Semantic Web framework. The system
comprises specialised SerenA agents implementing core functionalities
of the system, as well as a number of wrapper agents acting as
intermediaries to external services such as Spotlight, Twitter
(via TwitLogic), Sindice and Digg. Although focusing on
Android development for our first user interface prototype, it is
important that the technology we use and develop for connecting user
devices to the back-end system be re-usable and flexible enough to
cope with the challenges of future interfaces, whether they be
Web-based, desktop or public installation applications.

The concept of real-time notifications is nothing new, and in the
context of the Web, various techniques exist to allow newly received
information on the server-side to be relayed to a user’s browser or
standalone client application. However, due to the document-oriented
design of the HTTP protocol, in which a user requests a resources and
the server returns it and closes the connection, the concept of
pushing information from the server has to be faked somewhat. In the
simplest, and most inefficient case, a Web application might
periodically query the server to find out whether any new information
has arrived. Other techniques, generally referred to as Comet
technologies, include HTTP streaming and long polling. In these cases,
instead of the server closing the client-initiated connection once it
has transmitted the requested resource, it keeps it open so that new
information arriving at the server can be delivered immediately to the
client over the long-lived connection. Comet technologies can work
well in practice, but a lack of standardisation and variation in
browser implementations in particular can lead to added
complications. HTTP streaming can also sometimes suffer unexpected
consequences due to not closing client connections for extended
periods of time, as other infrastructure components such as proxies
might wait until connections are closed before relaying
information. Long-polling avoids this particular problem by closing
the connection after each update is sent from the server. The client
then immediately re-establishes the connection which is used for the
next update. However, this naturally increases bandwidth consumption.

As an alternative to these well established methods of server-push
technologies, we took a look at the recent WebSocket protocol. The
WebSocket protocol is currently a proposed Web standard, aligned with
the emerging HTML5 standard. WebSockets are already implemented in
recent versions of most widely-used browsers, and a number of actively
developed libraries are now available for standalone application
development.

WebSockets provide bi-directional communication between a client and a
server using a single TCP connection, and importantly, integrate with
existing HTTP infrastructure. To open a WebSocket connection, which
like regular HTTP connections are always initiated by the client, a
client sends a HTTP Upgrade request to the WebSocket-enabled Web
server, optionally using TLS for encrypted communication. This request
is the first part of the WebSocket handshake, and resembles a
regular HTTP GET request with additional WebSocket-specific header
fields. The server then returns the handshake, and if all has gone
well, the WebSocket connections is established. From this point on,
both client and server can initiate data transfer independently using
the TCP-based WebSocket protocol. The WebSocket protocol itself
describes how data is transferred “on the wire”. In order to enable
application specific requirements to be met, during the handshake the
client and server negotiate the subprotocol that will be used during
the subsequent interaction.

So returning to SerenA, WebSockets potentially offer a general and
secure solution to enabling timely communication between the back-end
agent system and a range of front-end user devices. After
investigating a number of WebSocket library implementations, we are
currently evaluating jWebSocket, which provides a number of
Java-based server options, as well as JavaScript and Java client
libraries, the latter of which can be used on the Android
platform. The Java client itself is currently less feature-rich than
the JavaScript library, which in our case has meant extending it in
order to take advantage of the newly integrated Spring security
framework, as well as adding client-side channel functionality so that
users can exchange messages with specific agents over designated
password-protected private channels.

Asynchronous real-time messaging between agents is a common feature of
multi-agent systems, and WebSockets potentially offer a means of
extending that kind of interaction into standard Web infrastructure,
and ultimately to users. There is also increasing interest in the
Semantic Web community in real-time RDF data streaming, for which
WebSockets may be a viable solution. WebSockets are not a silver
bullet, but with the significant effort towards standardisation, and
the apparent levels of interest within Web development communities,
they are a promising technology for future Web-based applications.