Agent Infrastructure

1
Agent Infrastructure

• Michael Luck
• University of Southampton, UK

2
Part I

• The Case for Agent-Oriented Software Engineering
• with slides borrowed from Nick Jennings

3
Remote Agent Experiment (RAX)

• Deep Space One mission to validate technologies
• AI software in primary command of a spacecraft

4
RAX

• Comprises
• planner/scheduler to generate plans for general
  mission goals
• smart executive to execute plans
• Mode identification and recovery to detect
  failures
• Goals not pre-planned so more flexible
• Tests include simulated failures
• Tests in May 1999

5
Agents

• Relatively new field (10-15 years?)
• Dramatic growth
• Popularity
• Increasing numbers of applications
• Multi-disciplinary
• Problems
• Agent backlash?
• Sound conceptual foundation?

6
Agent-Based Computing A New Synthesis for AI and
CS

• Increasing number of systems viewed in terms of
  agents
• as a theoretical model of computation
• more closely reflects current computing reality
  than Turing Machines
• as a model for engineering distributed software
  systems
• better suited than object-orientation, design
  patterns and software architectures
• as a model for conceptualising and building
  intelligent entities
• framework for unifying piecemeal specialisations

7
Which Perspective?

• Answer from many points of view from
  philosophical to pragmatic
• Proceed from standpoint of using agent-based
  software to solve complex, real-world problems

8
Software Development is Difficult

• One of most complex construction task humans
  undertake
• Computer science is the first engineering
  discipline ever in which the complexity of the
  objects created is limited by the skill of the
  creator and not limited by the strength of the
  raw materials. If steel beams were infinitely
  strong and couldnt ever bend no matter what you
  did, then skyscrapers could be as complicated as
  computers. Brian K. Reid
• True whatever models and techniques are applied
• the essential complexity of software Fred
  Brooks
• Software engineering provides models techniques
  that make it easier to handle this essential
  complexity

9
Software Development is Getting Harder

• Shorter development lifecycles
• More ambitious requirements
• Less certain requirements
• Greater scope for change
• More challenging environments
• Greater dynamism
• Greater openness

10
Software Engineering Continually Playing Catch Up

• Better Models
• components
• design patterns
• software architectures

• Better Processes
• light methods
• heavier methods

• interacting agents

Our ability to imagine complex applications will
always exceed our ability to develop
them Grady Booch
11
The Adequacy Hypothesis

• Agent-oriented approaches can enhance our ability
  to model, design and build complex distributed
  software systems.

12
The Essence of Agent-Based Computing
13
Agent

• encapsulated computer system, situated in some
  environment, and capable of flexible autonomous
  action in that environment in order to meet its
  design objectives (Wooldridge)

14
Agent

• encapsulated computer system, situated in some
  environment, and capable of flexible autonomous
  action in that environment in order to meet its
  design objectives (Wooldridge)

• control over internal state and over own behaviour

15
Agent

• encapsulated computer system, situated in some
  environment, and capable of flexible autonomous
  action in that environment in order to meet its
  design objectives (Wooldridge)

• control over internal state and over own behaviour

• experiences environment through sensors and acts
  through effectors

16
Agent

• encapsulated computer system, situated in some
  environment, and capable of flexible autonomous
  action in that environment in order to meet its
  design objectives (Wooldridge)

• control over internal state and over own behaviour

• experiences environment through sensors and acts
  through effectors

• reactive respond in timely fashion to
  environmental change
• proactive act in anticipation of future goals

17
Definitional Malaise

• My guess is that object-oriented programming
  will be what structured programming was in the
  1970s. Everybody will be in favour of it. Every
  manufacturer will promote his product as
  supporting it. Every manager will pay lip service
  to it. Every programmer will practice it
  (differently). And no one will know just what it
  is. (Rentsch, 82)

• My guess is that agent-based computing will be
  what object-oriented programming was in the
  1980s. Everybody will be in favour of it. Every
  manufacturer will promote his product as
  supporting it. Every manager will pay lip service
  to it. Every programmer will practice it
  (differently). And no one will know just what it
  is. (Jennings, 00)

18
Multiple Agents

