agent-oriented & distributed software systems dr rem collier [email protected]

Agent-Oriented&

Distributed

Software Systems

Dr Rem [email protected]

2003 © ChangingWorlds Ltd.

Week 2: Agent Factory (2 hours)


Selected Reading

All of these papers can be found on the http://agentfactory.sourceforge.net website

Ross, R, Collier, R, O Hare, G.M.P. AF-APL: Bridging principles & practices in agent oriented languages. In Proc. The Second International Workshop on Programming Multiagent Systems Languages and tools (PROMAS 2004). Held at AAMAS 04, New York, USA, 2004.

Collier, R., Rooney, C., ;O'Hare, G.M.P., (2004), A UML-based Software Engineering Methodology for Agent Factory, Proceedings of the 16th International Conference on Software Engineering and Knowledge Engineering (SEKE-2004), Banff, Alberta, Canada, 20-25th June.

Rooney, C F.B., Collier, R.W., O'Hare, G.P., VIPER: VIsual Protocol EditoR, in 6th International Conference on Coordination Languages and Models (COORDINATION 2004), Pisa, February 24-27, 2004.

Collier, R.W., O'Hare G.M.P., Lowen, T., Rooney, C.F.B., Beyond Prototyping in the Factory of the Agents, 3rd Central and Eastern European Conference on Multi-Agent Systems (CEEMAS'03), Prague, Czech Republic, 2003.


What is Agent Factory?



Agent Factory is…

“a cohesive framework that delivers structured support for the development and deployment of agent-oriented applications.”



Agent Factory is…


Organised over four layers: Programming Language

Run-Time Environment

Development Environment

Software Engineering Methodology



Agent Factory is…



Declarative Formalised through a Multi-modal logic Agent-specific Constructs






Agent Factory is…



Run-Time Environment Distributed FIPA Compliant Agent Platforms + Infrastructure System Agents: AMS + DF




The Run-Time Environment

Remote Management Interface

Remote Command Shell

Command Line Interface



Agent Factory is…




Development Environment AF-APL Compiler Netbeans & Eclipse Plugins VIPER – Protocol Editor



AF NetBeans Plugin


VIPER – Visual Protocol Editor



Agent Factory is…







Development Methodology

Iterative Refinement Process

SystemBehaviour

Model

ActivityModel

InteractionModel

ProtocolModel

Agent Model

GenerateAgent

Classes

Build AgentComponents

BuildPlatformServices

ProtocolTesting

BehaviourTesting

VIPER

AF IDE

ConfigureAgent

Platforms

DeployApplication

DESIGN

IMPLEMENTATIONDefine

ApplicationOntologies

DEPLOYMENT



Agent Factory is…

“a cohesive framework that delivers structured support for the development and deployment of agent-oriented applications.” Organised over four layers: Programming Language




Implemented in Java

Personal Java, J2ME and J2SE-Compliant

Deployed on PDAs / PCs

Open Source:

Downloadable from http://agentfactory.sourceforge.net


Applications

Ubiquitous Computing & M-Commerce. Agent Factory has been employed to deliver a number of location aware services for hand-held devices.

Gulliver’s Genie, WAY System, E=mc2, AD-ME and EasiShop

Robotics. Agent Factory was employed as part of a hybrid agent architecture that is being used in ongoing research to investigate social robotics.

IMPACT, MARC

Enterprise Search. Agent Factory is being used to implement an autonomic enterprise search architecture.

HOTAIR

Distributed Sensor Networks. Agent Factory is being used to implement sensor networks for monitoring polution in rivers, etc.

Adaptive Information Cluster (AIC), Clever Cat


Agent Factory Summary

So,

Agent Factory is an agent-oriented software engineering framework.

It includes a purpose-built programming language known as AF-APL.

Deployment of applications is supported through a distributed run-time environment that adheres to the FIPA standards.

Tool-based support for the development of agents is provided via the VIPER toolkit and through plug-ins to existing IDEs (NetBeans / Eclipse).

A methodology is includes that promotes a structured approach to the fabrication of agents using Agent Factory.


The AF-APL Language


Agents & AF-APL

AF supports the fabrication of agents through the AF-APL programming language.

