Transcript JADE Java Agent DEvelopment Framework

JADE
Java Agent DEvelopment Framework
Fabio Bellifemine, CSELT - Torino (Italy)
Agostino Poggi, Giovanni Rimassa,
University of Parma (Italy)
Slide: 1
What is JADE

is a software framework


is the middle-ware for MAS





that simplifies the implementation of multi-agent systems
target users: agent programmers for MAS
agent services
 life-cycle, white-page, yellow-page, message transport
tools to support debugging phase
 remote monitoring agent, dummy agent, sniffer agent
designed to support scalability
 (from debugging to deployment)
 from small scale to large scale
fully implemented in Java

distributed under LPGL
Slide: 2
Distributed architecture of a
JADE Agent Platform
Application Agent
Application Agent
Application Agent
Host 3
Application Agent
Application Agent
Application Agent
Host 2
Application Agent
Application Agent
Application Agent
Host 1
Jade distributed Agent Platform
Jade Main-container
JRE 1.2
Jade Agent Container
JRE 1.2
Jade Agent Container
JRE 1.2
Network protocol stack
Slide: 3
Internal architecture of
the JADE main-container
Agent
Management
System
Directory
Facilitator
White page
service
Yellow page
service
Agent Communication Channel
Intra-Container
Message Transport
(Java events)
Inter-Containers
Message Transport
(Java RMI)
local cache of
agent addresses
Inter-Platforms
Message Transport
(IIOP)
Note: The internal architecture of a JADE container is similar, but
it does not contain the AMS, the DF, and the IIOP modules.
Slide: 4
Mapping theory into design

Agents are autonomous.

Agents are active objects.

Agents are social entities.

Intra-agent concurrency is
needed.

Messages are speech acts,
not invocations.

Asynchronous messaging
must be used.

An agent can say “no” and “I
don’t care”.

Peer-To-Peer messaging (built
over distributed objects
Client/Server interactions).
Slide: 5
JADE Communication Subsystem

every agent has a private queue of ACL
messages created and filled by the JADE
communication sub-system

designed as a chameleon to achieve the lowest
cost for message passing


the mechanism is selected according to the situation
the overheads depend on the receiver’s location and the
cache status
Slide: 6
JADE Communication Subsystem
AGENT CONTAINER (FE)
Agent
Container
Table
Agent
Global
Descriptor
Table
Message Dispatcher
AGENT CONTAINER
AGENT CONTAINER
Agent1
event
Agent2
Local
cache
event
Message Dispatcher
Agent3
Java RMI
Message Dispatcher
Slide: 7
Communication Model
implications on the JADE implementation

library of interaction protocols

the framework directly supports parsing





envelope parser (in JADE 2.0)
ACL parser
CL parser
 including support for uuencoded Java serialization
Ontology checker
the framework can be extended by the user



support to define/save/load new ontologies
interface for CLParser/Encoder
automatically used by the framework
Slide: 8
Agent Execution Model
implications on the JADE implementation

agent is autonomous



it completely controls its thread of execution
 private proxy of the life-cycle manager
it decides itself when to read received messages and which
messages to read/serve
 the transport mechanism fills a private queue but it does not
call the agent code (no automatic callback)
agent needs concurrency


can engage multiple simultaneous conversations
can execute several concurrent tasks
 Java multi-thread or/and
 JADE behaviours with cooperative scheduling

Slide: 9
one thread-per-agent rather than one thread-per-task/convers.
behaviour n
behaviour 2
…
active
agent behaviours
(i.e. agent intentions)
beliefs
polling-based
blocking-based
timeout-based
pattern matching
access mode
behaviour 1
Int. architect. of a generic JADE agent
private inbox of
ACL messages
capabilities
scheduler of
behaviours
life-cycle
manager
The JADE framework includes a library of interaction protocols
and generic agent behaviours, that must be customized for the specific
application needs in order to create the agent capabilities
application
dependent
agent resources
JADE library of
interaction protocols
and of generic Slide: 10
agent behaviours
Concurrency in JADE