• In most cases, single agent is insufficient
• no such thing as a single agent system (!?)
• multiple agents are the norm, to represent
• natural decentralisation
• multiple loci of control
• multiple perspectives
• competing interests

19
Agent Interactions

• Interaction between agents is inevitable
• to achieve individual objectives, to manage
  inter-dependencies
• Conceptualised as taking place at knowledge-level
  
• which goals, at what time, by whom, what for
• Flexible run-time initiation and responses
• cf. design-time, hard-wired nature of extant
  approaches

paradigm shift from previous perceptions of
computational interaction
20
Organisations

• Agents act/interact to achieve objectives
• on behalf of individuals/companies
• part of a wider problem solving initiative
• underlying organisational relationship
  between the agents

21
Organisations

• This organisational context
• influences agents behaviour
• relationships need to be made explicit
• peers
• teams, coalitions
• authority relationships
• is subject to ongoing change
• provide computational apparatus for creating,
  maintaining and disbanding structures

22
A Canonical View
Agent
Interactions
Organisational relationships
Environment
Sphere of influence
(see also Castelfranchi, Ferber, Gasser, Lesser,
..)
23
Making the Case Quantitatively
There are 3 kinds of lies lies, damned lies and
statistics Disraeli
24
Making the Case Qualitatively
Software techniques for tackling complexity
25
Tackling Complexity

• Decomposition
• Abstraction
• Organisation

26
Making the Case Qualitatively
Software techniques for tackling complexity
Nature of complex systems
27
Complex Systems

• Complexity takes form of hierarchy
• not a control hierarchy
• collection of related sub-systems at different
  levels of abstraction
• Can distinguish between interactions among
  sub-systems and interactions within sub-systems
• latter more frequent predictable nearly
  decomposable systems
• Arbitrary choice about which components are
  primitive
• Systems that support evolutionary growth develop
  more quickly than those that do not stable
  intermediate forms

(Herb Simon)
28
Making the Case Qualitatively
Software techniques for tackling complexity
Agent-based computing
Nature of complex systems
29
Making the Case Qualitatively
Software techniques for tackling complexity
Agent-based computing
Degree of Match
Nature of complex systems
30
The Match Process

• 1. Show agent-oriented decomposition is effective
  way of partitioning problem space of complex
  system
• 2. Show key abstractions of agent-oriented
  mindset are
• natural means of modelling complex systems

31
The Match Process

• 1. Show agent-oriented decomposition is effective
  way of partitioning problem space of complex
  system
• 2. Show key abstractions of agent-oriented
  mindset are
• natural means of modelling complex systems

32
Decomposition Agents

• In terms of entities that have
• own persistent thread of control (active say
  go)
• control over their own destiny (autonomous say
  no)
• Makes engineering of complex systems easier
• natural representation of multiple loci of
  control
• real systems have no top (Meyer)
• allows competing objectives to be represented and
  reconciled in context sensitive fashion

33
Decomposition Interactions

• Agents make decisions about nature scope of
  interactions at run time
• Makes engineering of complex systems easier
• unexpected interaction is expected
• not all interactions need be set at design time
• simplified management of control relationships
  between components
• coordination occurs on as-needed basis between
  continuously active entities

34
The Match Process

• 1. Show agent-oriented decomposition is effective
  way of partitioning problem space of complex
  system
• 2. Show key abstractions of agent-oriented
  mindset are
• natural means of modelling complex systems

?
35
Suitability of Abstractions

• Design is about having right models
• In software, minimise gap between units of
  analysis and constructs of solution paradigm
• OO techniques natural way of modelling world

36
(No Transcript)
37
(No Transcript)
38
(No Transcript)
39
(No Transcript)
40
(No Transcript)
41
The Adequacy Hypothesis

• Agent-oriented approaches can enhance our ability
  to model, design and build complex distributed
  software systems.

?
42
The Establishment Hypothesis

• As well as being suitable for designing and
  building complex systems,
• agents will succeed as a software engineering
  paradigm

NB will be complementary to existing software
models like OO, patterns, components,
43
Agents Consistent with Trends in Software
Engineering

