Simple agents in Jade

1. Agents (recap): encapsulating control

The deck opens by re-deriving the course’s core notion. If components in a distributed system encapsulate control, they will be able to keep on computing even without connection. A smart way to start engineering distributed systems is therefore to encapsulate computational autonomy within basic components — and computationally-autonomous components in (distributed) software systems are called agents. Properly-designed agents may provide not just fault tolerance, but even some degrees of liveness and consistence — at least at the individual component level.

This is Chapter 4’s argument restated in engineering terms: autonomy is not a luxury but the mechanism that keeps distributed components alive and consistent when the network fails them. Jade will make this concrete: each agent runs on its own thread, so an agent’s computation does not depend on the liveness of any other component.

2. The “weak” notion of agent

The deck introduces the hallmarks of agenthood as the literature standardly lists them [Jennings and Wooldridge, 1996]:

• autonomy — agents should be able to perform the majority of their problem solving tasks without the direct intervention of humans or other agents, and they should have a degree of control over their own actions and their own internal state;
• social ability — agents should be able to interact, when they deem appropriate, with other software agents and humans in order to complete their own problem solving and to help others with their activities where appropriate;
• responsiveness — agents should perceive their environment (which may be the physical world, a user, a collection of agents, the INTERNET, etc.) and respond in a timely fashion to changes which occur in it;
• proactiveness — agents should not simply act in response to their environment, they should be able to exhibit opportunistic, goal-directed behaviour and take the initiative where appropriate.

In the common acceptation of the agent literature, these are called weak agents [Wooldridge and Jennings, 1995]. The word “weak” is the key: nothing in this list requires beliefs, desires, intentions or explicit goals. Jade agents are weak agents — and the chapter will show how much can be built with just these four properties.

3. Agents as autonomous entities

The deck then gives the definition that Chapter 4 established and Chapter 11 reused:

Definition (Agent). Agents are autonomous computational entities [Omicini et al., 2008]: genus — agents are computational entities; differentia — agents are autonomous, in that they encapsulate control along with a criterion to govern it.

From autonomy, many other features stem: autonomous agents are interactive, social, proactive, and situated; they might have goals or tasks, or be reactive, intelligent, mobile; they live within MAS, and interact with other agents through communication actions, and with the environment with pragmatical actions. Every one of these words will find its Jade counterpart in the next sections.

4. What is Jade?

Jade [Bellifemine et al., 2007] stands for Java Agent DEvelopment Framework. Jade is a Java-based framework to develop agent-based applications in compliance with the FIPA specifications for interoperable, intelligent, multi-agent systems. FIPA stands for Foundation for Intelligent Physical Agents — the IEEE Computer Society standards organisation (currently inactive) that promotes agent-based technology and the interoperability of its standards with other technologies.

As an agent-oriented middleware, Jade pursues a twofold goal:

• being a full-fledged FIPA-compliant agent platform — hence, it takes charge of all those application-independent aspects — such as agent lifecycle management, communication, distribution transparency, etc. — necessary to develop a MAS;
• a simple yet comprehensive agent development framework — therefore, it provides Java developers a set of APIs to build their own customisations.

This is the classic middleware deal: the platform handles the hard, application-independent machinery; the developer writes only the agent-specific logic. Chapter 11’s complaint about FIPA becomes visible here: the platform is built around communication; pragmatical actions are left to the programmer.

5. Jade main ingredients and features

Jade’s two main ingredients mirror its twofold goal:

• Java — being fully implemented in Java, Jade is a notable example of a distributed, object-based, agent-oriented infrastructure — hence an interesting example about how to face a design/programming paradigm shift;
• FIPA — being compliant to FIPA standards, Jade is a complete and coherent agent platform providing all the necessary facilities to deploy MAS — promoting interoperability.

And the features Jade offers, which the deck lists as its selling points:

• a distributed agent platform — a single (logical) Jade system can be split among different networked hosts;
• transparent, distributed message passing service;
• transparent, distributed naming service;
• white pages & yellow pages discovering facilities;
• intra-platform agent mobility (code & context, to some extent);
• debugging & monitoring graphical tools;
• … and much more.

6. FIPA architecture: platforms and containers

A FIPA agent platform can be split onto several hosts, provided that:

• each host acts as a container of agents — that is, it provides a complete runtime environment for Jade agents execution (lifecycle management, message passing facilities, etc.);
• there is (at least) one of these containers acting as the main container (actually, the first started);
• the main container is responsible for maintaining a registry of all other containers in the same Jade platform — through which agents can discover each other.

Hence, Jade promotes a peer-to-peer interpretation of a MAS: there is no centralised agent hub — containers are peers coordinated through the main container’s registry.

7. AMS, DF and the ACC

The FIPA architecture is built on three services, each with a distinct role:

• Agent Management System (AMS) — a single AMS exists for a given Jade platform. It keeps track of all other agents in the same Jade platform — even those living in remote containers — and should be contacted by Jade agents prior to any other action (they do not even exist until registered by the AMS). Hence, the AMS provides the white pages service — a location-transparent naming service.
• Directory Facilitator (DF) — a single DF exists for each Jade platform. It keeps track of all advertised services provided by all the agents in the same Jade platform, and should be contacted by Jade agents who wish to publish their capabilities. Hence, the DF provides the default yellow pages service — according to the publish/subscribe paradigm.
• Agent Communication Channel (ACC) — a distributed message passing system exists for a given Jade platform. It controls the exchange of messages within the Jade platform, be they local or remote; implements all the required facilities to provide for asynchronous communication; and manages all aspects regarding FIPA ACL (Agent Communication Language) [FIPA ACL, 2002] message format, such as serialisation and deserialisation.

