Mobile agents

1
Mobile agents

• EEL 6938 Engineering Applications of Autonomous
  Agents
• Lotzi Bölöni

2
Mobile agents

• Mobile agents are autonomous programs which move
  though a network and maintain their identity
  through this move.
• This is a stronger concept than code mobility
  such as Java applets, or client-side Javascript.
• Many agent systems were implemented with support
  for mobility.
• And for many researchers, agents mobile agents
  

3
Motivation for mobility (contd)

• Mobile agents can provide better support for
  mobile clients.
• Reduction of network traffic
• Asynchronous interaction (good in case of
  intermittent connection)
• Remote searching and filtering
• Mobile agents facilitate semantic information
  retrieval.
• Move one step above simple keyword based search.
• Mobile agents facilitate real-time interaction
  with a server
• Eg. space probes, real time control of a machine
  tool
• Mobile agent based transactions avoid the need to
  preserve process state in clients and servers
• Instead, the process state is carried in an agent

4
Motivations for mobility (contd)

• Agent based transactions scale better than
  RPC-based transactions
• Secure agent-based transactions have lower
  overhead than secure RPC.
• Mobile agents allow users to personalize server
  behaviour.
• Agents enable semantic routing.
• Not all these arguments are valid.

5
Counter arguments and answers

• Most counter arguments are based on the fact that
  
• What can be done with mobile agents can be done
  with RPC or
• What can be done on the server, you can do it on
  the client.
• The software engineering counterargument
  whereas each individual case can be addressed in
  some (ad-hoc) manner without mobile agents, a
  mobile agent framework addresses them all of them
  at once.

6
Mobile code

• ! mobile agents
• But, the majority of mobile agent systems imply
  mobile code
• Transferring code between (heterogeneous)
  machines.
• Implies machine independent code.
• Usually, it is implemented with some kind of
  virtual machine
• But it can be also implemented with adaptation,
  recompilation etc.
• Types of mobile code
• Partially Turing machine complete languages (e.g.
  SQL, SVG)
• Interpreted programming languages (Perl, Python,
  Javascript)
• Virtual machine based compiled languages (Java,
  Telescript)

7
Mobile code - applications

• Client-server queries (SQL)
• Client side browser applets
• Java applets
• Javascript
• ActiveX controls
• Remote code updates
• Software updates
• Plugins
• Active E-mail
• Confirmations
• Javascript, Visual Basic for Applications
• E-mail viruses and worms
• Mobile agents

8
Mobile agents without code mobility

• Seeing control handoff as mobility
• No code mobility involved.
• Multithreading involves problems.
• Distributed systems as mobile agent systems
• In this approach, mobility is an analysis
  approach, not a design principle.

9
Strong mobility
10
Strong mobility

• Strong mobility assumes that agents can move at
  any point during their execution
• They are usually relying on
• Specially designed programming languages (eg.
  Telescript).
• Modified virtual machines (eg. NOMADS / AromaVM)

11
Custom language Telescript

• Proprietary language, created by General Magic
  around 1994-95
• Highly influential, without being highly
  successful
• Interpreted language, which runs on a Telescript
  engine.
• The company implemented engines running on PDAs,
  PCs etc
• High Telescript
• Object oriented language, inspired by Smalltalk
• Compiled to Low Telescript
• Low Telescript
• Postfix syntax for stack based implementation

12
Telescript (contd)

• The basic network configuration is to run a
  Telescript Engine on each node of the network.
• A network of Telescript Engines provides a
  homogenous environment on which to build
  distributed systems.
• Basic class Process. Telescript supports
  preemptive, prioritized multi-tasking of Process
  objects. A Process instance can be thought of as
  an object with a life of its own.
• A Place object represents a virtual space in
  which other objects can interwork (through local
  communication). Each Telescript Engine can
  support a number of places.

13
Telescript (contd)

• An Agent object is a Process object which can
  migrate between Places. An agent may move between
  Places on the same Engine, or between Places
  which exist on different Engines.
• The Telescript notion of a distributed system is
  a number of distinctly located places and a
  number of Agents which move between these Places.
  
• Places provide meeting locations for Agents. At a
  Place, Agents can exchange information and
  perform computation. Places also route travelling
  Agents.
• Persistent Objects --- Telescript Engines
  implicitly save and recover object state
  information.
• The Telescript world is divided into "regions".
  Each Engine uses a "regions" database to route
  migrating Agents. Places and Agents are
  identified using "Telenames"
• Telename(Locally-Unique-Name, Region-Name)

14
Telescript security

• Agents have "attributes" such as "identify" and
  "owning authority" which uniquely identify the
  Agent and the entity responsible for it. These
  attributes may be used for authentication.
  Telescript objects also have a "permit" attribute
  which may be used to limit the amount of
  resources which they may consume (e.g. a Place
  may ask an Agent to pay it 30 "Teleclicks" before
  granting it access to some resource).
• A secure "permits" feature is crucial to stop
  Agents from creating a crash-limited number of
  clones of themselves, exhausting resources, or
  other such anti-social behaviour.
• Apparently you can't define a legal Telescript
  Place which holds visiting Agents to ransom
  unless you can circumvent security features and
  hack the Interpreter code!)

