Mobile Agents on the Internet - Aglets SDK (I) (EN)

Overview

• What is an Autonomous Mobile Agent?
• Generic architecture of a platform for AMAs
• Autonomous Mobile Agents and security
• …but are they useful for anything?
• Conclusions

This is the first of a 3-part series. See the 2nd and 3rd parts.

---

The concept of an Autonomous Mobile Agent is both fascinating and fearsome: code capable of sending itself at will until it achieves the objective of the task it was entrusted with… I admit it sounds like a killer virus, yes, but the ignorant and scared die before the cautious and informed. In this series, we will try to show that they are much more fascinating than fearsome, that sometimes the bad guy is not the one who arrives but the one who awaits the arrival, and that despite what they tell us, only those we want to enter our house do.

As we advanced in the introduction, in this small series of articles we are going to talk about autonomous mobile agents in general, and about the implementation on the Java platform that IBM Japan has made of them: Aglets ¹.

The objective of the series is to present the mobile agent paradigm to the reader as a very promising alternative within the framework of distributed computing and the construction of complex systems from simple social behaviors. But less talk and let’s get down to business…

What is an Autonomous Mobile Agent?

As we will see later, an AMA (Autonomous Mobile Agent) is a special type of agent with the ability to move through a network and decide its final destination.

But to properly understand the part (Autonomous Mobile Agent), we will first describe the whole (Agent). An agent is a computer program specifically designed to perform a well-defined task, with minimal interaction with the user, and a design that allows us to interpret it as an independent and capable entity. The TYPICAL CHARACTERISTICS OF AN AGENT box shows some of the most common characteristics that we can find in agents.

The intuitive idea of an agent is that of a program that does something for us, that is, that given minimal guidance on our part, it carries out a task of our interest.

The Office 97 assistant is a familiar example of an agent. We perceive it as an entity in itself, as a servant or collaborator willing to help us find the information we are looking for. Its ‘intelligent’ design, another possible characteristic of agents, as well as the iconography used (associating the assistant, for example, with a friendly paperclip) manage to multiply the illusion of an independent and capable entity. Of course, it is still a program, but the perception of it as a useful entity capable of performing tasks for us makes it a tool that we no longer want to do without. Before the assistant, we had a search engine; now we have a specialized worker at our entire disposal.

If by now the reader has not begun to understand the conceptual change to which the massive use of agents leads us, it is because they are unable to value the work of thousands of specialized workers willing to work tirelessly for us. Or maybe they should keep reading, and see if anything good comes out of all this.

But let’s narrow it down a bit more; let’s move from agents to mobile agents. A mobile agent is an agent on which we can perform the following operations: we can stop its execution, store its state in a permanent medium, send it (code and state) through a network, recover its state in the new host, and resume its execution at the point where it was left. This can be interesting, for example, in the following framework. Imagine an internal network of a research group that has a mobile agent infrastructure to optimize the computing resources of its 10 most powerful computers. The agents perform all kinds of tasks: from managing automatic e-mail lists to performing costly calculations on demand (recording consumption, to bill later). In order to optimize the computing capacity of the 10 computers, the mobile agent manager moves agents to the least loaded computers at a given time. This achieves better use of resources and minimizes computation time by parallelizing the most costly tasks.

Finally, if we continue to narrow it down, we arrive at Autonomous Mobile Agents (AMAs from now on). An AMA is a mobile agent programmed to jump to another host when it deems it appropriate (see Figure A). An AMA may want to jump to another host for different reasons, ranging from having finished its task on it and wanting to send itself to the next one on the itinerary, to sending itself to any active host because it receives a notification that the one it currently occupies is going to be disconnected.

As we can see, AMAs are a very special type of agent and, therefore, require a very specific platform.

Fortunately, although the final implementation varies, we can define the general aspects of these platforms (or support) for working with AMAs quite clearly. We will see that this clears up many doubts.

Generic architecture of a platform for AMAs

Any support architecture for AMAs will have the following elements:

• AMAs
• HOST application for AMAs
• AMA/HOST interface
• Security subsystem
• Serialization/deserialization subsystem
• AMA transport protocol

The final implementation can be very varied, but the basic structure is always the same. We will try to explain clearly how these elements are combined to support AMAs.

We already know Autonomous Mobile Agents, so we will first talk about the HOST application for AMAs (when we talk about Aglets later in the series, we will call this application “context”). The HOST application, which we will assume runs in its own execution subprocess, is in charge of managing the hosting, security, and transport of the AMAs. It must be able to create, delete, send, and receive AMAs automatically and in a secure environment for the system administrator or user. Nothing prevents a computer from having two or more HOST applications.

