Tutorial 1: JADE Architecture Overview

Table of contents
Next


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

  1. It must be the first container to start in the platform and all other containers register to it at bootstrap time
  2. 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 REQUESTmessage)

Table of contents
Next