1

Mobile Code, Mobile Agents &

Mobility (and Autonomy)
Ming Kin Lai
March 9, 2007
2
Programming Languages for Mobile Code
Tommy Thorn
ACM Computing Surveys 9/1997
mobile code defined differently
author defines as software that travels on a
heterogeneous network, crossing protection
domains, and automatically executed upon
arrival at the destination
protection domains corporate network or PDA
excludes cases where code is
loaded from a shared disk
downloaded (manually) from the Web
3
Mobile code supports a flexible form of
distributed computation where the desired
nonlocal computations need not be known
in advance at the execution site
4
Advantages
Efficiency
Simplicity and flexibility
Storage
5
Well-known examples of mobile code
PostScript
Database technology SQL
Documents with embedded executable
contents transmitted on the network =
Java (applet)
Inferno developed by Lucent a mobile-
code-enabled network OS
6
Common needs of mobile code in
terms of programming languages
Portability
Safety
Security
Confidentiality
Integrity
Availability
Authenticity
Efficiency

7
Representative programming
languages for mobile code
Java
Limbo
Objective Caml
Obliq
Telescript
Safe-Tcl

8
Two Mobility Models
Code fetching user downloads the code
to be executed; initiative is with the
receiver of the code Java, OCaml, Limbo
Agent programmed to migrate
themselves; initiative is with the mobile
code itself Obliq, Telescript

9
Mobile Agents: Basic Concepts, Mobility
Models, and the Tracy Toolkits
Peter Braun, Wilhelm Rossak 2005
Mobile code a technique where code is
transferred
from the computer system that stores
the codes file
to the computer system that executes
the code
Mobile agent a special type of mobile
code

10
Java applets
Well-known example of mobile code
Small programs available in a portable and
interpretable byte code format
Transferred from a Web server to a Web
browser in order to be executed as part of
an HTML page

11
Mobile agents
A program that can migrate from a starting
host to many other hosts in a network of
heterogeneous computer systems and
fulfill a task specified by its owner
During the self-initiated migration, the
agent carries all its code and data, and in
some systems also some kind of
execution state

12
Differences between Java applets
and mobile agents
MAs initiate the migration process; migration of
Java applets is initiated from other software
components (e.g. Web browser)
Java applets migrate only from a server to a
client, do not leave the client to another client or
back to the server
Applets lifetime bound to that of the Web page,
dies when browser terminates or another Web
page requested; MA usually migrate more than
once
13
MA from 2 viewpoints
AI: MA = Software agent + mobility
Distributed Systems:
Self-contained and identifiable computer programs,
bundled with their code, data, and execution state,
that can move within a heterogeneous network of
computer systems.
Can suspend their execution on an arbitrary point and
transport themselves to another computer system.
During this migration the agent is transmitted completely,
i.e., as a set of code, data, and execution state.
At the destination, execution is resumed at exactly the
point where it was suspended.

14
Distributed Systems Point of View
of MAs
Nothing about the characteristics of software
agents
Simply computer program or processes in the
meaning of OSes that are able to freeze
themselves, move to another systems, and
resumes execution there
Considered a design paradigm in the area of
distributed programming
And a useful supplement of traditional
techniques such as client-server architectures
15
Code
Some kind of executable representation of
computer programs
Can be :
Source code, in the case of scripting languages such
as Perl or Tcl
Byte code, in the case of Java
Executable machine language, in the case of C
Logic of the agent
Code of agent vs code of the agency
16
Data
All variables of the agent (in OO
languages, set of all attributes of the
corresponding object)
Corresponds to agents instance variables
if an agent is an instance of a class in
object-oriented languages
aka object state
Owned by agent and movable
17
Execution state
Info about the execution of the agent
Might be quite complete info from within the
underlying (virtual) machine about
Call stack
Register values
Instruction pointers
Most Java-based MA toolkits do not provide a
sophisticated determination of the execution
stack, due to some limitations of the JVM

18
Execution state
vs object state (i.e. data)
- object state: directly controlled by agent
itself
- execution state: usually controlled by
processor and OS
- Depends on decision of MA toolkit
designer and underlying execution
environment (processor, OS, virtual
machine)
19
Execution state
In some toolkits, consists of:
Current value of instr pointer
Stack of underlying processor
20
I think
Local variables are data
Program counter can also be considered data
Object variables can be considered state
So,
state is data
data is state
??
Distinction between exec state and object state (i.e.
data) may be simply due to
whether one is controlled by the agent and thus somehow easier
to capture
whether one is controlled by the OS and thus somehow more
difficult to capture



