Table of contents
Next
Tutorial 1: JADE Architecture Overview
This tutorial provides an overview of the JADE Architecture introducing the notions of
- Agent
- Container
- Platform
- Main Container
- AMS and DF
Figure 1 represents the main JADE architectural elements. An application based on JADE is made of
a set of components called Agents each one having a unique name. Agents execute tasks and interact by
exchanging messages. Look at the JADE Programming Tutorial for a detailed explanation
about how to develop agents and to make them execute tasks and communicate. Agents live on top of a Platform
that provides them with basic services such as message delivery. A platform is composed of one or more Containers.
Containers can be executed on different hosts thus achieving a distributed platform. Each container can
contain zero or more agents. For instance, with reference to the picture below, container "Container 1" in host Host 3
contains agents A2 and A3. Even if in some particular scenarios this is not always the case, you can think of a Container
as a JVM (so, 1 JVM ==> 1 container ==> 0 or many agents). A special container called Main Container exists in
the platform. The main container is itself a container and can therefore contain agents, but differs from other
containers as
- It must be the first container to start in the platform and all other containers register to it
at bootstrap time
- It includes two special agents: the AMS that represents the authority in the platform and is the only
agent able to perform platform management actions such as starting and killing agents or shutting down the whole
platform (normal agents can request such actions to the AMS). The DF that provides the Yellow Pages
service where agents can publish the services they provide and find other agents providing the services they need.
Figure 1. The JADE Architecture
It should be noticed that if another main container is started, as in host Host 4 in Figure 1, this constitutes a
new platform.
Agent communication
Agents can communicate transparently regardless of whether they live in the same container (e.g. A2 and A3),
in different containers (in the same or in different hosts) belonging to the same platform (e.g. A1 and A2) or in different
platforms (e.g. A1 and A5). Communication is based on an asynchronous message passing paradigm. Message format
is defined by the ACL language defined by FIPA, an international organization
that issued a set of specifications for agent interoperability. An ACL Message contains a number of fields
including
- the sender
- the receiver(s)
- the communicative act (also called performative) that represents
the intention of the sender of the message. For instance when an agent sends an INFORM message
it wishes the receiver(s) to become aware about a fact (e.g. (INFORM "today it's raining")). When
an agent sends a REQUEST message it wishes the receiver(s) to perform an action. FIPA defined 22
communicative acts, each one with a well defined semantics, that ACL gurus assert can cover more than 95% of
all possible situations. Fortunately in 99% of the cases we don't need to care about the formal semantics
behind Communicative acts and we just use them for their intuitive meaning.
- the content i.e. the actual information conveyed by the message (the fact the receiver
should become aware of in case of an INFORM message, the action that the receiver is expected to
perform in case of a REQUEST message)
Table of contents
Next