JADE Java Agent DEvelopment Framework

1. JADE Java Agent DEvelopment Framework Fabio Bellifemine, CSELT - Torino (Italy) Agostino Poggi, Giovanni Rimassa, University of Parma (Italy)

2. What is JADE • is a software framework • that simplifies the implementation of multi-agent systems • is the middle-ware for MAS • 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

3. Distributed architecture of a JADE Agent Platform Host 1 Host 2 Host 3 Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Application Agent Jade distributed Agent Platform Jade Main-container Jade Agent Container Jade Agent Container JRE 1.2 JRE 1.2 JRE 1.2 Network protocol stack

4. Agent Management System Directory Facilitator White page service Yellow page service local cache of agent addresses Agent Communication Channel Intra-Container Message Transport (Java events) Inter-Containers Message Transport (Java RMI) Inter-Platforms Message Transport (IIOP) Internal architecture of the JADE main-container Note: The internal architecture of a JADE container is similar, but it does not contain the AMS, the DF, and the IIOP modules.

5. Agents are autonomous. Agents are social entities. Messages are speech acts, not invocations. An agent can say “no” and “I don’t care”. Agents are active objects. Intra-agent concurrency is needed. Asynchronous messaging must be used. Peer-To-Peer messaging (built over distributed objects Client/Server interactions). Mapping theory into design

6. JADE Communication Sub-system • 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

7. JADE Communication Sub-system

8. Communication Modelimplications 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

9. Agent Execution Modelimplications 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 • one thread-per-agent rather than one thread-per-task/convers.

10. active agent behaviours (i.e. agent intentions) … behaviour n behaviour 1 behaviour 2 beliefs pattern matching blocking-based access mode polling-based timeout-based capabi- lities private inbox of ACL messages scheduler of behaviours life-cycle manager application dependent agent resources JADE library of interaction protocols and of generic agent behaviours 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 Int. architect. of a generic JADE agent

11. Concurrency in JADE • different containers on the same platform • 1 JVM per container • different agents on the same 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

12. Behaviour-based Concurrency Model • Multithreaded inter-agent scheduling. • Behaviour abstraction • Composite for structure • Chain of Responsibility for scheduling. • No context saving.

13. 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

14. 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 support for registration (and automatic usage) of user-defined CL and ontologies library of common behaviours (e.g. WakerBehaviour) that can be composed usability installing / sw requirements 1 jar file, JRE 1.2 programming about 10 public classes + the library of IPs and behaviours JADE 1.25 main features

15. 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 • CSELT, KPN, Starlab, Politecnico of Torino • FILIGRANE - e-commerce of mobile agents • LiMe - Living Memory for connected communities • 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, ...

16. How much of FIPA is hidden by JADE to the programmer? • no need to implement the Agent Platform • AMS, DF, and ACC executed at start-up • 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 • automatically (and possibly efficiently) done by the framework when sending/receiving messages • Interaction Protocols must only be extended via handle methods

17. 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

18. 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

19. 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

20. Example of a Behaviour public class my3StepBehaviour { private int state = 1; private boolean finished = false; public void action() { switch (state) { case 1: { op1(); state++; return; } case 2: { op2(); state++; return; } case 3: { op3(); state=1; finished = true; return; } } } public boolean done() { return finished; } }

21. 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 messages and/or creating/destroying JADE behaviours

22. 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.

23. 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.

24. 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.

25. JADE Support Tools

26. 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

27. 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

28. Agent Management Model • 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.

29. 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.

30. 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

31. 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.

32. Message Transport Protocol • IIOP is no longer the sole message transport protocol. • Now there are three possible message transport protocol: • IIOP • WAP • HTTP

33. Message Encoding • String is no longer the sole message encoding. • Now there are three possible encoding: • String encoding • bit-efficient encoding • XML

34. 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.

35. ACL and SL • ACL messages contains two new parameters: • reply-to • encoding • SL syntax has been modified to simplify content parsing.

36. 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

37. 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. • A new method, getAID(), returns the agent AID.

38. 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.

39. 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.

40. 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 .

41. 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 senderparameter. 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).