Mobile Code, Mobile Agents

1
Mobile Code, Mobile Agents Mobility

• Ming Kin Lai
• March 2, 2007

2
Programming Languages for Mobile CodeTommy
ThornACM 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 know 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 ToolkitsPeter Braun, Wilhelm
Rossack 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
Short History of MAsMobile 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

21
Short History of MAs contdMobile 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

22
Short History of MAs contdMobile 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

23
Short History of MAs contdMobile 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

24
Short History of MAs contdMobile Agents

• 1994 White, affiliated with General Magic,
  published a white paper
• Introduced Telescript
• Received a U S patent

25
Short History of MAs contdMobile Agents

• 1997 Chess et al published a paper describing a
  framework for itinerant agents as an extension of
  the client-server model

26
Short History of MAs contdExisting Mobile
Agent Toolkits

• ADK
• Aglets
• Ajanta
• Concordia
• DAgents
• Grasshoppers
• Mole
• Semoa
• Tacoma
• Tracy
• Voyager

27
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

28
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

29
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

30
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
  1st stmt after migration

31
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

32
Migration Command in the Tracy MA Toolkit

• final protected void go(String dest, String
  methodName)
• go(tcp//darwin.ics.uci.edu4040,
  runAtRemote)
• Semantics
• Stops execution immediately
• Statements following the go never executed

33
Migration of execution state

• in Tracy, state name of method to invoke at the
  destination
• go(tcp//darwin.ics.uci.edu4040,
  runAtRemote)

34
Java reflection technique

• Used to resume agent execution at the receiver
  agency
• Determine info about
• classes
• their variables
• methods
• at runtime

35
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

36
Javas object serialization and deserialization

• ObjectOutputStream.writeObject()
• ObjectInputStream.readObject()

37
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?

38
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

39
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

40
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

41
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

42
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

43
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

44
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

45
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

46
Many design issues relating to mobility models

• From users view
• Naming and addressing
• Creating agents
• Code source
• Migration

47
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

48
Types of mobility

• Most discussed issue concerning agent migration
• Each type can be characterized by the
  interpretation of the term state
• weak
• strong

49
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

50
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

51
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

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

53
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

54
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

55
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

56
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

57
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

58
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

59
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

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

61
Examples for mobility models

• IBM Aglets 1995
• IKV Grasshopper 1995
• Both have weak mobility

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

63
Grasshopper

• A method named live is invoked to an agent
• Migration command named move with one parameter
  the destination agency
• move(http//....)

64
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

65
My analysis
? migrated
66
My analysis
Claiming MESSENGER has strong mobility may be
misleading
67
My comments

• Most, if not all, definitions of strong and weak
  mobility assume code mobility
• Usually, code mobility refers to mobility on
  heterogeneous network, across protection domains

68
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