mobile codmobile code mobile agents & mobility (& autonomy)e mobile agents & mobility (& autonomy)

8/12/2019 Mobile CodMobile code Mobile Agents & Mobility (& Autonomy)e Mobile Agents & Mobility (& Autonomy)

1/106

1

Mobile Code, Mobile Agents &

Mobility (and Autonomy)

Ming Kin Lai

March 9, 2007


2/106

2

Programming Languages for Mobile CodeTommy Thorn

ACM Computing Surveys 9/1997

mobile code defined differently

author defines as software that travels on a

heterogeneous network, crossing protectiondomains, and automatically executed upon

arrival at the destination

protection domainscorporate network or PDA

excludes cases where code is loaded from a shared disk

downloaded (manually) from the Web


3/106

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/106

4

Advantages

Efficiency

Simplicity and flexibility

Storage


5/106

5

Well-known examples of mobile code

PostScript

Database technologySQL

Documents with embedded executablecontents transmitted on the network =

Java (applet)

Inferno developed by Lucenta mobile-code-enabled network OS


6/106

6

Common needs of mobile code in

terms of programming languages

Portability

Safety

Security Confidentiality

Integrity

AvailabilityAuthenticity

Efficiency


7/106

7

Representative programming

languages for mobile code

Java

Limbo

Objective Caml Obliq

Telescript

Safe-Tcl


8/106

8

Two Mobility Models

Code fetchinguser downloads the code

to be executed; initiative is with the

receiver of the code Java, OCaml, Limbo

Agentprogrammed to migrate

themselves; initiative is with the mobile

code itself Obliq, Telescript


9/106

9

Mobile Agents: Basic Concepts, Mobility

Models, and the Tracy ToolkitsPeter Braun, Wilhelm Rossak 2005

Mobile codea technique where code istransferred

from the computer system that storesthe codes file

to the computer system that executes

the code Mobile agenta special type of mobile

code


10/106

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/106

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 ofexecution state


12/106

12

Differences between Java applets

and mobile agents

MAs initiate the migration process; migration ofJava applets is initiated from other softwarecomponents (e.g. Web browser)

Java applets migrate only from a server to aclient, do not leave the client to another client orback to the server

Applets lifetime bound to that of the Web page,

dies when browser terminates or another Webpage requested; MA usually migrate more thanonce


13/106


14/106

14

Distributed Systems Point of View

of MAs

Nothing about the characteristics of softwareagents

Simply computer program or processes in the

meaning of OSes that are able to freezethemselves, move to another systems, andresumes 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/106

15

Code

Some kind of executable representation of

computer programs

Can be :

Source code, in the case of scripting languages suchas 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/106

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/106

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/106

18

Execution state

vs object state (i.e. data)

- object state: directly controlled by agentitself

- execution state: usually controlled byprocessor and OS

- Depends on decision of MA toolkit

designer and underlying executionenvironment (processor, OS, virtualmachine)


19/106

19

Execution state

In some toolkits, consists of:

Current value of instr pointer

Stack of underlying processor


20/106

20

I think

Local variables are data Program counter can also be considered data

Object variables can be considered state

So,

state is datadata 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 moredifficult to capture


21/106

21

Portable Support for

Transparent Thread Migration in JavaTruyen et al.

Proceedings of the Joint Symposium on Agent Systems andApplications / 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/106

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/106

23

Strong and weak migrationas 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/106

24

Java

Code and data migration stronglysupported

Thread migration completely not

supported JVM threads not implemented as

serializable

Java language does not define anyabstractions for capturing andreestablishing thread state info inside JVM


25/106

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 in1971

Softnet by Linkoping Univ in Sweden in 1980

Network command language (NCL) by Falconein 1987

Remote evaluation by Stamos in 1986


26/106

26

Short History of MAscontd

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/106

27


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/106

28


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/106

29


Mobile Agents

1994 White, affiliated with General Magic,

published a white paper

Introduced Telescript

Received a U S patent


30/106

30


Mobile Agents

1997 Chess et al published a paper

describing a framework for itinerant agents

as an extension of the client-server model


31/106

31


Existing Mobile Agent Toolkits ADK

Aglets

Ajanta

Concordia

DAgents

Grasshoppers

Mole

Semoa

Tacoma

Tracy

Voyager


32/106

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/106

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/106

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/106

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 1ststmt

after migration


36/106

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/106

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 gonever executed


38/106

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/106

39

Java reflectiontechnique

Used to resume agent execution at the

receiver agency

Determine info about

classes

their variables

methods

at runtime


40/106

40

Javas object serialization and

deserialization

Serialization means all variables of theagent, plus all recursively referencedobjects 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 theobject state of an agent, not its executionstate


41/106

41

Javas object serialization and

deserialization

ObjectOutputStream.writeObject()

ObjectInputStream.readObject()


42/106

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/106

43

Code migration