15
Specialized JVM NOMADS/Aroma

• NOMADS/Aroma is a Java based agent system with
  strong mobility support, developed at Boeing and
  University of West Florida.
• The standard Java JVM does not allow explicit
  execution state capture, thus we can not
  implement hard mobility.
• There are several solutions
• Modify (patch) the Sun JVM
• Difficulty because of the native thread usage.
• Implement a new JVM
• Use preprocessors and a standard JVM.

16
NOMADS

• Is composed of two parts the agent execution
  environment (called Oasis) and the AromaVM. This
  provides two key enhancements
• Strong mobility the ability to capture and
  transfer the full execution state.
• Safe execution the ability to control the
  resources consumed by the agents thereby
  facilitating guarantees of quality of service and
  protecting against denial of service attacks.
• These features, however come with a performance
  penalty.

17
Weak mobility
18
Weak mobility

• In the case of weak mobility, agents are allowed
  to transfer data only at specific instances.
• Weak mobility puts smaller requirements on the
  agent systems
• Traditional programming languages can be used
  Java, Perl, Python, Lisp
• Smaller performance penalty
• But there are still a number of challenges

19
Challenges in soft mobility

• Platform independent code
• How do I handle heterogeneous systems?
• What about _extremely_ heterogeneous systems?
• How to collect state / data?
• How to mark checkpoints (when is mobility
  possible)?
• Authorization, security, resource management
• Reliability problems
• How do I handle open files and other local
  resources?
• How do I handle global names? How do I send a
  message to a mobile agent? What is the address of
  the agent?

20
Agent systems with weak mobility

• Most agent system designers considered that
  migration is a relatively rare even in the life
  of the agent system.
• Thus weak mobility
• The agent system is allowed to migrate, but
  migration is not a fundamental type of operation,
  but a problem to be solved
• In Telescript, migration was the basic
  communication primitive!
• Examples
• Aglets, Jade, Concordia, Grasshopper, Bond 2,
  aIsland (JXTA)
• About 60 agent systems on the Mobile Agent List
• http//mole.informatik.uni-stuttgart.de/mal/mal.ht
  ml

21
Standards for weak mobility

• Object Management Group (OMG), an international
  consortium dealing with interoperability
  specifications (e.g. CORBA)
• MASIF Mobile Agent Facility
• A specification, released in 2000, specifying how
  CORBA based agents should implement weak mobility
• There are a number of conformant agent systems
  (eg. Grasshopper, partially Aglets)
• As of yet, FIPA did not release any standard for
  agent mobility.
• But they did for mobile (nomadic) users, eg. PDAs
  etc.

22
Aglets

• Java based mobile agent system
• I have chosen to present this because of its
  major focus on mobility
• Research project at IBM Japan (from 1996)
• Danny Lange and Mitsuro Oshima
• http//www.trl.ibm.com/aglets/index_e.htm
• As IBM decided to phase out the project it was
  released as an Open Source project
• http//aglets.sourceforge.net/

23
Aglets (contd)

• Goal Provide an easy and comprehensive model
  for programming mobile agents without requiring
  modifications to Java VM or native code

24
Aglet Lifecycle
25
Agent lifecycle

• Instantiating
• Creating a new aglet from the codebase
• Cloning (the clone has the same state as the
  original but different identity)
• An aglet can dispatch itself to a remote server
  by calling the Aglet.dispatch(URL dest)
  primitive. To be more precise, an aglet occupies
  the aglet context and can move from this context
  to others during its execution. Because the
  server may serve multiple contexts within one
  Java VM, and one host may serve multiple servers
  in one host the context are named as the
  following set
• the address of the host, typically IP-address.
• the port number to which the server is listening.
• the name of context within the server.
• Example atp//aglets.ibm.com1434/context_name
• ATP// Aglets Transport Protocol

26
Aglet lifecycle (contd)

• Dispatching causes an aglet to suspend its
  execution, serialize its internal state and
  bytecode into the standard form and then to be
  transported to the destination. On the receiver
  side, the Java object is reconstructed according
  to the data received from the origin, and a new
  thread is assigned and executed.
• Aglets can be persistent. Since a mobile aglet
  needs to be serializable into a bit-stream, all
  mobile aglet can be persistent in nature. The
  Aglet.deactivate(long timeout) primitive causes
  an aglet to be stored in secondary storage and to
  sleep for a specified number of milliseconds.

27
Migration events in Aglets
28
Security issues in aglets / mobile agents

• For secure agent execution, the agent system must
  provide the following security services
• Authentication of the Sender, the Manufacturer
  and the Owner of the Agent.
• Who is responsible for this agent?
• Who is responsible for the agent code?
• Has the agent (code and state) been tampered
  with?
• Authorization of the Agent (or Its Owner)
• What can this agent do? (E.g, can this agent
  access files?)
• Secure Communication between Agent Systems.
• Can the agent protect its privacy?
• Non-repudiation and Auditing.
• How can we ensure that a deal has been actually
  carried out?
• Security-sensitive activities of agents must be
  recorded, and an administrator must be able to
  audit them.