• Conceptual basis rooted in problem domain
• world contains autonomous entities that interact
  to get things done

44
Agents Consistent with Trends in Software
Engineering

• Conceptual basis rooted in problem domain
• Increasing localisation and encapsulation
• apply to control, as well as state and behaviour

45
Agents Consistent with Trends in Software
Engineering

• Conceptual basis rooted in problem domain
• Increasing localisation and encapsulation
• Greater support for re-use of designs and
  programs
• whole sub-system components (cf. components,
  patterns)
• e.g. agent architectures, system structures
• flexible interactions (cf. patterns,
  architectures)
• e.g. contract net protocol, auction protocols

46
Agents Support System Development by Synthesis

• An agent is a stable intermediate form
• able to operate to achieve its objectives and
  interact with others in flexible ways
• construct system by bringing agents together
  and watching overall functionality emerge from
  their interplay
• well suited to developments in
• open systems (e.g. Internet)
• e-commerce

47
Conclusions

• Agents are a new model of computation
• Basic concepts are
• Agents
• Interactions
• Organisations
• Agents well suited to developing complex
  distributed applications

48
Further Reading

• M. Luck, P. McBurney and C. Preist (2003) Agent
  Technology Enabling Next Generation Computing (A
  Roadmap for Agent Based Computing), AgentLink,
  2003.
• N. R. Jennings (2000) On Agent-Based Software
  Engineering Artificial Intelligence, 117 (2)
  277-296.
• H. S. Nwana (1996) Software Agents An Overview
  The Knowledge Engineering Review, 11 (3).
• M. Luck, R. Ashri, M. dInverno (2004)
  Agent-Based Software Development, Artech House,
  2004.

49
Part II

• Conceptual Infrastructure
• The SMART Agent Framework
• with
• Mark dInverno, University of Westminster, UK

50
The SMART View Objects
51
Agents
52
Autonomous Agents
53
Conceptual Infrastructure
Structured, Modular Agent and Relationship Types
(SMART)
Entities
Objects

• Entities have attributes
• Objects are entities with capabilities
• Agents are objects with goals
• Autonomous agents are agents able to generate
  their own goals (based on motivations)

Agents
Autonomous Agents
54
Entities

• Abstraction with
• Actions
• Attributes
• Goals
• Motivations

55
Objects, Agents, Autonomous Agents

• Objects are entities with non-empty actions
• Agents are objects with non-empty goals
• Autonomous Agents are agents with non-empty
  motivations

56
Motivation

• Motivations give rise to goals
• Greed
• Hunger
• Etc
• Robbing a bank greed
• The why as opposed to the what

57
Engagement

• One agent satisfies the goals of another
• Can build up chains of engagements
• Autonomous agent at head of chain
• Cooperation involves two autonomous agents

58
Relationships

• Ownership
• When no others engage an agent
• Direct ownership
• When no chain is involved
• Other categories are possible

59
Understanding Agent Systems
60
Part III

• Technical Infrastructure
• Agent Implementation through Jini
• with
• Ronald Ashri, University of Southampton, UK

61
Overview

• Goals and roadblocks
• Required solutions
• What is infrastructure support for agent-based
  systems?
• A layered approach to infrastructure
• Intelligent agents, mobile agents and middleware
• Concept-centred view of agent development
• Paradigma Jini-based agent system
• Further Work

62
Goals

• Integration of services
• Effective information management
• Intelligent Environments at work, home and in the
  community
• Minimised workload
• Optimised resource handling
• More fun in life!

63
Example Ambient Intelligence
The game is starting in 5 min.
Milk is out of date
Home Community
There is an urgent mail!
Hi, I am a new mobile phone
Autonomous Agent
Just let me know how you would like me to take
care of things.
64
Roadblocks

• A multitude of computing environments
  (workstations, embedded, mobile)
• A multitude of platforms (Windows, Unix/Linux,
  Macintosh, OS/2, PalmOS, legacy,)
• Different applications for every task, little
  integration, too much work expected from the user
  (direct manipulation).
• Complex administration

65
Required Solutions