Code = all classes the agent might ever use inthe receiver agency

Need to determine those classescode 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/106

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

f


45/106

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 poola table containing all

names ever used in this class

R l f d d t d f


46/106

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

Li ki t d t


47/106

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/106

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/106

49

Migration of code, data, and state

Migration of execution stateparameter

of the migration command

Migration of data - serialization

Migration of code

Class.getDeclaredClasses(), ByCal,

ClassLoader


50/106

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 modeldescribes the migration

techniques of a MA toolkit

M d i i l ti t


51/106

51

Many design issues relating to

mobility models

From users view

Naming and addressing

Creating agents

Code source

Migration


52/106

52

Migration issues

Who initiates the migration

How to define the destination

Effect of migrationcopy or clone

What happens if there is an error

Mobility


53/106

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/106

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/106

55

My opinion MAs of the Weakest form of Mobility may not qualify

as MAs if one defines MAs as having the ability tomigrate code, data, and EXECUTION STATE

MAs - Self-contained and identifiable computerprograms, bundled with their code, data, and

execution state,that can move within a heterogeneous network ofcomputer systems.

Can suspend their execution on an arbitrary point

and transport themselves to another computersystem.

During this migration the agent is transmittedcompletely, i.e., as a set of code, data, andexecution state


56/106

56

Types of mobility

Not so weak Transmits Instance variables (object state)

Code

Name of starting methodAllows programmer to define name of starting

method within the gocommand

Agent initialized and started by invoking a

given method Used in Voyager

Weak mobility with arbitrary methodinvocation

W k f f bilit


57/106

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) ofthe agent. runAtRemote() can use copyOfLocal again.


58/106

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 gonever executed


59/106

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 1st

instruction after go() Used in early MA toolkits such as Telescript,AgentTCL


60/106

60

Strong mobility

Comparatively easy to add all the features

that support strong mobility

iffull access to

the underlying programming language,

the compiler, and

the runtime system

is available

Implementing strong mobility in


61/106

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/106

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/106

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 comparableattempt

Drawbacks:

Longer source code

Unnegligible performance decrease


64/106

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/106

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 strongmobility has a more natural programming style

.


66/106

66

Examples for mobility models

IBM Aglets1995

IKV++ Grasshopper1995

Both have weak mobility


67/106

67

Aglets

A method named runis called whenever

an agent is started or restarted at an

agency

Migration command named dispatchwithone parameter: the destination agency