An AF-APL agent has the following characteristics:

Autonomy. Each agents has its own thread of control.

Situatedness. Agents exist within some environment and interact (sense and effect) with that environment.

Social Ability. Each agent will interact with other agents (and possibly humans) via FIPA ACL.

Intentionality. The agents will employ a mental state architecture to reason about themselves and their environment.

Rationality. The agents will act on their decisions.

Mobility. Agent Factory supports weak migration of agents (migration of data but not process state).

Based upon these characteristics, various concepts have been employed within AF-APL.


Key AF-APL Agent Concepts

Agent = Mental State + Commitment Rules + Embodiment Config.

Mental State:

Beliefs. Subjective knowledge about the current state of the environment.

Commitments. Mental contract describing which activity, at what time, for whom, and under what conditions.

Activities may be either primitive actions or plans (SEQ, OR, PAR).

Commitment Rules:

Map situations (possible environment states) to commitments that should be adopted should the situation arise.

Embodiment Configuration

Perceptors. Computational units that convert raw data into beliefs.

Actuators. Computational units that define how to realise primitive actions.


AF-APL

AF-APL Programs define:

Actuators

Perceptors

Modules

Commitment Rules

Initial Mental State


Executing AF-APL

AF-APL is executed on a purpose-built agent interpreter.

The agent class is loaded into the interpreter when the agent is created.

Control functions can be used to suspend, resume, and terminate the operation of the agent.

The interpreter processes the agent program by analysing the model of the environment (beliefs) and making decisions about how to act (commitments).

Two problems arise from this:

How to ensure that the model of the environment is up-to-date?

How to make the decision about how and when to act?

These problems are known as the belief management and commitment management problems respectively.


Belief Management

Belief Management = Belief Update + Belief Query

Belief Update

Perception

Temporal Update

Current Beliefs

Temporal Beliefs

Sensor Data

Belief Update. Dynamic Environment -> Transitory beliefs Persistence can be supported through temporal operators (eg ALWAYS, NEXT) Belief update = gathering perceptions + updating the temporal beliefs.


Belief Management

Belief Management = Belief Update + Belief Query

Belief Update

Perception

Temporal Update

Current Beliefs

Temporal Beliefs

Belief Rules

Belief Query

Sensor Data

Belief Queries

Belief Query. Beliefs = Facts + Implications (Belief Rules). Resolution-based reasoning on current beliefs


Representing Beliefs in AF-APL

AF-APL supports three forms of belief:

Current Beliefs. Beliefs that are true at the current time point.

Temporal Beliefs. Beliefs that persist over more than one time point.

Belief Rules. Rules that define inferences that can be made on the current beliefs.

In AF-APL a belief is represented as a first-order structure enclosed within a BELIEF operator:

BELIEF(happy(rem)) – a belief that rem is happy

BELIEF(likes(?person, beer)) – a belief that some person likes beer

BELIEF(bid(fred, 50)) – a belief that fred has bid 50

BELIEF(happy) – a belief that the believer is happy…

These beliefs are current beliefs and apply only at the current time point. As a consequence, they are wiped at the start of each iteration of the AF-APL interpreter.


Temporal Beliefs

Temporal Beliefs associate a temporal operator with the current belief. This operator defines how the belief persists.

ALWAYS – the belief is a current belief and will persist until the temporal belief is dropped.

ALWAYS(BELIEF(happy(rem))) – always believe that rem is happy

UNTIL – the belief is a current belief and will persist until either the temporal belief is dropped or the associated condition is satisfied.

UNTIL(BELIEF(drinking(beer,rem)), !BELIEF(available(beer))) – believe that rem is drinking beer untik you do not believe that there is beer available.

NEXT – the belief will be a current belief at the next time point.

NEXT(BELIEF(finished(beer))) – at the next time point belief that the beer is finished.

These beliefs are maintained until they are explicity dropped.


Belief Rules

Belief Rules define inferences that can be made over the current beliefs of the agent.

They take the form of logical implications:

BELIEF(likes(?food)) & BELIEF(has(?food)) => BELIEF(want(?food))

BELIEF(has(rem, icecream)) => BELIEF(happy(rem))