• Move from static to dynamic networks
• Online Communities
• Dynamic registration of new devices and software
• Fault-tolerance
• Move from object-oriented to agent-oriented
  software engineering
• Co-ordination amongst software components
• Delegation of tasks and task sharing
• Autonomous behaviour

66
How to provide such solutions

• Middleware technologies to create the appropriate
  environment
• Many candidates
• Service Location Protocol
• Salutation
• UPnP
• E-Speak
• Jini
• All still fairly new but there is progress and
  reasons to be hopeful

67
Solutions Frameworks for agent-based systems

• A framework should...
• Provide meanings for common concepts
• Enable comparison and evaluation of alternative
  designs
• Provide for subsequent refinement and development
• Challenge is to provide a framework with a strong
  conceptual base that can be practically
  implemented!

68
Solutions Design principles

• A common structure for both practical and
  theoretical development of agent research
• Use of existing technologies (Java, XML),
  especially as it refers to the environment (Jini
  middleware)
• Extensibility that will allow for the natural
  evolution of the framework

69
Infrastructure support for agent-based systems
Basic building blocks required for the
development and deployment of an application
Aim is support for agent-based systems not
general distributed systems. Agent infrastructure
should touch upon lower-level issues as well as
higher-level.
70
Heterogeneous Environments
LAN
Internet
Gateway
Network Community
LAN
Internet
cellular network
LAN
short range wireless
bluetooth
71
Research Fields

• Middleware
• network protocols
• reflection
• access policies
• discovery
• security

• Intelligent Agents
• reasoning
• negotiation
• coalition
• formation
• autonomy
• security

• resource control
• optimization
• state migration
• security
• Mobile Agents

• code
• mobility
• binding

• communication
• coordination

72
Infrastructure Layers
intelligent agents (goal-directed, autonomous
operation)
mobile agents (resource optimization)
middleware (registration, discovery)
73
Framework Centered View
Capabilities, Attributes, Goals, Plans,
Motivations
Application Developer Concern
Domain specific capabilities
Infrastructure support capabilities
Agent Program
Agent Relationship Types (Agent Framework)
Agent Execution Environment
Middleware
Programming Language Support
OS Networking
74
Conceptual Infrastructure
Structured, Modular Agent and Relationship Types
(SMART)
Entities

• Entities have attributes
• Objects are entities with capabilities
• Agents are objects with goals
• Autonomous agents are agents able to generate
  their own goals (based on motivations)

Objects
Agents
Autonomous Agents
75
PARADIGMA/ actSMART

• Infrastructure that provides base agent concepts
  to ground development of specific systems without
  starting from scratch (conceptually), but .
• Infrastructure that avoids forcing a developer to
  commit to a particular agent architecture
• Infrastructure that facilitates clean separation
  of agent behaviour from agent description, and
  promotes modularity of agent construction

76
Technical Infrastructure

• XML for agent specification
• XML separates agent function from agent
  description
• No specialised tools required and enables the
  creation of agent libraries
• XML could, eventually, be used for agent
  packaging to allow mobility. A far less costly
  mechanism for serialisation when compared to the
  Java mechanism.
• Jini as the network environment
• Ready Java-based implementation
• Source available and well supported through Jini
  community (www.jini.org)
• Based on lookup, discovery, join, entries,
  leasing and transactions

77
Overview
Network Communications (TCP/IP)
78
Technical Infrastructure
Capabilities, Attributes, Goals, Plans,
Motivations
Domain specific capabilities
Message Manager
Ontology Engine
Registration
Goal Selection
Plan Selection
Event Listener

XML-based Serialization/Deserialization
Resource Access Control
Dynamic Linking

Jini Java Unix TCP/IP
79
Jini as the network environment
80
Technical Infrastructure Jini

• Agent discovery through lookup and join
• Agent description using entries
• Agent management via leasing
• Information sharing can be done using Javaspaces
  (Linda-like tuple-space)

81
Conceptual Infrastructure SMART

• Some further definitions
• Server Agents - Those agents that are not
  autonomous
• Neutral Objects - Those objects that are not
  agents
• These definitions allow for more dynamic
  behaviour
• Once a neutral object is assigned a goal it
  becomes a server agent