dispatch(http://....);


68/106

68

Grasshopper

A method named liveis invoked to an

agent

Migration command named movewith one

parameter: the destination agency

move(http://....);


69/106

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 remotedestination

(here, Braun & Rossaks weak mobility containsobject state)

Weak mobility: Code shipping (remote evaluation)

Code fetching (code-on-demand)

Strong mobility: supported in 2 forms: Migration

Remote cloning

In my opinion significance of


70/106

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 andmigrating the call stack and heap

Does MESSENGERS-C have


71/106

71

Does MESSENGERS-C have

strong mobility?

MESSENGERS does not migrate code, call stack, andheap

True that a Messenger starts execution at the next stmtafter 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 callstack?

Yosen: It is easy to capture only the program counter but difficultto reset it using Java.

Claim that MESSENGERS has strong mobility may bemisleadingusing a term intended for the purposes ofcomparing apple (mobile code with call stack) with apple(mobile code with call stack) to compare apple withorange


72/106

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, Messengerstarts 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/106

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 afterhop

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/106

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 xState mobility subsumes control mobility

Determinant(s) of the ability to


75/106

75

restart at arbitrary point (or

transparency of migration) Format of the PC migrated?both strong andMESSENGERS migrate the PC without explicitlyor 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 anarbitrary point whereas weak does not migrate

the call stack and cannot restart at an arbitrarypoint

Coupling relationship between code migrationand call stack migration?


76/106

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

RPC and non-local variables


77/106

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/106

78

RFC 1057 Remote Procedure Call, Version 2 June 1988

There are a few important ways in which remoteprocedure calls differ from local procedure calls:1. Error handling: failures of the remote server ornetwork must be handled when using remote procedurecalls.

2. Global variables and side-effects: since the serverdoes not have access to the client's address space,hidden arguments cannot be passed as global variablesor returned as side effects.

3. Performance: remote procedures usually operate oneor more orders of magnitude slower than local procedure

calls.4. Authentication: since remote procedure calls can betransported over insecure networks, authentication maybe necessary.

RPC MESSENGERS C


79/106

79

RPC vs MESSENGERS-C

RPC Code distributed

Restart at (the start of) a specified function

Does not transfer exec state, except programcounter

Transparent migration (conceptually)

MESSENGERS-C

Restart at arbitrary point

Explicit hop

Bibliography


80/106

80

Bibliography Anurag Acharya et al. Sumatra: A language for resource-aware

mobile programs. 1997

Lorenzo Bettini and Rocco De Nicola. Translating strong mobilityinto weak mobility. 2001

Arjav J. Chakravarti et al. Implementation of strong mobility formulti-threaded agents in Java. 2003

Stefan Funfrocken. Transparent migration of Java-based mobileagents. 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 usingthe 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

Process Migration


81/106

81

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

Software mobility


82/106

82

y Passive data:

Traditional means of transferring data between

computers

Active data: 3 types based on incrementalevolution 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

Alt ti t i ti


83/106

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 systemsdid not adequately support mobility

DC++, OMG MASIF

Mobile agents

Mi ti l l


84/106

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

P i ti l


85/106

85

Process migration goals

Exploitation of resource locality

Accessing more processing power

Resource sharing

Fault resilience

System admin

Mobile computing

Process migration examples


86/106

86

g p

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

M bil bj t M bil t


87/106

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

Th d i ti


88/106

88

Thread migration

thread :

In context of OS, entity for CPU scheduling

and resource holding

In context of program design, sequence ofinstructionsflow-of-control

OS threads are a particular mechanism for

encapsulating a control flow

Thread migration

thread refers to thread in the context of OS

Thread Migration with Active Threads


89/106

89

Thread Migration with Active ThreadsMichael Holtkamp 1997

Code

Heap

StaticStack

Virtual addr space

ProcessRegisters

Process

Virtual addr space

Heap

Static

Code

Reg Reg Reg

Stack

Stack

Stack

Thread Thread Thread

P Mi ti


90/106

90

Process Migration

Entire virtual address space of the processis copied

To optimize:

Pre-copying

Copying on reference

Thread Migration


91/106

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 inthe destination machine

The code is in the same virtual memory area on bothmachines

Problems: Pointers to stack

Pointers to heap

Heap accessed by multiple threads

Thread Migration Problems


92/106

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

Thread migration goals


93/106

93

Thread migration goals

Exploitation of resource locality

Accessing more processing power

Resource sharing

Fault resilience

Load balancing

Thread Migration Examples


94/106

94

Thread Migration Examples

Emerald

Ariadne

Amber

Millipede

UPVM

Active Threads

Is MESSENGERS-C a thread


95/106

95

migration system?

Most if not all thread migration systemsmigrate OS threads

MESSENGERS-C does not solve

problems usually addressed in threadmigration systems

Software migration in summary


96/106

96

Software migration in summary

Mobile code

Mobile agents/Mobile objects

Process migration

Thread migration

To recap

D fi iti f th t bil t


97/106

97

Definitions of the term mobile agentscollected 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 protectiondomains.

A mobile agent is a thread of control which can trigger

the transfer of arbitrary code to a remote computersuch that (i) this code has a chance to be executedremotely and independently , (ii) the resulting remotethread 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 toautonomously migrate to a different site.

A mobile agent is a set of objects performing acomputation on behalf of a user. .

AI viewpoint of Mobile Agents


98/106

98

AI viewpoint of Mobile Agents

Mobile software agents are computerprograms that act as representative in the

global network of computer systems. The

agents knows its owner, knows his or herpreferences, and learns by communicating

with his owner. The user can delegate

tasks to the agent, which is able to searchthe network efficiently by moving to the

service or information provider.

Agents


99/106

99

Agents

Agents

Mobile

agentsAutonomous

agents

Informal definitions


100/106

100

Informal definitions

Agentsachieving a goal withoutintervention from others

Autonomous/intelligent agentsexercises

control over its own actions

Mobile agents - able to transport itself from

one machine to another


101/106

101

An autonomous agentis a systemsituated within and a part of an

environment that senses that environment

and acts on it, over time, in pursuit of itsown agenda and so as to effect what it

senses in the future

Autonomy


102/106

102

Autonomyas defined by Russel & Norvig

If agents actions based completely onbuilt-in knowledge, and pays no attention

to its percepts, it lacks autonomy

A system is autonomous to the extent thatits behavior is determined by its own

experience

intelligence


103/106

103

intelligence

Search algorithms Uniformed

DFS

BFS Informed

Best First Search

A* algorithm

Where autonomous agents and


104/106

104

mobile agents intersect

The agents have autonomy, using someintelligence, to decide where to migrate

MESSENGERS-C has


105/106

105

autonomy in migration?

Autonomy is more than invoking the migration inown program

Need a decision-making algorithm to decide onmigration

A system can provide the mobilityfunctionalitybut the programmer has to program theautonomyin agents

So, some agents in a MA system can beautonomous, and some can be non-autonomous

A system may have built-in (domain-specific)intelligence in order to be an autonomoussystem

Reference


106/106

Reference

K. S. Barber, C. E. Martin,Specification,Measurement, and Adjustment of AgentAutonomy: 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, TakahiroKawamura, Why

Autonomy Makes the Agent, 2001