Agent-Oriented & Distributed Software Systems Dr Rem Collier

2003 © ChangingWorlds Ltd. Week 2: Agent Factory (2 hours)

2003 © ChangingWorlds Ltd. Selected Reading All of these papers can be found on the 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, 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.COORDINATION 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.CEEMAS'03

2003 © ChangingWorlds Ltd. What is Agent Factory?

2003 © ChangingWorlds Ltd. What is Agent Factory? Agent Factory is…a cohesive framework that delivers structured support for the development and deployment of agent-oriented applications.

2003 © ChangingWorlds Ltd. What is Agent Factory? 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 Run-Time Environment Development Environment Software Engineering Methodology

2003 © ChangingWorlds Ltd. What is Agent Factory? 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 Declarative Formalised through a Multi-modal logic Agent-specific Constructs Run-Time Environment Development Environment Software Engineering Methodology

2003 © ChangingWorlds Ltd. What is Agent Factory? 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 Run-Time Environment Distributed FIPA Compliant Agent Platforms + Infrastructure System Agents: AMS + DF Development Environment Software Engineering Methodology

2003 © ChangingWorlds Ltd. The Run-Time Environment Remote Management Interface Remote Command Shell Command Line Interface

2003 © ChangingWorlds Ltd. What is Agent Factory? 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 Run-Time Environment Development Environment AF-APL Compiler Netbeans & Eclipse Plugins VIPER – Protocol Editor Software Engineering Methodology

2003 © ChangingWorlds Ltd. AF NetBeans Plugin

2003 © ChangingWorlds Ltd. VIPER – Visual Protocol Editor

2003 © ChangingWorlds Ltd. What is Agent Factory? 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 Run-Time Environment Development Environment Software Engineering Methodology

2003 © ChangingWorlds Ltd. Development Methodology

2003 © ChangingWorlds Ltd. What is Agent Factory? 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 Run-Time Environment Development Environment Software Engineering Methodology Implemented in Java Personal Java, J2ME and J2SE-Compliant Deployed on PDAs / PCs Open Source: Downloadable from

2003 © ChangingWorlds Ltd. Applications Ubiquitous Computing & M-Commerce. Agent Factory has been employed to deliver a number of location aware services for hand-held devices. Gullivers Genie, WAY System, E=mc 2, 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

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. The AF-APL Language

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. AF-APL AF-APL Programs define: Actuators Perceptors Modules Commitment Rules Initial Mental State

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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))

2003 © ChangingWorlds Ltd. 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))

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. Commitment States

2003 © ChangingWorlds Ltd. Commitment Structure Example Rem, 2005/01/20-8:00:00, BELIEF(true), SEQ(doA, doB), INACTIVE

2003 © ChangingWorlds Ltd. Commitment Structure Example 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

2003 © ChangingWorlds Ltd. Commitment Structure Example 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, ACTIVE

2003 © ChangingWorlds Ltd. Commitment Structure Example 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, SUCCEEDED

2003 © ChangingWorlds Ltd. Commitment Structure Example Rem, 2005/01/20-8:00:00, BELIEF(true), SEQ(doA, doB), PLANNED Rem, 2005/01/20-8:00:00, BELIEF(true), doB, INACTIVE

2003 © ChangingWorlds Ltd. Commitment Structure Example Rem, 2005/01/20-8:00:00, BELIEF(true), SEQ(doA, doB), PLANNED Rem, 2005/01/20-8:00:00, BELIEF(true), doB, ACTIVE

2003 © ChangingWorlds Ltd. Commitment Structure Example Rem, 2005/01/20-8:00:00, BELIEF(true), SEQ(doA, doB), PLANNED Rem, 2005/01/20-8:00:00, BELIEF(true), doB, SUCCEEDED

2003 © ChangingWorlds Ltd. Commitment Structure Example Rem, 2005/01/20-8:00:00, BELIEF(true), SEQ(doA, doB), SUCCEEDED

2003 © ChangingWorlds Ltd. Failure Example 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, ACTIVE

2003 © ChangingWorlds Ltd. Failure Example 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, FAILED

2003 © ChangingWorlds Ltd. 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

2003 © ChangingWorlds Ltd. AF-APL Interpreter Cycle World Belief Update Query Perceptors Actuators Beliefs Commitments Commitment Management Commitment Rules Migrate? Belief Management

2003 © ChangingWorlds Ltd. Coding Agents in AF-APL

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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).

2003 © ChangingWorlds Ltd. 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; }

2003 © ChangingWorlds Ltd. 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(); }

2003 © ChangingWorlds Ltd. 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 are implemented as instances of Java classes. 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.

2003 © ChangingWorlds Ltd. 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() + "))"); }

2003 © ChangingWorlds Ltd. Actuators Actuators define the actions that an agent can perform. They are fired whenever an agent attempts to realise a Commitment. They are implemented as instances of Java classes. 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.

2003 © ChangingWorlds Ltd. 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; }

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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));

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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));

2003 © ChangingWorlds Ltd. 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.

2003 © ChangingWorlds Ltd. 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 // 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(

2003 © ChangingWorlds Ltd. 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

2003 © ChangingWorlds Ltd. Sample Script: queue.aps // PLATFORM_CONFIGURATION PLATFORM_CONFIGURATION queue.cfg // CREATE_AGENT CREATE_AGENT Rem qtest.agt // START_AGENT

2003 © ChangingWorlds Ltd. 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).

2003 © ChangingWorlds Ltd. 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));

2003 © ChangingWorlds Ltd. 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(

2003 © ChangingWorlds Ltd. Downloading Agent Factory You can download the latest version (for you only) from: The NetBeans plugin can be downloaded from: To use Agent Factory, you will need to set the following environment variables: AF_HOME = location of the base agentfactory 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 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).