• When a goal is satisfied it reverts to a neutral
  object
• This is a possible solution to the issue of
  agentification (Shoham, 93)
• Many more issues covered (interactions, planning,
  cooperation)

82
Paradigma Using Neutral Objects
83
Paradigma Different Execution Models

• Execution on servers JVM (Remote sensor
  interfaces)
• Execution on clients JVM (New capabilities for
  engaging agent, network monitoring)
• Execution on both client and server (Smart proxy)
• Allows for efficient use of computing resources

84
Paradigma Entity Relationship
AbstractObject
implements
NeutralObject
uses
ServerAgent
implements
extends
Agent
instatiates
AutoAgent
implements
85
PARADIGMA

• XML is used to describe agents (in terms of
  attributes, capabilities, goals, etc)
• Description are parsed to create component
  collections that are linked via infrastructure
  support and domain-specific capabilities
• Agent constructors carry necessary information
  for agent infrastructure and domain-specific
  capability needs
• Capabilities can be dynamically loaded
• Agent creation and operation are separate
• Currently, Jini is used for agent discovery

86
Paradigma Architecture
87
PARADIGMA

• Decoupling agent behaviour and description
• Helps deal with environmental constraints
  behaviours can vary to suit executing
  environments while behaviours remain the same
• Flexibility in evaluation - alternative
  algorithms (behaviours) can be applied to the
  same descriptions, and be clearly evaluated
  against each other
• Provides alternative forms of mobility
• Enables libraries of agent components
  (attributes, capabilities, plans, goals)

88
Conclusions

• A layered approach maximizes inter-domain
  transfer
• It can employ existing technologies, rather than
  competing with them, engaging user and developer
  communities
• By placing the agent framework at the centre we
  focus on agent issues and better relate them to
  non-agent issues
• Paradigma adopts this approach
• Through Paradigma, SMART is instantiated,
  evaluated and refined

89
Further Work

• Apply Paradigma to significant real world
  problems for further evaluation
• Develop conceptual infrastructure to support
  other issues eg. mobility
• Dynamic self modification of capabilities
  conceptual and technical development
• http//www.ecs.soton.ac.uk/ra00r/paradigma

90
Part III

• Applied Infrastructure
• Agent Construction for Mobile Devices
• with
• Ronald Ashri, University of Southampton, UK

91
Overview

• Challenges for agent development on mobile
  devices
• Desiderata for an agent construction model
• Agent Construction Model
• Example Implementation
• Conclusions

92
Challenges

• Standard challenges
• Heterogeneity
• Dynamicity
• Diverse Application Domains
• Mobile devices add
• Memory, storage, processing power, operating
  power limitations
• Unstable network connectivity
• Different devices for different tasks/trips
• Operating through changing organisational domains

93
Desiderata

• Agent construction framework that is able to deal
  with these challenges through
• Architecture neutrality
• Modularity
• Powerful reconfiguration (at run-time when
  possible)

94
Architecture Neutrality

• Developers need to produce agent-based solutions
  for a range of application domains
• Constraining a developer to one specific
  architecture (e.g. BDI) is not practical
• Providing a really good generic architecture
  doesnt work either
• Agent construction model must be architecturally
  neutral

95
SMART

• Provides the underlying theoretical approach
• It is already architecturally neutral
• Has been used to describe a range of agent
  architectures
• However, deals only with the description of agent
  systems not their construction

96
Descriptive Specification (SMART)

• What an agent is and does
• Attributes
• Capabilities
• Goals
• Motivations

PDA Storage 64 MB Connectivity 802.11b Owner
Ronald Ashri --- Join Research Group Receive
messages from other agents Negotiate
meetings Notify User --- Arrange a meeting with
Mike --- Keep meetings as short as possible
97
Structural Specification

• The main building blocks of the agent
• Sensors
• Actuators
• Controllers
• Infostores
• Each component is described with attributes
  (stateless and situation) and capabilities

User Preferences Infostore
Incoming Message Sensor
Message Mailbox Infostore
Meetings Negotiation Controller
Message Analysis Controller
User Notification Actuator
Agenda Update Actuator
Outgoing Message Actuator
98
Behavioural Specification