21
Portable Support for
Transparent Thread Migration in Java
Truyen et al.
Proceedings of the Joint Symposium on Agent Systems and
Applications / Mobile Agents 9/2000
In Java, each object consists of 3 states:
Program state: byte code of the objects class
Data state: contents of objects instance variables
Execution state:
each Java object executes in one or more JVM threads
each JVM thread has Program Counter Register and private
Java Stack
a Java stack stores frames; one frame for each method
invoked
each frame holds local variables and an operand stack

22
Javas capabilities
Code mobility
Use of byte code and JVM
Machine-independent
Java class loading mechanism
Byte-code easily transportable
Object state mobility
Java serialization mechanism
Execution state mobility
Not offered by Java. Need middleware support

23
Strong and weak migration
as defined by Funfrocken
Non-transparent or weak migration:
Programmer has to
provide explicit code to read and reestablish
agents state
manually encode agents logical execution
state into data state
Transparent or strong migration
24
Java
Code and data migration strongly
supported
Thread migration completely not
supported
JVM threads not implemented as
serializable
Java language does not define any
abstractions for capturing and
reestablishing thread state info inside JVM
25
Short History of MAs
Mobile code
Mobile code considered an ancestor of MAs
Decode-Encode-Languages (DEL) by Rulifson
in 1969
Network Interchange Language (NIL) by Elie in
1971
Softnet by Linkoping Univ in Sweden in 1980
Network command language (NCL) by Falcone
in 1987
Remote evaluation by Stamos in 1986
26
Short History of MAs contd
Mobile Objects
Mobile Objects = messaging concept +
minimal kind of autonomy
Active message = data + some program
code
Data portion still dominant, code more or
less an add-on
Migrates more than once, migration
initiated by agent itself
27
Short History of MAs contd
Mobile Objects
MESSENGERS-I
Limited to static LANs
No notion of application-level intelligence
Messengers autonomy limited to the level of
technological and system-level needs, not
targeted at solving a users problem

28
Short History of MAs contd
Mobile Processes
Ability to capture the actual execution
state of the processor or VM
Idea developed in the area of distributed
OSes in late 1980s
Process moves to balance load of the
distributed system as a whole
Example: Sprite OS

29
Short History of MAs contd
Mobile Agents
1994 White, affiliated with General Magic,
published a white paper
Introduced Telescript
Received a U S patent

30
Short History of MAs contd
Mobile Agents
1997 Chess et al published a paper
describing a framework for itinerant agents
as an extension of the client-server model

31
Short History of MAs contd
Existing Mobile Agent Toolkits
ADK
Aglets
Ajanta
Concordia
DAgents
Grasshoppers
Mole
Semoa
Tacoma
Tracy
Voyager

32
Programming languages for mobile agents
Any language can be used to implement
MAs
In most MA systems, same language for
both MAs and the underlying agency
Few (Tacoma and DAgents) allow diff
lang for MAs and agencies
Almost all MA toolkits from 2000-2005
used Java
33
Java as the implementation lang for MAs
in Tracy
import de.fsuj.tracy.agent.*;

public class MyAgent extends Agent
{
SomeOtherClass other = new SomeOtherClass();

public MyAgent() {
// do some init
}

public void startAgent() {
// do something
}

final protected void go(String dest, String methodName) {
// migrate the agent
}
}
34
Java as the de facto lang for MAs
Because of its many features that lessen
the effort in building MA toolkits
Features that support migration process
Object serialization
Dynamic class loading
Reflection
Security features
Some Java aspects are imperfect
35
Main drawback of Java
Impossible to obtain the current execution state
of a thread in the form of
Current instr pointer
Calling stack
Therefore, Java-based MAs can offer only a
weak form of mobility
Agent restarted at the receiver agency
by invoking a method instead of
jumping into it and resuming execution at the 1
st
stmt
after migration
36
Another drawback of Java
Lack of resource control (e.g. for memory
or processor cycles)
Therefore, impossible to avoid denial-of-
service attacks
Attacker tries to consume so many resources
that the system no longer can handle
incoming requests
37
Migration Command
in the Tracy MA Toolkit
final protected void go(String dest, String
methodName)
go(tcp://darwin.ics.uci.edu:4040,
runAtRemote);
Semantics:
Stops execution immediately
Statements following the go never executed
38
Migration of execution state
in Tracy, state = name of method to invoke
at the destination
go(tcp://darwin.ics.uci.edu:4040,
runAtRemote);
39
Java reflection technique
Used to resume agent execution at the
receiver agency
Determine info about
classes
their variables
methods
at runtime
40
Javas object serialization and
deserialization
Serialization means all variables of the
agent, plus all recursively referenced
objects and their variables, are traversed
and put into a flat byte array
Object closure = set of all objects to be
serialized
Java serialization determines only the
object state of an agent, not its execution
state
41
Javas object serialization and
deserialization
ObjectOutputStream.writeObject()
ObjectInputStream.readObject()

