Agents and real-world devices

Multi-agent systems are broadly conceptualised as a collection of
specialised software components (the agents) inhabiting some
notional space (the environment). Agents can range from the very
simple reactive kind, to more complex autonomous agents capable of
initiating actions within the environment. The environment itself can
range in complexity, depending on the services it makes available to
agents. Typical affordances of an environment include a messaging
system, allowing agents to communicate with each other via a
standardised interface, or the ability to migrate between distributed
machines.

The messaging system in particular is central to agent programming,
which is based on the principle of distributed and decentralised
computation. Within a single environment, which may span multiple
physical networks, each agent must have a unique name. If one agent
knows the name of another agent it can send a message directly to it,
analogous to sending email. Agent environments, or specialist system
agents within the environment, are typically available to allow agents
to search for other agents with particular expertise, or to broadcast
messages to sets of agents. So even though an environment may be
highly dynamic, with agents being created and destroyed on-the-fly,
the formal principle of a system of uniquely identifiable interacting
entities is maintained at all times.

Interesting questions arise when considering how to interface
multi-agent systems with non-agent-based systems and devices, such as
Web browsers and mobile phones. As has been mentioned before on this
blog, we are using the Jade agent development framework to implement
the core backend functionality of SerenA. Jade offers a number of
system components to tackle some of these issue. For example, the
JadeGateway class can be used to implement a Web interface for an
agent system, effectively allowing standard HTTP requests to trigger
agent behaviours, the results of which are returned to the external
client. The Jade approach to enabling Android devices to communicate
with an agent system differs slightly in that a MicroRuntimeService
can be instantiated on an Android device, within which a Jade
container, and therefore an agent, can be hosted. This approach
extends the notion of the agent environment to encompass individual
Android devices, enabling an agent running on a device to interact
with other agents in the distributed system in the usual way.

There are numerous advantages in attempting to extend the notion of
the agent environment to Web servers and mobile devices, not least
because of the elegance of a simple unified formalism applying to the
entirety of a large pervasive system. However, there are some
potential drawbacks too. The proprietary nature of the Jade
inter-container protocol means that implementations must be available
for each targeted software platform in order for them to join a Jade
platform.

A slightly different approach to allowing non-agent-based systems to
interact with a Jade backend is to base all non-agent interaction
exclusively on a single standard Web protocol, and allow agents to be
created and destroyed on-the-fly to handle the communication with
individual devices as they connect and disconnect from the
system. Jade’s standard HTTP gateway could be used to implement this
kind of design, although for our purposes, the call-and-response
paradigm of HTTP is less appropriate for our requirements of real-time
bidirectional messaging.

Our current approach to this problem is to use the WebSocket Protocol
for all non-agent-based device communication. Using a WebSocket server
(currently a fork of the jWebSocket server library), with custom
plugins providing user signup and agent interaction functionality, we
have a single endpoint for all devices wishing to interact with the
backend agent system. Furthermore, all communication is encrypted, and
authentication and authorisation is handled by the WebSocket server
using standard methods. Our fork of the jWebSocket client library
provides bidirectional messaging between Android (and other standalone
Java applications) and the agent system. WebSocket libraries are now
available for many programming languages, greatly simplifying the
development of future browser-based and standalone SerenA frontend
applications.

The current design of our Jade-WebSocket architecture is entirely
decoupled. Within this design, when a non-agent device initiates a
persistent connection with the WebSocket server, the agent server
plugin notifies a dedicated Jade agent, which is also holding a
persistent WebSocket connection to the server. This agent instantiates
a device-specific shadow agent, which represents the newly connected
device within the agent environment. Therefore, any agent within the
environment wishing to send a message to a particular external device
simply sends a message to the device’s shadow agent, leaving the
WebSocket server to carry out the routing and to ensure the security
policy is enforced. At the protocol level, we have all the guarantees
of packet delivery provided by the TCP. At the SerenA application
level, the success or failure of an action triggered by a messages
sent from either an agent or an external device is handled by
jWebSocket’s response listener mechanism. Response listeners are
executed upon receiving a response to a sent message, or after a
defined timeout period in the event of a problem, which must then be
handled in some appropriate way.

Device specific shadow agents allows the particular requirements or
capabilities of individual devices to be neatly encapsulated. We
currently have two kinds of shadow agents, one for Android devices,
and one for public SerenA devices such as large screen displays of
non-private location-specific information. Instantiated Android shadow
agents effectively mirror the capabilities of the SerenA Android app,
for example, allowing the triggering of notifications and the
persisting of user data in the server-side triple store. Our current
public SerenA shadow agent implementation takes advantage of the
WebSocket server’s channel plugin (also forked, but not as yet
released). For example, we are developing a number of prototype public
displays, intended for a particular location, implemented using the
Processing and jWebSocket client libraries. The prototype display
applications connect to the SerenA WebSocket server, and subscribe to
a specific password-protected channel. The shadow agent for that
public display is then responsible for publishing the appropriate
content to that channel.