different containers on the same platform


different agents on the same container


1 JVM per container
run in a preemptive multi-threaded environment scheduled by
the JAVA Virtual Machine
different behaviours on the same agent


scheduled cooperatively
 every behaviour must release the control to allow the other
behaviours to be executed
 no stack to be saved, more effort to the programmer
 JADE scheduler carries out a round-robin non-preemptive
policy among all behaviours in the ready queue
Behaviours can be composed into a tree
 every Behaviour is a Finite State Machine
 one
state per execution time slot
Slide: 11
Behaviour-based Concurrency Model

Multithreaded inter-agent
scheduling.

Behaviour abstraction
:Agent
x:SequentialBehaviour

Composite for structure
 Chain of Responsibility for
scheduling.

No context saving.
a)
b)
1.1
2
1.2
x1:SimpleBehaviour
c)
1
2.1
x2:SimpleBehaviour
d)
y:SequentialBehaviour
y1:SimpleBehaviour
e)
2.2
y2:SimpleBehaviour
f)
b1 = schedule()
b1.action()
b1.done()?
b2 = schedule()
b2.action()
b2.done()?
mainLoop()
mainLoop()
mainLoop()
mainLoop()
mainLoop()
mainLoop()
Exc. handler
Exc. handler
Exc. handler
Exc. handler
Exc. handler
Exc. handler
run()
run()
run()
run()
run()
run()
Slide: 12
Scalability in JADE

Configuration of a platform



from one MAS on a single host
 single-host platform
to one agent on a single host
 agent platform on a cluster of hosts
configuration can be changed at run-time
 hot restarting is possible thanks to the local caches
 agent

is referred by name => no need to get new reference
The agent container front end is the bottle-neck but
it is involved only when strictly necessary
Slide: 13
JADE 1.25 main features






support for registration
(and automatic usage) of
user-defined CL and
ontologies
 library of common
behaviours (e.g.
WakerBehaviour) that can
be composed
Fipa compliance
tested at Seoul + more
library of interaction
protocols
a number of DFs can be
instantiated
And

core is less than 250 KB
(not compressed)
 intra-platform agent
mobility
 supporting tools: RMA,
DummyAgent, Sniffer
 integrated with Jess

usability

installing / sw requirements
 1 jar file, JRE 1.2
 programming
 about 10 public
classes + the library of
IPs and behaviours
Slide: 14
Current usage of JADE

FACTS



TV-based entertainment
 CSELT, NHK, Imperial College of London, IRST
personal travel assistant
 BT, France Telecom, Broadcom
DICEMAN - Trading of A/V content



FILIGRANE - e-commerce of mobile agents
LiMe - Living Memory for connected communities



CSELT, KPN, Starlab, Politecnico of Torino
ICL, Philips, Queen Margaret University College, DomusAcademy
 2 day field trial for dynamic user profiling, collective information
dissemination and memory management
Univ. Helsinki, Parma, Bologna, Brescia
SONG, SAFIRA, COMMA, ...
Slide: 15
How much of FIPA is hidden
by JADE to the programmer?

no need to implement the Agent Platform


no need to implement agent-management
ontology and functionalities



an agent is registered with the AP within its constructor
 it is given a name and an address
the Agent class provides a simplified i/f to access the
services of the DF (registration, searching, …)
no need to implement Message Transport and
Parsing


AMS, DF, and ACC executed at start-up
automatically (and possibly efficiently) done by the
framework when sending/receiving messages
Interaction Protocols must only be extended via
handle methods
Slide: 16
Open Source

JADE is now available in Open Source under
LGPL license


http://sharon.cselt.it/projects/jade
running platform available with AMS, DF, ACC

successful test with Broadcom, Siemens, and University of
Parma
Slide: 17
JADE - what is next?

inter-platform agent mobility

