Agent Oriented

1
Agent-Oriented Distributed Software Systems
Dr Rem Collier rem.collier_at_ucd.ie
2
Week 2 Agent Factory (2 hours)
3
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.

4
What is Agent Factory?
5
What is Agent Factory?

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

6
What is Agent Factory?

• Organised over four layers
• Programming Language
• Run-Time Environment
• Development Environment
• Software Engineering Methodology

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

7
What is Agent Factory?

• Organised over four layers
• Programming Language
• Declarative
• Formalised through a Multi-modal logic
• Agent-specific Constructs
• Run-Time Environment
• Development Environment
• Software Engineering Methodology

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

8
What is Agent Factory?

• Organised over four layers
• Programming Language
• Run-Time Environment
• Distributed
• FIPA Compliant
• Agent Platforms Infrastructure
• System Agents AMS DF
• Development Environment
• Software Engineering Methodology

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

9
The Run-Time Environment
Command Line Interface
Remote Management Interface
Remote Command Shell
10
What is Agent Factory?

• Organised over four layers
• Programming Language
• Run-Time Environment
• Development Environment
• AF-APL Compiler
• Netbeans Eclipse Plugins
• VIPER Protocol Editor
• Software Engineering Methodology

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

11
AF NetBeans Plugin
12
VIPER Visual Protocol Editor
13
What is Agent Factory?

• Organised over four layers
• Programming Language
• Run-Time Environment
• Development Environment
• Software Engineering Methodology

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

14
Development Methodology
15
What is Agent Factory?

• 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 http//agentfactory.sourceforge.
  net

• Agent Factory isa cohesive framework that
  delivers structured support for the development
  and deployment of agent-oriented applications.

16
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, Emc2, 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

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

18
The AF-APL Language
19
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.

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

21
AF-APL

• AF-APL Programs define

• Actuators

• Perceptors

• Modules

• Commitment Rules

• Initial Mental State

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

23
Belief Management

• Belief Management Belief Update Belief Query

24
Belief Management

• Belief Management Belief Update Belief Query

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

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

27
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)) gt
  BELIEF(want(?food))
• BELIEF(has(rem, icecream)) gt 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.

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

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

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

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

32
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)) gt 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.

33
Commitment Maintenance

• Commitments are maintained using a maintenance
  condition that is associated with each
  commitment.
• E.g. BELIEF(has(?food)) gt 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.

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

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

36
Commitment States
37
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), INACTIVE
38
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, WAITIN
G
Rem, 2005/01/20-80000, BELIEF(true), doA, INACTI
VE
39
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, WAITIN
G
Rem, 2005/01/20-80000, BELIEF(true), doA, ACTIVE
40
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, WAITIN
G
Rem, 2005/01/20-80000, BELIEF(true), doA, SUCCEE
DED
41
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, INACTI
VE
42
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, ACTIVE
43
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, SUCCEE
DED
44
Commitment Structure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), SUCCEEDED
45
Failure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, WAITIN
G
Rem, 2005/01/20-80000, BELIEF(true), doA, ACTIVE
46
Failure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), PLANNED
Rem, 2005/01/20-80000, BELIEF(true), doB, WAITIN
G
Rem, 2005/01/20-80000, BELIEF(true), doA, FAILED
47
Failure Example
Rem, 2005/01/20-80000, BELIEF(true), SEQ(doA,
doB), FAILED
Rem, 2005/01/20-80000, BELIEF(true), doB, FAILED
48
AF-APL Interpreter Cycle
Belief Management
Belief Update
Perceptors
World
Query
Beliefs
Commitment Management
Migrate?
Actuators
Commitment Rules
Commitments
49
Coding Agents in AF-APL
50
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.

51
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.interfac
  es.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).

52
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

53
Example Module

• public synchronized boolean removeFromQueue()
• boolean removed false
• if (queue.size() gt 0)
• queue.remove(0)
• removed true
• return removed
• public synchronized Object getQueueHead()
• return queue.get(0)
• public synchronized int getQueueSize()
• return queue.size()

54
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.interfac
  es.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.

55
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 gt 0)
• adoptBelief("BELIEF(queueHead(
  module.getQueueHead() "))")

56
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.interfac
  es.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.

57
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

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

59
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)) gt
• COMMIT(Self, Now, BELIEF(true),
  addToQueue(?item))

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

61
Example Agent File

• / Start of Import from role ie.ucd.core.fipa.ag
  ent.Agent /
• / Start of Import from role ie.ucd.core.fipa.ac
  l.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.AddAgent
  IDActuator
• ACTUATOR ie.ucd.core.fipa.common.actuator.RemoveAg
  entIDActuator
• ACTUATOR ie.ucd.core.fipa.common.actuator.UpdateAI
  DActuator
• ACTUATOR ie.ucd.core.fipa.actuator.GenerateDFNameA
  ctuator
• ACTUATOR ie.ucd.core.fipa.actuator.SetDFNameActuat
  or
• ACTUATOR ie.ucd.core.fipa.actuator.PlatformSpecifi
  cNameActuator
• ACTUATOR ie.ucd.core.fipa.acl.actuator.FIPAInformA
  ctuator
• ACTUATOR ie.ucd.core.fipa.acl.actuator.FIPARequest
  Actuator
• ACTUATOR ie.ucd.core.fipa.acl.actuator.FIPAActionA
  ctuator
• PERCEPTOR ie.ucd.core.fipa.perceptor.SelfPerceptor
  
• PERCEPTOR ie.ucd.core.fipa.perceptor.PlatformPerce
  ptor
• PERCEPTOR ie.ucd.core.fipa.common.perceptor.Acquai
  ntancePerceptor
• PERCEPTOR ie.ucd.core.fipa.acl.perceptor.MessagePe
  rceptor

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

63
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.plu
  gins.services.mts_http.HTTPMessageTransportService
  4444
• SERVICE af.rcs.std com.agentfactory.plugins.servic
  es.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)

64
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.interpr
  eters.afapl.AFAPLAgent agt SLEEPTIME500
  THREADINGfalse
• AGENT_GUI com.agentfactory.plugins.gui.afapl.JAgen
  tGUI agt
• // Stuff for the ALPHA programming language --
  Comment out if ALPHA isn't needed
• AGENT_INTERPRETER com.agentfactory.plugins.interpr
  eters.alpha.ALPHAAgent alpha
• AGENT_GUI com.agentfactory.plugins.gui.alpha.swing
  .agent.JALPHAAgentGUI alpha

65
Sample Script queue.aps

• // PLATFORM_CONFIGURATION ltfilegt
• PLATFORM_CONFIGURATION queue.cfg
• // CREATE_AGENT ltnamegt lttypegt
• CREATE_AGENT Rem qtest.agt
• // START_AGENT ltnamegt

66
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.Age
  nt).
• This support includes
• MessagePerceptor - monitors an internal module
  for new messagesBELIEF(fipaMessage(?performative
  , sender(?agt, ?addresses), ?content))
• FIPAInformActuator informs another agent of
  some contentinform(?name, ?content) or
  inform(agentID(?name, ?addr), ?content)
• FIPARequestActuator requests that another agent
  perform some activityrequest(?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).

67
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)) gt
• COMMIT(Self, Now, BELIEF(true),
  request(agentID(?agt, ?addr), addItem(?item)))
• BELIEF(fipaMessage(request, sender(?agt, ?addr),
  addItem(?item))) gt
• COMMIT(Self, Now, BELIEF(true),
  addToQueue(?item))

68
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//localhost4444/acc))))

69
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).