• How the agent behaves
• Links between components
• Type of messages exchanged
• Execution sequence of components

User Preferences Infostore
Incoming Message Sensor
Message Mailbox Infostore
Meetings Negotiation Controller
Message Analysis Controller
User Notification Actuator
Agenda Update Actuator
Outgoing Message Actuator
99
Reconfiguration

• Agent aspects managed through a shell, which
  directs access to each specification

100
Example BDI Architectures

• BDI aims to model rational or intentional agency
• The symbols representing the world correspond to
  mental attitudes
• Three categories
• informative (knowledge, belief, assumptions)
• motivational (desires, motivations, goals)
• deliberative (intentions, plans)

101
BDI Systems

• BDI Belief, Desires and Intentions
• Many agent architectures are BDI based
• Original system was PRS
• More recent versions include dMARS.
• Other related systems include AgentSpeak(L) and
  Agentis

102
Folk Psychology

• I believed the tutorial today was at 8am so I
  intended to arrive yesterday from London.
• I believed the planes were not delayed and
  desired not to be late so I intended to arrive by
  6pm.
• Compelling because
• familiar what it wants, knows and intends -
  easier to understand and predict behaviour.
• Other agents can understand and predict behaviour
• Relationship between these three categories may
  give us a handle on intelligent action in
  general.

103
BDI Architectures

• Beliefs - modelling world state.
• Desires - choice between possible states.
• Intentions - commitment to achieving particular
  state.

104
PRS/dMARS/AgentSpeak(L)

• Beliefs information about the world
• Goals tasks to achieve
• Plan library procedural knowledge
• Intentions partially instantiated selected plans

105
Procedural Reasoning System (PRS)
Beliefs
Plan library
Action output
Sensor input
Interpreter
Intentions
Goals
106
BDI Architecture

• In general, an agent cannot achieve all its
  desires.
• Must therefore fix upon a subset.
• Commit resources to achieving them.
• Chosen desires are intentions.
• Agents continue to try to achieve intentions
  until either
• believe intention is satisfied, or
• believe intention is no longer achievable.

107
Plans

• BDI model is operationalised in PRS/dMARS agents
  by plans.
• Plans are recipes for courses of action.
• Each plan contains
• invocation condition circumstances for plan
  consideration
• context circumstances for successful plan
  execution
• maintenance condition must be true while plan is
  executing, in order for it to succeed and
• body course of action, consisting of both goals
  and actions.

108
Plan Structure
Plan
Start
?g2 (otherwise)
?g1
Invocation
P2
Context
P1
?g4
Body
?g3
a1
Maintenance
P3
P4
End3
Success
!g1
!g2
Failure
End1
End2
109
Operation 1

• Observe world and agent state, and update event
  queue to reflect observed events.
• Generate new possible goals (tasks), by finding
  plans whose trigger matches event queue.
• Select matching plan for execution (an intended
  means).

110
Operation 2
Intention

• Push the intended means onto the appropriate
  intention stack in the current set.
• Select an intention stack and execute next step
  of its topmost plan (intended means)
• if the step is an action, perform it
• if it is a subgoal, post it on the event queue.

Plan Instance(m)
Plan Instance (m-1)
Plan Instance(1)
111
Applications

• Air-traffic control
• spacecraft systems
• telecommunications management
• air-combat modelling

112
Example AgentSpeak(L) - Description
113
Example AgentSpeak(L) Structure
114
Example AgentSpeak(L) Behaviour
115
Implementation - actSMART

• All concepts implemented in Java, accessible as
  APIs
• Implementation of core in J2ME
• AgentSpeak(L) running on Palm m100
• Desktop version configurable via XML

116
Implementation actSMART
117
Conclusions

• Development process greatly aided through better
  understanding of architecture, easier debugging
• Affords flexibility and allows easy comparison
  between different approaches (both at a
  theoretical and implementation level)
• Can be integrated with existing methodologies or
  form the basis for one

118
Further Work

• Larger scale implementation
• Library of architectures and architectural
  patterns
• Integration with other aspects (relationships,
  discovery)