The AMA/HOST interface is the communication mechanism between the AMA and the HOST application. Thanks to it, the AMA can request to be sent to another HOST application (either on the same computer or on a different one), create child AMAs, self-destruct, etc.

The security subsystem provides mechanisms so that the execution of unreliable or unknown AMAs does not endanger the system. As we will see later, the architecture must contemplate not only security against unreliable AMAs but also against malicious HOST applications.

The serialization/deserialization subsystem is in charge of converting the AMA (code+state) into a binary sequence that can be transferred over a network, as well as creating an AMA from said sequences.

Finally, the transport protocol is the negotiation protocol between HOST applications to transfer AMAs to each other.

Given the demanding security measures, and their intrinsic multiplatform nature, mobile agent architectures have at their core some type of virtual machine that interprets the agents’ code; Java, therefore, greatly facilitates their design. Not in vain, although some platforms have their own specific-purpose VM, the vast majority are built on Java.

Autonomous Mobile Agents and security

After reading the scenario presented, we can easily reach the following conclusions regarding the security offered by working with Autonomous Mobile Agents:

• Without a HOST application that waits for and manages the arrival of AMAs, none will ever enter our computer (see Figure B). Only those you want to enter your house do. So no unplugging the modem so that we don’t get infected by some agent of the Cold type, is that clear?

• The security system against malicious AMAs will be as good as the HOST application is capable of limiting the resource access privileges of the agents that arrive.

• A malicious AMA is as bad as a HOST that is dedicated to altering the code and/or the state of honest and useful AMAs. Sometimes the bad guy is not the one who arrives, but the one who awaits the arrival.

The key element of security is, as we see, to enclose the executable code of the AMA in an isolated and secure region, and then limit its access to the system’s resources (disk, screen, network…).

Some readers may be wondering how an agent can then do anything useful, if it arrives at a host that limits all its actions. The answer is simple if we think in human terms: the agent must arrive at its destination, explore and recognize the environment, and negotiate with local agents that do have privileges so that they provide it with information or perform the tasks it wants (see Figure C). For these interactions to take place, the HOST must provide some means of communication between AMAs, as well as distinguish between trusted agents (with privileges) and untrusted ones (without them).

An example of all this, very simple and easy to design, is a file server agent. An agent that comes to the host in search of a file will request our file server agent to access such and such a file. Following our instructions, the local agent (with access permission, for example, to the /agents/ftp directory and subdirectories) will respond to the navigation requests made by the newly arrived agent. It may require a password, an encryption key, or anything else we can think of.

…but are they useful for anything?

This simple question, typical of practical bosses and usually answered with a “we haven’t found its proper application yet, but it seems very promising,” has cut short hundreds of “promising” lines of research.

Most likely, whoever first seriously imagined AMAs (perhaps Jim White, see ²) was thinking more about the fascination of having mobile code with autonomy, than about solving a software problem. However, after the fascination and the initial research stage, AMAs have found their usefulness in different areas.

First, they have an important field of application in client/server architectures where the number of transactions between multiple clients and the server are numerous and the bandwidth is reduced. An AMA-based architecture solves this problem by moving an agent to the server so that, once there, it performs locally all the transactions that were previously done remotely.

AMAs also solve well certain problems created by unreliable or intermittent connections. As an example, a certain host could send an agent to perform some laborious or long task, and go into off-line mode (turning off the modem, for example). The agent, once the task is finished, would try to return to the home host. Unable to do so, it would wait patiently, checking from time to time, for its home host to wake up. Once it went into on-line mode, the agent would return bringing the results that were requested.

The design of classic client/server architectures is greatly simplified with the AMA model, as client and server can be implemented as agents with a well-designed common messaging system.

Finally, AMAs solve very well those problems in which, due to their complexity, it is easy to define the behavior of the elements and their relationships, but difficult or impossible to model the overall behavior of the set. Let’s think, for example, of the enormous capacity of an “ant” society compared to one of its members.

Conclusions

Of everything that has been said here, the following points should be very clear:

• AMAs are useful for certain tasks and under certain conditions. In addition, they initiate a new way of thinking within the field of distributed computing.

• Their potential must be weighed against security aspects.

• Security will be as good as we want it to be; we can initially limit access to everything, and only then give light or non-problematic permissions.

Many will have noticed that we have not yet talked about “Aglets”; we will not do so until the next installment of the series.

The objective of this first installment was only (and if it has been achieved, it is already a great achievement) to arouse curiosity among those who did not know about AMAs, and to resolve some doubts among those who already knew them.

---