Introduction

1.1 What are agents?

The concept of agents is not an unfamiliar one. The precepts of agent technology have existed in many of the applications we use today and take for granted. For example, your e-mail client is a type of agent. At your request, it goes about its business of collecting your unread e-mail from your mail server. Contemporary e-mail clients will even presort your incoming messages into specified folders based on criteria that you define. In this manner, the software becomes an extension of the user, performing tasks on the user's behalf. Indeed, the computer itself can be considered an agent, as its primary task is to increase productivity through automation.

Recently, intelligent agents have come to vogue. These agents have some degree of artificial intelligence and are capable of taking judicious decisions within their realm of expertise. For example, the e-mail client can exhibit some sort of artificial "intelligence" to determine the importance of a particular piece of e-mail - possibly by scanning the message text for indicators of urgency. However, not all agents need to be intelligent.

One of the most interesting and much vaunted category of agents is mobile agents. Mobile agents can themselves be intelligent or non-intelligent. Unlike static agents, which are restricted to operate within a single machine or address space, mobile agents have the ability to migrate about the network, executing tasks at each location, potentially interacting with other agents that cross their paths.

Mobility is a common characteristic of many agent definitions. A mobile agent is an active object that can move both data and functionality (code) to multiple places within a distributed system. It doesn't matter what the ultimate purpose of the agent is or whether or not it can be classified as "intelligent". A mobile agent should be able to execute on any machine within a network, regardless of the processor type or operating system. In addition, the agent code should not have to be installed on every machine that the agent could potentially visit; it should move with the agent's data automatically. Therefore, it is desirable to implement agents on top of a mobile code system, such as the Java virtual machine (VM). The dynamic nature of Java classes and objects, combined with advanced networking capabilities, makes Java highly qualified for use as a mobile agent platform. Just as an applet's classes are loaded dynamically from the Web server into the browser, an agent's classes are loaded at runtime over the network as it travels from one location to another.

Mobile agents are defined in formal terms as objects that have behavior, state, and location. A subset of behaviors of every agent is inherited from the basic agent model, notably those behaviors that define the means by which agents move from place to place. Mobile agent models almost always define a method of interagent messaging as well. Finally, a mobile agent model is not complete without defining a set of events that are of interest to the agent during its lifetime. For example, the event of arriving at a new location is a momentous one in the life of an agent and generally entails the invocation of one or more of its behaviors. The set of events varies a bit from model to model, but the following is a list of the most common ones:

Creation - A handler for this event should initialize state and prepare the agent for further instructions.

Disposal - A handler for this event should free whatever resources the agent is using and prepare the agent for burial.

Dispatch - Signals the agent to prepare for departure to a new location. This event can be generated explicitly by the agent itself upon requesting to migrate, or it can be triggered by another agent that has asked this agent to move.

Arrival - Signals the agent that it has successfully arrived at its new location and that it should commence performing its duties.

Communication - Notifies the agent to handle messages incoming from other agents and is the primary means of interagent correspondence.

Thus mobile agents have mobile code and data that is transferred over the network. Once it reaches a host machine, its code enables it to execute a set of operations determined by the creator of the agent.

There are several applications where the mobile agents paradigm can be used successfully solve existing problems. The following is a cross-section of possible problems and is by no means exhaustive.

User passivity/data timeliness

Applications that demand immediate reaction to incoming streams of real-time data, regardless of whether the users are at their desk or not, fit well into an agent-based architecture. This is perhaps the classic application of agents, whereby the agent acts as a digital proxy for a human user, interacting with incoming data streams on the user's behalf.

Multi-staged/multi-processed calculations

Cumbersome calculations often can be broken into discrete units for distribution among a pool of servers or processors. Each of these discrete units can be assigned to an agent, which is then dispatched to an "agent farm," where the work is actually performed. Upon completion, each agent can return home and the results can be aggregated and summarized.

Untrusted collaborators

Mobile agents can collaborate with other agents by meeting in pre-specified "neutral turf." These agents could be from different product groups within the same organization or even from different, possibly competing, companies. Like distributed objects, agents communicate through well-defined interfaces and are usually protected from intrusion or inspection by other agents by the agent host. Unlike distributed objects, however, a compromised agent rarely poses a security threat to the owner's network, since the agent does not have access to internal network resources until it returns home. Even then, it can be barred access to networked resources by the agent host.

Low-reliability/partially-disconnected networks

In systems with low-reliability or frequently disconnected networks, agents can save network retries by moving the executable content to the data source rather than repeatedly attempting network connections to the data source. An example of such an environment is one in which a majority of users rely on notebook computers networked via dial-up connections. Prior to disconnecting from the network, agents can be sent to a server to perform off-line calculations. Upon reconnecting, the agents can be recalled to the notebook machine for local execution and a manipulation.

1.4 Applets vs Agents

Applets work in the following manner:

When a web-client requests a java applet by clicking on a link, the applet byte code (class file) is send to the client by the HTTP daemon. The client creates an instance of the applet class and calls the init method to begin the Applet. The Applet class loader installs a class loader for the applet that prevents it from making any IO calls etc. Thus in case of an applet, no data is carried from node to node besides the applet byte code. Also, the transfer is always between 2 nodes, the server and the client.

On the other hand, an agent is instantiated at the origin location only. And each of the subsequent locations carries this same instance of the agent. That means that the agent class is instantiated only once. This is necessary, as the agent needs to carry persistent data throughout its journey. Unlike an applet, an agent has the capability to move across many nodes during its journey and returns to the sender eventually. This ability of the agents to carry the code and data (state and behavior) across nodes make them much more powerful than applets.