Belief Rules are applied during the belief query process.

If you wish to check whether the belief BELIEF(want(icecream)) is true then the belief query process will attempt to match the query against any relevant current beliefs AND the right-hand side of any belief rules.

If it is matched with a belief rule, then the belief query process queries whether the terms on the left-hand side of the belief rule are also true (this is known as the resolution step).

If any of these sub-queries is found to be false, then the principal query is found to be false.


Issues in Belief Representation

Knowledge Representation

A content language is a set of definitions of the first-order structures and constants that are used to represent the agents beliefs.

E.g. likes(?x, ?y) represents the relationship that ?x likes ?y.

The definition of this content language is vital to ensuring consistency of meaning within an implementation – this is related to ontologies.

Knowledge Acquisition

The belief set of an agent is basically an expert system.

The developer must acquire domain knowledge and encode that knowledge using the constructs provided (belief rules and temporal beliefs).

This can be done using standard knowledge acquisition techniques.


Commitment Management

Commitment Management is the meta-level process that manipulates an agents’ commitments.

It is formed from a number of sub-processes which implement a set of strategies that specify how an agent:

Adopts new commitments.

Maintains its existing commitments

Refines commitments to plans into additional commitments.

Realises commitments to action.

Handles failed commitments.

A Commitment Management Strategy is a specific set of strategies that can be employed by an agent.

E.g. blind commitment, single-minded commitment, social-minded commitment.

The default strategy in Agent Factory is single-minded commitment.

An agent maintains a commitment so long as it believes it is still acheivable.


Representing Commitments

Commitments represent the courses of action (activity) that an agent has chosen to follow.

In AF-APL a Commitment is a combination of:

Agent Name. The name of the agent to whom the commitment is made.

Time. The time at which the commitment should be considered.

Maintenance Conditions. The conditions under which the commitment must be maintained.

Activity. The course of action (plan/primitive) that must be executed.

Status. The current status of the commitment.

This is represented in AF-APL through the COMMIT construct:

COMMIT(Self, Now, BELIEF(true), drink(beer))


Representing Activities

Activities describe what the agent can do:

Actions. Primitive abilities that are directly executable by the agent.

Plans. A recipe that consists of a partially ordered set of activities.

AF-APL supports the definition of actions and explicit plans.

Actions are defined in the constructor of the associated actuator unit. The definition consists of a unique identifier (e.g. eat(?food) ), a pre-condition (e.g. BELIEF(has(?food)) ) and a post-condition (not used).

Explicit plans are defined within the activity field of a commitment. They take the form of a plan operator (SEQ or PAR for AF-APL) together with a list of activities that may be either additional plan operators or actions.

E.g. SEQ(PAR(boilWater, addCoffee), pourWater, PAR(addSugar, addMilk))


Commitment Adoption

Commitments are adopted as a result of the triggering of Commitment Rules.

A commitment rule defines a situation in which the agent should adopt a commitment.

E.g. BELIEF(has(?food)) => COMMIT(Self, Now, BELIEF(true), eat(?food))

Each of the commitment rules is checked during each iteration of the AF-APL interpreter.

If the situation (left-hand side) of any rule is evaluated to true, then the rule is said to have been triggered.

Whenever a rule is triggered, there exists (at least one) set of variable bindings.

Each set of bindings is applied to the commitment construct on the right-hand side of the commitment rule, and the corresponding primary commitment is adopted by the agent.


Commitment Maintenance

Commitments are maintained using a maintenance condition that is associated with each commitment.

E.g. BELIEF(has(?food)) => COMMIT(Self, Now, BELIEF(true), eat(?food))

This condition outlines what must remain true for the agent to keep the commitment (like terms and conditions and a contract).

In the above example, the maintenance condition will always be true. This is sometimes known as blind commitment.

The maintenance condition is evaluated at each time point.

If the condition becomes false at any time point, then the commitment is said to have “failed”.


Commitment Realisation & Refinement

At some point in time, the agent will try to fulfill its commitments. Commitments to action are fulfilled through actuator activation.

The agent finds the corresponding actuator and activates it. If not corresponding actuator exists, then the commitment fails.

Commitments to plans are fulfilled through commitment refinement.