The mnemonic is simple: AMS answers “who is there?” (white pages), DF answers “who offers what?” (yellow pages), and ACC moves the messages.

8. Agents in Jade

Two sentences capture the essence of Jade agents:

• An agent is a Java object executed by a Java thread. Since Jade is an object-based middleware, Jade agents are first of all Java objects — user-defined agents must extend jade.core.Agent, inheriting some ready-to-use methods.
• An agent is more than a Java object. Despite being Java objects, Jade agents have a wide range of features promoting their autonomy: each Jade agent is executed by a single Java thread (with an exception, though); all Jade agents have a globally unique name (agent ID, AID), which is (by default) the concatenation — by symbol ‘@’ — of their local name and of the Jade platform name; the agent’s business logic must be expressed in terms of behaviours; and Jade agents communicate by exchanging FIPA ACL messages.

Three consequences deserve emphasis. First, the single-thread rule is what makes autonomy safe: one agent, one thread — no interference from within. Second, the AID is the identity that makes communication possible — you need a name before you can have a mailbox. Third, “business logic must be expressed in terms of behaviours” is the discipline that makes the whole platform work — the topic of section 10.

9. The FIPA agent lifecycle

FIPA defines the states a Jade agent goes through, and the deck lists them precisely:

• Initiated — the agent object has been built, but cannot do anything since it is not registered to the AMS yet — it has no AID even;
• Active — the agent is registered to the AMS and can access all Jade features — in particular, it is executing its behaviour(s);
• Waiting — the agent is blocked, waiting for something to happen (and to react to) — typically, an ACL message;
• Suspended — the agent is stopped, therefore none of its behaviours are being executed;
• Transit — the agent has started a migration process — it will stay in this state until migration ends;
• Unknown — the agent is dead — it has been deregistered to the AMS.

Notice how the lifecycle encodes autonomy: the AMS grants existence (registration), the agent itself decides when to wait, when to suspend, and when to die. The state explorer below lets you walk the transitions.

10. Agent behaviours and scheduling

Why behaviours at all? By definition, agents are autonomous entities, therefore they should act independently and concurrently with respect to one another. The need for efficiency drives toward the execution of Jade agents as a single Java thread each. However, agents need to perform complex activities, possibly composed by multiple tasks — even concurrently. How can such contrasting requirements be satisfied altogether?

The answer is the behaviour abstraction:

• a behaviour can be seen as an activity to perform with the goal of completing a task;
• a behaviour can represent a proactive activity — started by the agent on its own — as well as a reactive activity — performed in response to some events (timeouts, messages, etc.);
• Jade implements behaviours as Java objects, which are executed concurrently — still by a single Java thread — using a non-preemptive, round-robin scheduler, internal to the agent class but hidden to the programmer.

This is Chapter 10’s remark made concrete: Jade agents encapsulate procedural knowledge as behaviours, and “need just the selection of a (pre-defined) course of action most appropriate to the current situation” — the scheduler performs that selection, round-robin, one behaviour at a time.

11. The ACC: mailbox and ACL messages

Following the FIPA specification, Jade agents communicate via asynchronous message passing:

• each agent has a message queue (a sort of mailbox) where the Jade ACC delivers ACL messages sent by other agents;
• whenever a new entry is added to the mailbox, the receiving agent is notified — no need to either block or keep on asking;
• if and when the agent actually processes a message is up to the agent itself (or the programmer) — for the sake of agents autonomy.

The autonomy point is subtle and worth underlining: delivery is asynchronous and notification-based, but processing is a choice. An autonomous agent may ignore a message; the platform cannot force it to react. That is the weak-notion autonomy of section 2, enforced by the middleware.

To understand each other, agents must agree on the format and semantics of the messages they exchange. An ACL message contains:

• :sender — who sends the message (automatically set);
• :receiver — who the message targets (possibly many);
• :performative — the name of the communication act the agents want to carry out (constrained by a FIPA ontology);
• :content — the actual information conveyed by the message;
• :language — the syntax used to encode the :content;
• :ontology — the semantic framework upon which the :content relies;
• … other fields, and so on.

These are the FP/EE (or FP/RE) pairs Chapter 10 mentioned when discussing FIPA ACL — the same standard, now seen from the message side.

12. Communication primitives

To interact, Jade agents have a number of ready-to-use methods:

• send — to send a message to a recipient agent;
• receive — to asynchronously retrieve the first message in the mailbox (if any);
• timed receive — to perform a timed, synchronous receive on the mailbox — timeout causes the agent to resume execution;
• selective receive — to retrieve a message from the mailbox which matches a given message template — message queue order is bypassed.

All the above methods are distribution-transparent: they choose the proper address and transport mechanism based upon sender and receiver locations. The agent writes send(msg); the ACC decides whether the message stays in the platform or crosses hosts.

13. Fast Lab

The deck ends with the hands-on assignment: clone the lab repository and follow the lead.

git clone https://dvcs.apice.unibo.it/pika-lab/courses/ise/ay2526/lab-jade
cd lab-jade
# and follow the lead

Everything in this chapter — containers, AMS, behaviours, ACL messages, mailboxes — becomes tangible in the lab: run a main container, spawn agents on it, make them exchange messages, and observe the lifecycle and the scheduler in the debugging tools.

Check your understanding