An Agent Platform for Reliable Asynchronous Distributed Programming
L. Bellissard , N. De Palma, A.Freyssinet , M. Herrmann, S. Lacourte
Sirac Project and AAA-Dyade, INRIA Rhône-Alpes
655, Avenue de l’Europe, F-38330 Montbonnot - FRANCE
Luc.Bellissard@inrialpes.fr
Abstract
Production of reliable and flexible distributed applications
is a growing area of interest and research. Various
middleware technologies are often used as the
communication infrastructure and as a practical ease to
the network programming problem. Among them,
Message-Oriented Middleware (MOM) are known to
provide reliable and flexible communication through
asynchronous message passing. This kind of middleware is
of particular interest when coordinating components that
are not designed for simultaneous execution. Usually,
MOM focus on the communication layer with a
programming interface, charge to the external components
to adapt to the MOM communication model. In this paper,
we introduce a distributed programming model based on
autonomous software entities called agents. Agents act as
the glue software components and they offer reliable and
flexible properties like atomic execution or migration from
node to node. The combination of both a MOM and agents
has been implemented in the AAA platform presented in
the second part of the paper.
1. Introduction
Reliable and flexible distributed applications is a
growing area of interest. Various middleware technologies
like CORBA, DCOM[2], RMI[7] are providing solutions
but some application domains are not fully covered by
those technologies. For example, “24 by 7”
environments[5] request hardware or software failure
recovery, guaranteed transmission, flexible cooperation
between software components and scalability. Message
Oriented Middleware (MOM) are the alternative to
classical middleware. MOM are based on asynchronous
messages as the single structure for communication,
coordination and synchronization, thus allowing
desynchronized execution of components. Reliable
communication is guaranteed by message queueing
techniques (e.g. MQSeries [3]) or specific communication
protocols (e.g. iBus[4]) that can be added independently
from the programming of software components. However,
current solutions only provide to programmers a
communication interface (e.g. JMS[8]). Recovery applies
only to messages but not necessarily to software
components themselves.
In this paper, we introduce a Message Oriented
Middleware which combines the previously stated
communication properties as well as a programming model
of distributed, persistent software entities called agents into
a single homogeneous platform. The platform handles not
only reliable communication but also recovery of software
failures, while the programming model of the software
entities remains simple and flexible.
2. Agent Model
2.1. Agent paradigm
The agent paradigm is close to the reactive object
paradigm[1] in an asynchronous world. Agents are active
objects which can run concurrently and have their own
state. They behave according to an event/reaction model.
An event is a typed data structure used for exchanging
information with other agents. Information means in this
particular case any data structure that can be passed by
value or agent references. Once an agent receives an event,
it reacts accordingly thus changing its state and/or
communicating with other agents. This event/reaction
model is based on a message-passing middleware which
ensures asynchronous and anonymous communication
properties.
Anonymous communication means that agents never
know events targets. To receive an event, agent must
subscribe to a specific event source which is the agent
producer of this event.
Asynchronous communication property decouples
producers of information from consumers. They do not
need to be both ready for execution at the same time.
2.2. Infrastructure Properties
Services provisioning in a highly distributed environment
requires a flexible, scalable and reliable infrastructure.
In order to cope with application unavailability due to
failures, the agent infrastructure provides transactional
facilities and a reliable communication mechanism.
• Agent properties
Agents are persistent. This means that the agent lifetime is
not bounded to the duration of the execution. However,
persistency is not sufficient for retrieving a consistent state
after failure. Also, agent reactions are atomic. This
property ensures that a reaction is either fully executed or
not executed at all.
Agents are true distributed objects; each of them has a
global unique reference, they can be remotely installed and
created, and can be migrated from node to node.
• Communication properties
The communication infrastructure provides asynchronous
message passing between agents. What characterizes
MOM is the guaranteed delivery of messages, through
persistence of senders’ events in queues while it is not
delivered to the receivers. A transaction ensures the
delivery. In addition the infrastructure provides causal
ordering[6] for events delivery.
3. Architecture
3.1. Agent Platform Architecture Overview
The runtime architecture provides the communication
infrastructure. Intuitively, message queuing is a technique
for sending messages from one program to another by
directing messages to a queue as an intermediate storage
point. The basic behavior is that an agent sends events
using the sendTo method. Events are encapsulated in
messages. The bus forward messages over the network and
stores them in a queue. When a listening agent is ready to
run, the bus gets the first message in the queue and calls the
agent reaction which handles the event.
3.2. Inside the agent infrastructure
The architecture of the MOM can be divided into three
entities parts:
Agent Server : it is a single process that manages a set of
agents. All agent server can communicate with each other,
thus implementing a part of the software bus. Each server
has an engine, which is in charge of enacting agents
according to the events received. Atomicity of agents’
reaction is achieved by the engine.
Agents : it is the unit of execution. An agent is a passive
Java object whose reaction is enacted by the server engine
component whenever an event is delivered.
Channel (Message queue): it is the communication
infrastructure. A channel is made of representative
contained in each agent server. Each of those are
implemented in their own thread of execution, thus
handling communication, reliability and the causality
properties.
Agent server Agent server
A1 A2 A4 A5
A3 A6
channel engine channel engine
Message queues Messages queues
Figure 1 Agent platform architecture
3.3. Discussion about the Infrastructure
Agents of a same server do not really run concurrently,
since an engine is in charge of activating them once at a
time. This implementation choice has several advantages: a
lightweight implementation of atomic reactions and the
scalability of the number of agents.
Nevertheless, real parallelism can always be achieved with
several agent servers on a same machine.
4. Conclusion
Current Middleware technology such as CORBA or
DCOM do not fit well to classes of application where
desynchronize execution of components and reliable
communication are essential.
We have described an agent infrastructure based on a
software bus which embed built-in mechanisms for
reliable events sending. Experiments have been undertaken
in cooperation with Business Units of Bull S.A. in the
fields of Network security and system supervision. Up to
1000’s of agents are used for the analysis and audit of
network traffic incoming through firewalls deployed on a
system with up to a hundred nodes. Agents properties
seems to be well suited to such a large-scale distributed
system where information delivery and service
provisioning must be guaranteed at all time.
5. References
[1] G. Agha, P. Wegner, A. Yonezawa, eds (1993), “Research
Directions in Concurrent Object-Oriented Systems”, the MIT
Press, Cambridge, MA, 1993
[2] D. Rogerson, “Inside DCOM”, Microsoft Press, Redmond,
WA, 1997
[3] B. Blakeley, H. Harris, J.R.T. Lewis, “Messaging and
Queueing Using the MQI: Concepts and Analysis, Design and
Development” 1995:McGraw-Hill. ISBN 0-07-005730-3
[4] S. Maffeis, “iBus – The Java Intranet Software Bus”, TR,
Softwired A.G., February 1997
[5] B. Oki, M. Pflueg, A. Siegel, D. Skeen, “The Information Bus
– An Architecture for Extensible Distributed Systems”, Operating
Systems review, 27(5), PP.58-68, Dec. 1993
[6] Raynal M., Singhal M., “Logical Time : Capturing Causality
in Distributed Systems”, IEEE Computer , Feb 1996, pp.49-56
[7] Sun Microsystems, “RMI: Remote Method Invokation “, July
1997
[8] Sun Microsystems, “Java Message Service”, v. 1.0.1, October
1998.