The agent adopts a set of secondary commitments that correspond to the activities specified in the plan.

Plan operators may be used to place an order on the achievement of these commitments.

We label the set of commitments adopted when fulfilling a primary commitment to be a commitment structure.


Commitment Failure Handling

If any commitment fails, the failure handling strategy defines how the agent should respond to the failure.

In AF-APL, the strategy is simple:

The failure of a secondary commitment is passed to the parent commitment. The impact of this failure is assessed with respect to the parent commitment.

The failure of a commitment that has children causes the children to fail. There is no assessment here!

During the failure handling process, this strategy is applied recursively through the commitment structure.

This recursive process, while potentially computationally expensive, is essential to ensure the agent does not continue to try and fulfil commitments that are now redundant.


Commitment States


Commitment Structure Example

Rem,2005/01/20-8:00:00,BELIEF(true),SEQ(doA, doB),INACTIVE



Rem,2005/01/20-8:00:00,BELIEF(true),SEQ(doA, doB),PLANNED

Rem,2005/01/20-8:00:00,BELIEF(true),doB,WAITING

Rem,2005/01/20-8:00:00,BELIEF(true),doA,INACTIVE





Rem,2005/01/20-8:00:00,BELIEF(true),doA,ACTIVE





Rem,2005/01/20-8:00:00,BELIEF(true),doA,SUCCEEDED




Rem,2005/01/20-8:00:00,BELIEF(true),doB,INACTIVE




Rem,2005/01/20-8:00:00,BELIEF(true),doB,ACTIVE




Rem,2005/01/20-8:00:00,BELIEF(true),doB,SUCCEEDED



Rem,2005/01/20-8:00:00,BELIEF(true),SEQ(doA, doB),SUCCEEDED


Failure Example



Rem,2005/01/20-8:00:00,BELIEF(true),doA,ACTIVE


Failure Example



Rem,2005/01/20-8:00:00,BELIEF(true),doA,FAILED


Failure Example

Rem,2005/01/20-8:00:00,BELIEF(true),SEQ(doA, doB),FAILED

Rem,2005/01/20-8:00:00,BELIEF(true),doB,FAILED


AF-APL Interpreter Cycle

World

BeliefUpdate

Query

Perceptors

Actuators

Beliefs

Commitments

CommitmentManagement

Commitment Rules

Migrate?

Belief Management


Coding Agents in AF-APL


Coding AF-APL Agents

Deployed AF-APL Programs are stored in agent files (.agt)

Many agents share common code:

E.g. how to communicate with other agents; how to migrate to another agent platform

Code reuse is supported through the concept of an agent role.

A partial or full agent program that defines a coherent and related set of agent behaviours.

Stored in role files (.rle)

Can reference other roles (via a USE_ROLE construct)

Compiled into agent files (.agt) for deployment

The com.agentfactory.plugins.core.fipa.agent.Agent role specifies the default AF agent behaviour.


Modules

Modules define any internal functionality required by an agent.

Modules can hold data and can provide methods to manipulate that data.

They are implemented as instances of Java classes.

They extend the com.agentfactory.platform.interfaces.Module class.

The developer can implement an init(…) method.

The developer should implement custom methods as required.

Example Modules:

An internal queue (e.g. one that stores documents that have been found, but not yet processed, by a web spider agent).

A graphical interface that supports interaction with a user (e.g. a chat window).


Example Module

package ie.ucd.queue.module;

import ie.ucd.aflite.agent.Module;

import java.util.*;

public class QueueManagerModule extends Module {

private ArrayList queue = new ArrayList();

public synchronized boolean addToQueue(String item) {

boolean added = false;

if (!queue.contains(item)) {

queue.add(item);

added = true;

}

return added;

}


Example Module

public synchronized boolean removeFromQueue() {

boolean removed = false;

if (queue.size() > 0) {

queue.remove(0);

removed = true;

}

return removed;

}

public synchronized Object getQueueHead() {

return queue.get(0);

}

public synchronized int getQueueSize() {

return queue.size();

}

}


Perceptors

Perceptors define the beliefs that an agent can have about its environment.

They are fired once per agent cycle and generate beliefs about the current state of the agents environment.