plans (i.e. JADE behaviours) as production rule
systems

when <guard check> do <code body> transition
<enable/disable other plans>

more transport protocols (SMTP, HTTP, WAP)

JADE run time for mobile terminals

checking new user requirements
Slide: 18
Communication Overheads




Same container
 no remote invocations; ACL message object is cloned
Same Agent Platform, different container, cache hit
 one RMI call, the ACL message object is serialized and
unserialized by RMI run time
Same Agent Platform, different container, cache miss
 two RMI calls (update the cache, send the message),
the ACL message object is serialized and unserialized
by RMI run time
Different platforms
 CORBA remote invocation through IIOP
 double marshalling from Java object to Java String to
IIOP byte stream (sender side)
 double unmarshalling from IIOP byte stream to Java
String to Java object (receiver platform side)
 + the cost of delivering to the actual receiver agent
Slide: 19
Example of a Behaviour
public class my3StepBehaviour {
private int state = 1;
private boolean finished = false;
public void action()
switch (state) {
case 1: { op1();
case 2: { op2();
case 3: { op3();
return; }
}
}
{
state++; return; }
state++; return; }
state=1; finished = true;
public boolean done() {
return finished;
}
}
Slide: 20
Integration with JESS

In some cases agents may need to reason about the
state of the world

JESS (Java Expert System Shell) is a symbolic
reasoning tool




it has been developed by Sandia National Laboratories
it is free for non-commercial usage
it is written in Java and it support simple integration into Java
applications
a built-in behaviour is available in the JADE library that, for each
received message, asserts a fact in the Jess engine that describe
the message
 it allows reasoning about messages in JESS
 it allows a JESS program to control sending/receiving
Slide: 21
messages and/or creating/destroying JADE behaviours
JADE Programming Model

JADE based applications are made by one or
more Agents

A JADE agent is mapped onto an user defined Java class,
that must subclass Agent class in jade.core package.

Agent activities are mapped onto user defined subclasses
of Behaviour class in jade.core.behaviours
package.
Slide: 22
JADE Programming Model

The new JADE 1.4 supports user defined content
languages and ontologies.




Each agent holds a table of its capabilities.
Message content is represented as instances of Frame
class, in a language independent way.
User defined classes can be used to model ontology
elements (Actions, Objects and Predicates).
The new JADE 1.4 supports agent mobility.

Intra-platform, weak mobility with on-demand class fetching.
Slide: 23
JADE Support Tools

Administration tools.



RMA Management Agent.
 White pages GUI.
 Agent life cycle
handling.
Directory Facilitator GUI.
 Yellow pages handling.
Development tools.

DummyAgent.
 Endpoint Debugger.
 Message Sniffer.
 Man-in-the-middle.
Slide: 24
JADE Support Tools
Slide: 25
JADE 2.0

Released 12 September 2000


has been updated in order to comply with the new FIPA
specifications (so-called FIPA2000).
 unfortunatelly is has an impact on the user code
general improvements
 the GUI of the DF allows now to control a network of
federated yellow-page services
 programmer’s guide and examples
 added


a section with a guidelines to upgrade user code
fixed all reported bugs
improved the ontology and content language support
Slide: 26
FIPA2000

FIPA2000 is the new set of FIPA specifications
that have been approved.

These specifications make relevant
modifications to:



Agent Platform Architecture and Management
Message Encoding and Transport
ACL and SL syntax
Slide: 27
Agent Management Model
Software
Agent Platform
Agent
Agent
Management
System

The main difference is the
ACC is not an agent.

The ACC supports the
Message Transport System.

The Message Transport
Service is the default
communication method
between agents on different
APs.

The ACC also supports AP
routing tasks.
Directory
Facilitator
Message Transport System
Message Transport System
Agent Platform
Slide: 28
Agent Naming

FIPA identifies an agent through an extensible collection
of parameter-value pairs, called an Agent Identifier (AID).
An AID comprises:

