in Multi Agent

Getting started with JADE

JADE, the Java Agent DEvelopment Framework, has been around the block. It is developed and maintained by http://jade.tilab.com/, and it’s been around for over fifteen years.

This framework has decent documentation (for programming it) and its classes force opinions about how agents should communicate and behave. I decided to try this out as an experiment in a new programming paradigm, and below are some lessons learned so far.

Configuring JADE

I opted to not use embedded JADE configuration and instead use JADE’s (very poorly documented) config file format. I recommend downloading the source code and becoming familiar with the jade.Boot class. Config file values are not always their commandline equivalents.

Main Container Configuration

JADE is a distributable solution with a possible active-standby configuration for its main container. The stateful nature of agents written in the JADE paradigm, and their need to directly address each other requires this. Below is the configuration i use for this controller. It starts up a swing-based gui for this.

gui=true
host=localhost
port=10099
local-port=10099

Agent Container Configuration

Development requires frequent agent starts and stops, and a gui will just slow the whole thing down. In an effort to make that possible, i use the (undocumented) no-display option in my configuration. Also, in order to start up as a peripheral container, you do not use the same option as the commandline (-container). You use main=false.

agents=\
    firstAgentYouDesigned:bookBuyer.BookBuyerAgent;\
    nextAgentYouDesigned:bookSeller.BookSellerAgent
port=10099
host=localhost
main=false
no-display=true

I thought state was a bad thing!

State is a bad thing. Well, system state is a bad thing. This work is also an experiment to see how working with stateful agents could be used as an abstraction to create a system that may hold state but is also fault tolerant (can survive agent death). The use of orchestrator agents and the “yellow pages” service seem to suggest that if a transaction goes bad, connecting to another instance of that kind of agent may be possible. The agent abstraction is also a very intuitive one, as humans in an organization are stateful agents.