They extend the com.agentfactory.platform.interfaces.Perceptor class and implement the perceive method.

Perceptors should use the adoptBelief(…) method to add beliefs to the agents mental state.

Example Perceptors:

Generate beliefs about the agents name.

Generate beliefs about what messages have been received since the message queue was last checked.


Example Perceptor

import java.net.*;

import java.util.Iterator;

import ie.ucd.aflite.agent.*;

public class QueuePerceptor extends Perceptor {

public void perceive() {

QueueModule module = (QueueModule) agent.getModuleByName(“queue”);

int size = module.getQueueSize();

adoptBelief("BELIEF(queueSize(" + size + "))");

if (size > 0) {

adoptBelief("BELIEF(queueHead(“ + module.getQueueHead() + "))");

}

}

}


Actuators

Actuators define the actions that an agent can perform.

They are fired whenever an agent attempts to realise a Commitment.


They extend the com.agentfactory.platform.interfaces.Actuator class and implement the act(…) method.

The constructor must specify the associated action identifier.

The method must return true or false to indicate whether or not the action was successfully executed.

Example Actions:

executing a search on Google.

making a robot move forwards.

sending a message.


Example Actuator

import ie.ucd.aflite.agent.Actuator;

import ie.ucd.aflite.agent.Agent;

import ie.ucd.aflite.logic.FOS;

public class AddToQueueActuator extends Actuator {

public AddToQueueActuator() {

super(“addToQueue(?item)”);

}

public void act(FOS action) {

String item = action.argAt(0).toString();

QueueModule module = (QueueModule) agent.getModuleByName(“queue”);

module.addToQueue(item);

return true;

}

}


Agent Role

Describes how the agent should behave.

Combines Actuators, Perceptors, and Modules with Commitment Rules and an Initial Mental State.

They are implemented in plain text.

Statements are semicolon (;) delimited.

The file can contain commitment rules that describe when to adopt new commitments.

The file can contain initial beliefs that the agent should have.

They can be aggregations of pre-existing roles (via the USE_ROLE construct).

Example Agent Designs:

E-Auctions: Auctioneer, Buyer, Seller

Knowledge Management: Searcher, Tracker, Analyser, Profiler, Indexer, Advertiser, Summariser, User.


Example Agent Design (qtest.rle)

// Modules

LOAD_MODULE queue module.QueueModule;

// Perceptors and Actuators

PERCEPTOR perceptor.QueuePerceptor;

ACTUATOR actuator.AddToQueueActuator;

// Initial Mental State

NEXT(BELIEF(add(honey)));

// Commitment Rules

BELIEF(add(?item)) =>

COMMIT(Self, Now, BELIEF(true), addToQueue(?item));


Compiling Agent Roles

An Agent Role defines a specific set of common behaviours that an agent may employ.

They are the Agent Factory equivalent of “.java” files.

Role files terminate with “.rle”

Role files may have dependencies with other Role files.

To deploy an agent-oriented application, we must first compile our Agent Roles into Agent Classes.

Agent classes are aggregations of roles

They contain a complete description of an agent.

Agent Class files terminate with “.agt”

Agent Class files depend only upon the respective Actuator, Perceptor and Module implementations.

You can compile role files into agent files using either NetBeans or at the command line using the afaplc compiler.


Example Agent File

/** Start of Import from role: ie.ucd.core.fipa.agent.Agent **/

/** Start of Import from role: ie.ucd.core.fipa.acl.agent.FIPACore **/

SERVICE_BIND fipa.mts.mtp.http.std;

ACTUATOR ie.ucd.aflite.actuator.AdoptActuator;

ACTUATOR ie.ucd.aflite.actuator.RetractActuator;

ACTUATOR ie.ucd.core.fipa.common.actuator.AddAgentIDActuator;

ACTUATOR ie.ucd.core.fipa.common.actuator.RemoveAgentIDActuator;

ACTUATOR ie.ucd.core.fipa.common.actuator.UpdateAIDActuator;

ACTUATOR ie.ucd.core.fipa.actuator.GenerateDFNameActuator;

ACTUATOR ie.ucd.core.fipa.actuator.SetDFNameActuator;