42
Moving of code, data and state
Execution state (name of start method)
transmitted as a parameter in the
migration command
Data (i.e. object state) is migrated using
object serialization and de serialization
How about code?
43
Code migration
Code = all classes the agent might ever use in
the receiver agency
Need to determine those classes code closure
Code closure consists of :
agents main class, and
all classes used for
variables,
method parameters,
method return values,
local variables
of any class of the code closure

44
Migration of code closure
Java does not provide an easy way to
determine code closure
Class.getDeclaredMethods() returns
classes used for member variables
Using this info, we can determine classes
used for parameters and return values
Still cannot determine info about local
variables defined within methods
45
Determining the code needed for
local variables in a method
Tracy uses its own technique that looks at
the byte code of the class
Use ByCal (byte code analyzer) to read
the constant pool
Constant pool a table containing all
names ever used in this class
46
Removal of redundant code from
code closure to be migrated
If certain code assumed to be already in
the receiver agency, delete it
Java does not provide a tool
Tracy develops its own way
47
Linking agents code to
the receiver agencys code
After agent is received at the destination
agency, its code must be linked to the
code of the already running agency
Use Javas dynamic loading and linking
mechanism
48
Javas dynamic class loading
Allows JVM to load and define classes at
runtime
class ClassLoader
findClass()
defineClass()
calls dlopen() ? Unixs lib for dynamic
loading for C programs
49
Migration of code, data, and state
Migration of execution state parameter
of the migration command
Migration of data - serialization
Migration of code
Class.getDeclaredClasses(), ByCal,
ClassLoader
50
Efficient migration
MA should not always migrate as one unit
consisting of all code, data and state
Sometimes useful to let the agent decide
which code and data should be transferred
to the next server
Mobility model describes the migration
techniques of a MA toolkit
51
Many design issues relating to
mobility models
From users view
Naming and addressing
Creating agents
Code source
Migration

52
Migration issues
Who initiates the migration
How to define the destination
Effect of migration copy or clone
What happens if there is an error
Mobility

53
Types of mobility
Most discussed issue concerning agent
migration
Each type can be characterized by the
interpretation of the term state
weak
strong
54
Types of mobility
Weakest
Transmits only
Instance variables (object state)
Code
Agent initialized and started by invoking a
designated (pre-defined) method
Used in Aglets, Grasshoppers, Mole,
Discovery
Weak mobility with fixed method invocation
55
My opinion
MAs of the Weakest form of Mobility may not qualify
as MAs if one defines MAs as having the ability to
migrate code, data, and EXECUTION STATE
MAs - Self-contained and identifiable computer
programs, bundled with their code, data, and
execution state,
that can move within a heterogeneous network of
computer systems.
Can suspend their execution on an arbitrary point
and transport themselves to another computer
system.
During this migration the agent is transmitted
completely, i.e., as a set of code, data, and
execution state

