O'Reilly logo

Mobile Agents by Wilhelm R. Rossak, Peter Braun

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

2.2 A Short History of Mobile Agents 17
execution state. At site S
B
, virtual machine M
U
B
executes the code, providing
access to the resources located at S
B
. Later, the code may decide that it needs
other resources at other sites, (e.g., S
C
), in which case the code will migrate
to another computer again.
Mobile Agents Need an Environment
Obviously, mobile agents need some kind of environment to become alive.”
What we have simplified as virtual machine in Figure 2.2 actually consists
not only of the interpreter for the programming language but also of the
execution environment for agents, which is called the agent server or agency.
An agency is responsible for hosting and executing agents in parallel and
provides them with an environment so that they can access services, commu-
nicate with each other, and, of course, migrate to other agencies. An agency
also controls the execution of agents and protects the underlying hardware
from unauthor ized access by malicious agents.
Today, many different types of agencies exist. Many universities and also
some companies have developed their own product, and we will use the
name mobile agent toolkit in the following to describe such a product. The
most prominent examples today are Aglets by IBM and Grasshopper by IKV.
Later in this book, we introduce Tracy, which is the mobile agent toolkit that
was developed by our team at the University of Jena.
A single agency only rarely makes sense, particularly in the case of mobile
agents. In addition, even a network of several agencies is still not thrilling
unless some mobile agents are roaming the network, using services to fulfill
some task. Therefore, we will discuss at least two agencies, which then form
a mobile agent system that defines the space in which agents live.
2.2 A Short History of Mobile Agents
As we have pointed out, the mobile agent paradigm relies heavily on the idea
of mobile code. Thus, to some extent, we must consider mobile code as an
ancestor of mobile agents.
2.2.1 The Early Approaches of Mobile Code
The idea of sending code in an architecture-independent for mat to dif-
ferent hosts via a network was mentioned, probably for the first time, by
18 Chapter 2 From Client-Server to Mobile Agents
Rulifson [1969]. He and his colleagues introduced the Decode-Encode-
Language (DEL), which was published as RFC 5.
5
The idea was to download
an interpretative program at the beginning of a session while communi-
cating to a remote host. The downloaded program, written in DEL, could
then control the communication and efficiently use the small bandwidth
available between the user’s local host and the remote host. Later, Michael
Elie improved this concept and proposed the Network Interchange Language
(NIL) as RFC 51 in 1970.
About 10 years later, a group at Linkoping University in Sweden had
the idea to build a packet-oriented radio network they called Softnet. Each
packet sent over the network was a program written in the FORTH program-
ming language, and each network node that received a packet immediately
executed this FORTH program. Using this technique, every user was able
to instruct every network node to provide new services. More infor mation
can be found in a paper by Zander and Forchheimer [1983]. Shoch and
Hupp did the first exper iments with mobile software at Xerox, where they
wrote worms to traverse their local area network seeking idle processors
[Shoch and Hupp, 1982].
2.2.2 Remote Evaluation
Joseph R. Falcone faced the problem of providing client-specific interfaces to
remote services across a heterogeneous distributed system [Falcone, 1987].
In contrast to offering a single interface with many small functions to sat-
isfy the possibly high number of clients, Falcone wanted to enable clients
to program their specific interfaces themselves, using a well-defined new
programming language NCL (network command language). In NCL a client
sends an NCL expression to a server, which then executes this expression
using standard functions provided in form of a library. The server sends the
result (again an expression) to the client, which can start a computing process
again. Thus, what we have here is primitive mobile code in both directions.
Independently of Falcone, Stamos developed the remote-evaluation (REV)
approach, which extends the idea of remote procedure calls introduced by
Birrell and Nelson (Birrell and Nelson [1984]; Nelson [1981]). The motivation
for REV is the same as that for NCL. In REV a client sends a request to a
5. Request For Comments, see www.rfc-editor.org for more information about RFCs.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required