A name.
 Other parameters, such as transport addresses, name resolution
service addresses, and so on.

The name of an agent is immutable; the other parameters
in the AID of an agent can be changed.

A given agent may support many methods of
communication and can put multiple transport address
values in the :addresses parameter of an AID.
Slide: 29
Agent Management

Agent Management Ontology has some
changes deriving from the introduction of agent
AID representation and from the renaming of
AMS and DF actions.

Now AMS and DF have a common subset of
actions:




register
deregister
search
modify
Slide: 30
Message Structure

A message is made up of two parts:



a message envelope expressing transport information, and
a message body comprising the ACL message of the
agent communication.
For the purposes of message interpretation by
an agent:


ACL semantics are defined only over the ACL message
delivered in the message body of a FIPA message.
All information in the message envelope is supporting
information only. How and if this information is used to by
an agent for any kind of additional inference is undefined
by FIPA.
Slide: 31
Message Transport Protocol

IIOP is no longer the sole message transport
protocol.

Now there are three possible message transport
protocol:



IIOP
WAP
HTTP
Slide: 32
Message Encoding

String is no longer the sole message encoding.

Now there are three possible encoding:



String encoding
bit-efficient encoding
XML
Slide: 33
Protocol and Encoding
Mapping

Each of the three message transport protocols
supports the three different kinds of message
encoding.

Only the message envelope depends on
transport protocol.

Abstract Frame-based envelope syntax, mapped to
protocol-dependent concrete syntaxes.
Slide: 34
ACL and SL

ACL messages contains two new parameters:



reply-to
encoding
SL syntax has been modified to simplify content
parsing.
Slide: 35
JADE 2.0

Version 2.0 upgrades JADE to be compliant to
FIPA2000.

JADE 2.0 requires an upgrading phase of all the
software written in earlier versions.

The main modifications are related to:



Agent class
ACLMessage class
MessageTemplate class
Slide: 36
Agent class

the agent name, that was a String, has been replaced
by an Agent Identifier, represented by the class AID.

In particular the name attribute is the globally unique
identifier and, replaces the agent name of the
previous version of JADE.

The methods getLocalName() and getName() continue
to exist and work at the same way.

However the full name of an agent is no more
composed of the concatenation of its local name and
the platform IIOP address: now FIPA does not allow to
distinguish between the local name and its home AP
address.
Slide: 37

A new method, getAID(), returns the agent AID.
ACLMessage class

The new FIPA specifications have added the two
new parameters reply-to and encoding to the
ACL Message structure.

The specs have also removed the envelope
parameter that is now treated separately.

The sender and receiver parameters do not
contain any more, syntactically Strings, but
AIDs.

As a consequence of that, the user code must
be modified as follows.
Slide: 38
ACLMessage class
Replace
getSource() and setSource(String)
with
getSender() and setSender(myAgent.getAID()).
Replace
getDest, getFirstDest(), addDest()
with
getAllReceiver(), clearAllReceiver(),
addReceiver(AID), removeReceiver(AID).
getAllReceiver() returns an Iterator over all the receivers.
Slide: 39
ACLMessage class
Replace
setReplyTo and getReplyTo
with
setInReplyTo and getInReplyTo.
This modification has been done to avoid ambiguity with the new
reply-to parameter of FIPA.
Replace
setEnvelope(String) and getEnvelope(String)
with
addUserDefinedParameter(":X-envelope", String),
getUserDefinedParameter(":X-envelope")
because envelope is no more a parameter of FIPA ACL Message .
Slide: 40
ACLMessage class
Take care of replying to messages by using the AID's in the reply-to
parameter, when present, instead of those in the sender
parameter.
The best practice is to use the method ACLMessage.createReply()
that already takes care of that.
The deprecated method dump() has been removed, replace it with
System.out.println(msg.toString()).
The deprecated method setType(String) has been removed,
replace it with setPerformative(ACLMessage.REQUEST).
Slide: 41