ACTUATOR ie.ucd.core.fipa.actuator.PlatformSpecificNameActuator;

ACTUATOR ie.ucd.core.fipa.acl.actuator.FIPAInformActuator;

ACTUATOR ie.ucd.core.fipa.acl.actuator.FIPARequestActuator;

ACTUATOR ie.ucd.core.fipa.acl.actuator.FIPAActionActuator;

PERCEPTOR ie.ucd.core.fipa.perceptor.SelfPerceptor;

PERCEPTOR ie.ucd.core.fipa.perceptor.PlatformPerceptor;

PERCEPTOR ie.ucd.core.fipa.common.perceptor.AcquaintancePerceptor;

PERCEPTOR ie.ucd.core.fipa.acl.perceptor.MessagePerceptor;

/** End of Import from role: ie.ucd.core.fipa.acl.agent.FIPACore **/

BELIEF(newAgentID(?name,?addresses)) => COMMIT(Self,Now,BELIEF(true),addAgentID(?name,?addresses));

BELIEF(fipaMessage(?perf,sender(?agt,?addresses),?content)) & !BELIEF(agentID(?agt,?addresses)) => COMMIT(Self,Now,BELIEF(true),addAgentID(?agt,?addresses));

BELIEF(fipaMessage(inform,?sender,agentID(?agent,?addresses))) & !BELIEF(agentID(?agent,?addresses)) => COMMIT(Self,Now,BELIEF(true),addAgentID(?agent,?addresses));

BELIEF(fipaMessage(inform,?sender,changedAID(?oldName,?name))) => COMMIT(Self,Now,BELIEF(true),updateAID(?oldName,?name));

BELIEF(platformName(?pfmName)) & !BELIEF(homeDF(?df)) & !BELIEF(noDFOfPlatform) & !BELIEF(gettingDFAID) => COMMIT(Self,Now,BELIEF(true),PAR(generateDFName(?pfmName),adoptBelief(ALWAYS(BELIEF(gettingDFAID)))));

BELIEF(dfName(?df)) & BELIEF(homeAMS(?ams)) => COMMIT(Self,Now,BELIEF(true),PAR(request(?ams,getAgentID(?df)),adoptBelief(ALWAYS(BELIEF(gettingDFName(?df))))));

BELIEF(gettingDFName(?df)) & BELIEF(agentID(?df,?addr)) => COMMIT(Self,Now,BELIEF(true),PAR(setDFName(?df),retractBelief(ALWAYS(BELIEF(gettingDFAID))),retractBelief(ALWAYS(BELIEF(gettingDFName(?df))))));

/** End of Import from role: ie.ucd.core.fipa.agent.Agent **/

ACTUATOR AddToQueueActuator;

PERCEPTOR QueuePerceptor;

LOAD_MODULE queue QueueModule;

BELIEF(wantToAdd(?item)) => COMMIT(Self,Now,BELIEF(true),addToQueue(?item));


Deploying Agent-Oriented Applications

Agent-Oriented Applications are deployed over one or more Agent Platforms.

Each agent platform implements a number of system agents: AMS – White Pages Service DF – Yellow pages Service SuperDF – Central Manager for all AMS and DF agents.

And a number of platform services: HTTP Message Transport Service (Agent Communication) Migration Service (Agent Migration)

For each Agent Platform, you must:

Define a Configuration: What Platform Services, the Agent ID of the Super DF, etc.

Write a Startup Script The initial community of agents.


Sample Configuration File: queue.cfg

// The platform domain and name

PLATFORM_DOMAIN domain.tld

PLATFORM_NAME host

// This is the instantiation of the FIPA HTTP Message Transport Service

// The parameter at the end (4444) denotes the port on which the service is listening.

// Changing this number will allow the service to be set up on alternate ports.

SERVICE fipa.mts.mtp.http.std com.agentfactory.plugins.services.mts_http.HTTPMessageTransportService 4444

SERVICE af.rcs.std com.agentfactory.plugins.services.rcs.RemoteCommandService 5050 6001

// The SuperDF agent provides support for the federation of yellow and white pages services

// across a number of agent platforms. The line below specifies the platform should start