56
Types of mobility
Not so weak
Transmits
Instance variables (object state)
Code
Name of starting method
Allows programmer to define name of starting
method within the go command
Agent initialized and started by invoking a
given method
Used in Voyager
Weak mobility with arbitrary method
invocation
57
Weak forms of mobility
Programmer has to exert additional effort to implement
marshalling and demarshalling of local variables
public class MyAgent extends Agent
{
private int copyOfLocal = 0;
protected void anyMethod() {
int local = 10;
// some code
// before migration, we need to save local
copyOfLocal = local;
go(tcp://darwin.ics.uci.edu, runAtRemote);
}
}
This example shows how to save the value of local variables in object
variables, so that the value is part of the (object stare, i.e. data) of
the agent. runAtRemote() can use copyOfLocal again.


58
Weak forms of mobility
In both weak levels, the migration
command has to be the last instruction
within a method, because migration to a
new agency invokes a new method
Recall:
Semantics of go():
Stops execution immediately
Statements following the go never executed
59
Types of mobility
Strong
Transmits
Code
Instance variables (object state)
All local variables of the current method + program
counter + call stack (execution state)
Agent initialized and started at the 1
st

instruction after go()
Used in early MA toolkits such as Telescript,
AgentTCL
60
Strong mobility
Comparatively easy to add all the features
that support strong mobility
if full access to
the underlying programming language,
the compiler, and
the runtime system
is available
61
Implementing strong mobility in
Java-based MA toolkits
Either
Source code of JVM must be modified
Or
Agents source has to be transformed to
simulate modification
62
JVM modification
Difficult
Said to be done in
Ara [Peine and Stolpmann, 1997]
Sumatra [Acharya et al., 1997]
DAgents [Gray et al., 2002]
Resulting MA toolkits can be used only if the
modified JVM is used
Problems of licensing the JVM source code
63
Agent source code transformation
Funfrocken [1999] uses a preprocessor
that inserts code to save and recover the
execution state
Sekiguchi et al [1999] made a comparable
attempt
Drawbacks:
Longer source code
Unnegligible performance decrease
64
Agent source code transformation
Other attempts:
Illmann et al [2001]
Bettini and Nicola [2001]
Wang et al [2001]
Fukuda et al [2003]
Chakravarti et al [2003]
65
Strong or weak mobility?
Pro-weak
Baumann states strong mobility is useless in most
cases, because a migration step is a major break in
the life of an agent
Cabri et al argue along the same line, stressing that
weak mobility leads to a clean programming style
Pro-strong
Belle and DHondt, for example, argue that strong
mobility has a more natural programming style
.

66
Examples for mobility models
IBM Aglets 1995
IKV++ Grasshopper 1995
Both have weak mobility
67
Aglets
A method named run is called whenever
an agent is started or restarted at an
agency
Migration command named dispatch with
one parameter: the destination agency
dispatch(http://....);
68
Grasshopper
A method named live is invoked to an
agent
Migration command named move with one
parameter: the destination agency
move(http://....);
69
Other mobility model classification
Fuggetta et al [1998]:
Weak mobility = remote evaluation, where, except
some init data, no state info is shipped to the remote
destination
(here, Braun & Rossaks weak mobility contains
object state)
Weak mobility:
Code shipping (remote evaluation)
Code fetching (code-on-demand)
Strong mobility: supported in 2 forms:
Migration
Remote cloning

70
In my opinion, significance of
strong vs weak mobility
Not really about code mobility although
common definitions assume it
Really about whether the language
supports automatic capturing and
migrating the call stack and heap
71
Does MESSENGERS-C have
strong mobility?
MESSENGERS does not migrate code, call stack, and
heap
True that a Messenger starts execution at the next stmt
after hop(), i.e. arbitrary point, at the new node
Would it be trivial to achieve the same in the case of a mobile
code language if we dont need to capture and migrate the call
stack?
Yosen: It is easy to capture only the program counter but difficult
to reset it using Java.
Claim that MESSENGERS has strong mobility may be
misleading using a term intended for the purposes of
comparing apple (mobile code with call stack) with apple
(mobile code with call stack) to compare apple with
orange
72
My analysis
Level of mobility Program counter Data space Code
Strong (after migration, agent
starts at the point after the
migration command)



MESSENGERS-C (after migration, Messenger
starts at the point after hop())
Weak w/ arbitrary
method invocation
(after migration, agent
starts at the specified point)

Weak w/ fixed
method invocation

Components of execution state
= migrated
73
My analysis
Level of mobility State Code Point of Restart
Strong Full (PC + object
variables + call stack)
Y Next stmt after
hop
MESSENGERS-C Limited (PC +
Messenger variables)
N Next stmt after
hop
Weak w/ arbitrary
method invocation
Limited (PC + object
variables)
Y The specified
method
Weak w/ fixed
method invocation
Limited (object
variables)
Y The pre-defined
method
Migration of
74
Mobility hierarchy
Data Control Code State

MPI x
RPC x x
MESSENGERS-C x x
Mobile code x
Thread migration x x x
Mobile agents with
weak mobility x x x x (by programmer)
Mobile agents with
strong mobility x x x x (by system)

Computation mobility x x x x
State mobility subsumes control mobility


75
Determinant(s) of the ability to
restart at arbitrary point (or
transparency of migration)
Format of the PC migrated? both strong and
MESSENGERS migrate the PC without explicitly
or implicitly specifying the restart method and
both can restart at an arbitrary point
Whether call stack is migrated? strong
migrates the call stack and can restart at an
arbitrary point whereas weak does not migrate
the call stack and cannot restart at an arbitrary
point
Coupling relationship between code migration
and call stack migration?
76
How RPC conceptually works
main ()
{
func(1, 2);
}

func (int x, int y)
{

}
Server code on one machine, client code on another
Code does not migrate
Data migrates in the form of parameter passing
77
RPC and non-local variables
main ()
{
int a = 3;
func (int x, int y)
{
// access a
}
func(1, 2);
}

ok if local function call
not allowed if remote function call
No migration of exec state, except the program counter
78
RFC 1057 Remote Procedure Call, Version 2 June 1988
There are a few important ways in which remote
procedure calls differ from local procedure calls:
1. Error handling: failures of the remote server or
network must be handled when using remote procedure
calls.
2. Global variables and side-effects: since the server
does not have access to the client's address space,
hidden arguments cannot be passed as global variables
or returned as side effects.
3. Performance: remote procedures usually operate one
or more orders of magnitude slower than local procedure
calls.
4. Authentication: since remote procedure calls can be
transported over insecure networks, authentication may
be necessary.
79
RPC vs MESSENGERS-C
RPC
Code distributed
Restart at (the start of) a specified function
Does not transfer exec state, except program
counter
Transparent migration (conceptually)
MESSENGERS-C
Restart at arbitrary point
Explicit hop


80
Bibliography
Anurag Acharya et al. Sumatra: A language for resource-aware
mobile programs. 1997
Lorenzo Bettini and Rocco De Nicola. Translating strong mobility
into weak mobility. 2001
Arjav J. Chakravarti et al. Implementation of strong mobility for
multi-threaded agents in Java. 2003
Stefan Funfrocken. Transparent migration of Java-based mobile
agents. 1999
Munehiro Fukuda et al. A mobile-agent PC grid. 2003
Robert S. Gray et al. DAgents: Applications and performance of a
mobile-agent system. 2002
Torsten Illmann et al. Transparent migration of mobile agents using
the Java platform debugger architecture. 2001
Holger Peine and Torsten Stolpmann. The architecture of the Ara
platform for mobile agents.1997
Tatsurou Sekiguchi et al. A simple extension of Java language for
controllable transparent migration and its portable implementation.
1999
Xiaojin Wang et al. Reliability through strong mobility. 2001
81
Process Migration
Milojcic et al.
ACM Computing Surveys 1999
Taxonomy
Mobility
Hardware
Software
Passive data
Active data
Mobile code (code)
Process migration (code+data)
Mobile agents (code+data+authority)
82
Software mobility
Passive data:
Traditional means of transferring data between
computers
Active data: 3 types based on incremental
evolution of state transfer
Mobile code: e.g. Java applets, transfers code
Process migration:
code
data
authority (e.g. access to shared file system) in a limited way:
authority is under the control of a single admin domain
Mobile agents
authority: to act on owners behalf on a wide scale, such as
within Internet

83
Alternatives to process migration
Object migration at middleware level
Distributed objects systems: DCE, COBRA
Migration did not attract much research
because early heterogeneity of these systems
did not adequately support mobility
DC++, OMG MASIF
Mobile agents

84
Migration levels
Application-specific migration
Distributed apps
End user apps
User-level process migration
System libs
User space
Traditional process migration
OS kernel
Kernel space
85
Process migration goals
Exploitation of resource locality
Accessing more processing power
Resource sharing
Fault resilience
System admin
Mobile computing
86
Process migration examples
Early work
XOS, Worm, Butler, DEMOS/MP
Transparent migration in Unix-like systems
Locus, OSF/1 AD, MOSIX, Sprite
OS with Message-passing interface
Charlotte, Accent, V Kernel
Microkernels
RHODOS, Arcade, Chorus, Amoeba, Birlix, Mach
User-space migrations
Condor, Migratory PVM, LSF,
Application-specific migrations
Freeman, Skordos, Bharat & Cardelli (Migratory Applications)
Mobile objects
Emerald, SOS, COOL
Mobile agents: derived from 2 fields
AI
Distributed systems
Telescript, Agent Tcl, TACOMA, Mole, ..
87
Mobile object vs Mobile agent
My understanding and opinion
If we need to distinguish them
MO emphasize on distributed system
MA emphasize on AI
88
Thread migration
thread :
In context of OS, entity for CPU scheduling
and resource holding
In context of program design, sequence of
instructions flow-of-control
OS threads are a particular mechanism for
encapsulating a control flow
Thread migration
thread refers to thread in the context of OS

89
Thread Migration with Active Threads
Michael Holtkamp 1997
Code
Heap
Static
Stack
Virtual addr space
Process
Registers
Process
Virtual addr space
Heap
Static
Code
Reg Reg Reg
Stack
Stack
Stack
Thread Thread Thread
90
Process Migration
Entire virtual address space of the process
is copied
To optimize:
Pre-copying
Copying on reference
91
Thread Migration
Only thread stack and registers copied
All shared resources of the process remain on
the source machine
Assumptions:
A process for the same program has been started in
the destination machine
The code is in the same virtual memory area on both
machines
Problems:
Pointers to stack
Pointers to heap
Heap accessed by multiple threads

92
Thread Migration Problems
Heap Pointers
Disallow the use of the heap
Virtual common heap by a DSM
Stack Pointers
Pointer manipulation
Preventive stack reservation
93
Thread migration goals
Exploitation of resource locality
Accessing more processing power
Resource sharing
Fault resilience
Load balancing
94
Thread Migration Examples
Emerald
Ariadne
Amber
Millipede
UPVM
Active Threads

95
Is MESSENGERS-C a thread
migration system?
Most if not all thread migration systems
migrate OS threads
MESSENGERS-C does not solve
problems usually addressed in thread
migration systems
96
Software migration in summary
Mobile code
Mobile agents/Mobile objects
Process migration
Thread migration

97
To recap
Definitions of the term mobile agents
collected at a Mobile Object Systems conference 1996
From the perspective of systems implementation
Mobile agents are objects consisting of code, data
and execution state that may go beyond protection
domains.
A mobile agent is a thread of control which can trigger
the transfer of arbitrary code to a remote computer
such that (i) this code has a chance to be executed
remotely and independently , (ii) the resulting remote
thread may trigger another code transfer.
From the perspective of artificial intelligence
A mobile agent is a component containing at least
one thread of execution, which is able to
autonomously migrate to a different site.
A mobile agent is a set of objects performing a
computation on behalf of a user. .

98
AI viewpoint of Mobile Agents
Mobile software agents are computer
programs that act as representative in the
global network of computer systems. The
agents knows its owner, knows his or her
preferences, and learns by communicating
with his owner. The user can delegate
tasks to the agent, which is able to search
the network efficiently by moving to the
service or information provider.
99
Agents

Agents
Mobile
agents
Autonomous
agents
100
Informal definitions
Agents achieving a goal without
intervention from others
Autonomous/intelligent agents exercises
control over its own actions
Mobile agents - able to transport itself from
one machine to another
101
An autonomous agent is a system
situated within and a part of an
environment that senses that environment
and acts on it, over time, in pursuit of its
own agenda and so as to effect what it
senses in the future
102
Autonomy
as defined by Russel & Norvig
If agents actions based completely on
built-in knowledge, and pays no attention
to its percepts, it lacks autonomy
A system is autonomous to the extent that
its behavior is determined by its own
experience
103
intelligence
Search algorithms
Uniformed
DFS
BFS
Informed
Best First Search
A* algorithm
104
Where autonomous agents and
mobile agents intersect
The agents have autonomy, using some
intelligence, to decide where to migrate
105
MESSENGERS-C has
autonomy in migration?
Autonomy is more than invoking the migration in
own program
Need a decision-making algorithm to decide on
migration
A system can provide the mobility functionality
but the programmer has to program the
autonomy in agents
So, some agents in a MA system can be
autonomous, and some can be non-autonomous
A system may have built-in (domain-specific)
intelligence in order to be an autonomous
system
106
Reference
K. S. Barber, C. E. Martin, Specification,
Measurement, and Adjustment of Agent
Autonomy: Theory and Implementation, 1999
Charles J. Petrie, Agent-Based Engineering,
the Web, and Intelligence, 1996
Stan Franklin and Art Graesser, Is it an
Agent, or just a Program?:
A Taxonomy for Autonomous Agents, 1996
Sam Joseph, Takahiro Kawamura, Why
Autonomy Makes the Agent, 2001