// a Super DF agent called "SuperDF"

SUPER_DF SuperDF

// For federating agent platforms, it is vital that you specify which Super DF your AMS and

// DF agents should use. The line below specifies this. Please note that the address must

// map onto the same port number as the agent platform that is hosting the Super DF agent.

PRIMARY_SUPERDF SuperDF addresses(http://localhost:4444/acc)


Sample Configuration File: queue.cfg

// Is a directory facilitator required on this platform?

DIRECTORY_FACILITATOR yes

// Language Specific Plugins

// ===========================================================

// Stuff for the AF-APL programming langauge

AGENT_INTERPRETER com.agentfactory.plugins.interpreters.afapl.AFAPLAgent agt SLEEPTIME=500 THREADING=false

AGENT_GUI com.agentfactory.plugins.gui.afapl.JAgentGUI agt

// Stuff for the ALPHA programming language -- Comment out if ALPHA isn't needed

AGENT_INTERPRETER com.agentfactory.plugins.interpreters.alpha.ALPHAAgent alpha

AGENT_GUI com.agentfactory.plugins.gui.alpha.swing.agent.JALPHAAgentGUI alpha


Sample Script: queue.aps

// PLATFORM_CONFIGURATION <file>

PLATFORM_CONFIGURATION queue.cfg

// CREATE_AGENT <name> <type>

CREATE_AGENT Rem qtest.agt

// START_AGENT <name>


Adding Communication into the Mix

Inter-agent communication is an essential feature of multi-agent systems.

Agent Factory includes a pre-specified role, that implements support for the FIPA-Agent Communication Language (ie.ucd.core.fipa.agent.Agent).

This support includes:

MessagePerceptor - monitors an internal module for new messages[BELIEF(fipaMessage(?performative, sender(?agt, ?addresses), ?content))]

FIPAInformActuator – informs another agent of some content[inform(?name, ?content)] or [inform(agentID(?name, ?addr), ?content)]

FIPARequestActuator – requests that another agent perform some activity[request(?name, ?activity)] or [request(agentID(?name, ?addr), ?activity)].

To use this support, simply include the role (it is part of the af_core.jar package that comes pre-packaged with Agent Factory).


Example Agent Design (qtest2.rle)

USE_ROLE com.agentfactory.plugins.core.fipa.agent.Agent;

// Modules

LOAD_MODULE queue module.QueueModule;

// Perceptors and Actuators

PERCEPTOR perceptor.QueuePerceptor;

ACTUATOR actuator.AddToQueueActuator;

// Initial Mental State

NEXT(BELIEF(add(honey)));

// Commitment Rules

BELIEF(add(?item)) & BELIEF(queueAgent(?agt, ?addr)) =>

COMMIT(Self, Now, BELIEF(true), request(agentID(?agt, ?addr), addItem(?item)));

BELIEF(fipaMessage(request, sender(?agt, ?addr), addItem(?item))) =>

COMMIT(Self, Now, BELIEF(true), addToQueue(?item));


Sample Script: queue2.aps

PLATFORM_CONFIGURATION queue.cfg

CREATE_AGENT Rem qtest2.agt

CREATE_AGENT Bob qtest2.agt

ADD_BELIEF Rem ALWAYS(BELIEF(queueAgent(Bob, addresses(http://localhost:4444/acc))))


Downloading Agent Factory

You can download the latest version (for you only) from:

http://www.agentfactory.com/ums

The NetBeans plugin can be downloaded from:

http://www.agentfactory.com/netbeans

To use Agent Factory, you will need to set the following environment variables:

AF_HOME = location of the base agentfactory-0.2.0 folder

JAVA_HOME = location of a Java 2 SDK

PATH = add the location of %AF_HOME%\bin

An example BAT file can be found at http://www.agentfactory.com/ums

To run Agent Factory, type:

“agentfactory –config queue.cfg –script queue.aps”

Typing “afgui” will start up the remote management interface (you will have to configure a site).

agent-oriented & distributed software systems dr rem collier [email protected]

Documents

deployment of agent

agent factory summary

agent oriented languages

development methodology

hybrid agent architecture

multiagent systems ceemas03

ceemas03 slide

oriented applications