Work on mobile agents (MA), mobile objects and mobile code has become a hot research topic covered by many networking and software engineering conferences. Mobile code support frameworks are becoming so numerous that it is difficult to keep track of all of them. Certainly, Java is a principle factor that promoted mobility through dynamic class loading, direct support for networking and its portability. It is necessary however, to provide a certain classification of mobility approaches in order to be able to assess the application of Mobile Agents in Network Management. Our discussion is largely inspired by the classification provided in [Pic98]. We however emphasize that in contrast to many references that make use of the term “Mobile Code” as a general term for mobility, our unique concern is Mobile Agents, i.e. software agents that are in addition endowed with mobility features. Moreover, we focus mainly on those factors that affect the design of the MA. Techniques such as code pre-fetching and agent code repositories will not be considered, since they only allow to improve some performance parameters, but do not
affect the design of the agent itself. For better reviews of these aspect, refer to [Wil99]
and [Pic98].
2.3.1 Basic Components of a Mobile Agent Framework
A basic component of any MA framework is an MA server that runs on each host where MAs can migrate. The role of this server is to receive agents that want to visit its host and to help transparently transferring the agents to other hosts. We adopt the same ter-minology as [Pic98] and we call this server “Mobile Code Server” or MCS. When an MA arrives at a site, the MCS has to provide it with an execution environment. This execution environment is in general integrated with the MCS and allows the agent to gain access to the necessary resources for its execution.
MCSs communicate together in order to reliably ensure agent transfer. An Agent Transfer Protocol (or ATP) is used for this purpose. The ATP can be based on several possible protocols such as raw sockets, HTTP, or Java RMI. The role of the ATP is to put the agent in a serialized state and to transfer it to the next MCS, where it is deserialized to resume execution.
Besides these basic functions, an agent platform may include a large set of other mo-bility services and facilities. Fault tolerance is one important service that insures that agents are reliably transferred and are not lost because of a crash in the system. For ex-ample, persistent saving (checkpointing) of the MA is necessary to allow fault recovery in the case that the site on which the MA is running crashes.
Many available MA frameworks include directory and location services. These ser-vices allow the agents to be aware of the existence of other agents and to tract their loca-tions, for example to organize a rendezvous.
In order to provide an easy-to-use MA framework, it is also necessary to provide an agent development and deployment facility. In most of the cases, a set of classes and interfaces are supplied and should be integrated in the agent code in order to enable mobility. The deployment facility is an interface that allows the injection of MAs and the specification of their itinerary.
There is also an increasing need for an agent management utility that helps monitor-ing the operation of injected MAs and controllmonitor-ing their execution. For example, this may allow an agent owner to watch the progressive migration path followed by the agent.
Another important service is security, which concerns both the protection of hosts from malicious MAs, and the protection of MAs against malicious hosts. Security mech-anisms have to ensure authentication, integrity, confidentiality and access control. MA security aspects are detailed in [Vig98].
The Open Management Group (http://www.omg.org) defined MASIF (Mobile Agent System Interoperability Facility), a standard aimed at enabling the interoperability of MA platforms [Obj00]. Currently, MASIF is a reference model that defines a set of common concepts and support services for MA platforms. The standardized MA services include agent management, agent transport, agent tracking and agent security. The defined MA platform components include agent system, region, place, and MAFFinder. Examples of MASIF-compliant MA platforms will be provided in the next Chapter (Section 3.3.2).
2.3.2 Strong, Weak and Memoryless Mobility
A running MA can be broadly viewed as composed of data, code and execution state.
Strong mobility, as defined in [Pic98] and [FPV98], means that the agent migrates carry-ing all of its three parts, i.e. code, data and execution state. From a programmcarry-ing point of view, an agent might be running on a certain host and wants to migrate to another one. It calls a built-in migration function, e.g.moveTo (url)where theurlindicates the full path to the next host. This causes the agent code and data to be transported to the new host, where the agent resumes execution right where the migration functionmoveTo has been called. This leads to a highly transparent mobility, in which the agent migrates simply by calling a determined method.
In contrast, weak mobility means that the MA migrates only with its code and data, while ‘forgetting’ its execution state. From a programming point of view, weak mobil-ity requires an entry method, e.g.onResume, which is automatically invoked each time the agent resumes its execution on a new location. This entry method should contain the necessary code to re-establish the execution context of the agent, which is lost dur-ing the weak migration. Additionally, there might be another method (e.g.onMigrate) that allows the agent to prepare its migration before it is transported to the next host.
Although strong mobility offers an appreciated high degree of transparency to the MA regarding the migration mechanism, weak mobility still has the advantage to be easily implemented in MA frameworks. Despite this lower degree of transparency, weak mo-bility still ensures one of the main advantages of momo-bility, namely that of conserving the history and the past data of the agent.
Two other mobile code mechanisms are defined in [FPV98], namely Code on De-mand (COD) and Remote Evaluation (REV). Both COD and REV involve a piece of code that is downloaded to a certain location where it is executed. The difference between these two mechanism is strictly the standpoint of the user. COD means that the piece of code is downloaded from a remote location to be executed locally, whereas REV means that the piece of code is sent to a remote location where it is executed remotely. However,
if our standpoint is the MA itself, then both COD and REV become identical. We intro-ducememoryless mobilityto group them. A memoryless MA ‘forgets’ its history (i.e. both its data and execution state) when it migrates to another site. Concretely, this means that each time the agent arrives at a host, it is restarted again by having the MCS call a particular entry method such asonStart(or simplymain).
Interestingly, most of the existing MA frameworks use weak mobility. This is due to several reasons. The first is that most of these frameworks are based on Java, which can-not directly provide strong mobility. The reason is that Java threads are can-not serializable and therefore, the execution state of the MA cannot be transported. A second reason is that weak and strong mobility are equivalent from a functional point of view. The main difference with strong mobility is that it offers a higher degree of transparency to the MA programmer regarding migration aspects.
2.3.3 Remote Cloning
Another mechanism that provides a different kind of mobility is remote cloning. MA cloning is largely inspired by theforkprocess mechanism adopted in UNIX. Applied to MAs, the same principle consists in having an MA method, e.g.cloneAt (url)that pro-duces an exact copy of the MA, but on a different host. The two MA instances can be distinguished for example by their respective execution hosts. Importantly, cloning is combined with one of the migration strategies and can be either strong, weak or memo-ryless.
2.3.4 Single-hop and Multiple-hop Agents
Single-hop agentstravel to a target host, start their execution and remain there until they terminate. This kind of agent does not need any data when migrating to the target host (except maybe initialization data) and does not have to manage its itinerary. Therefore, single-hop MAs mostly compare to downloadable code, e.g. Java applets.
In contrast, Multiple-hop agents can travel to several sites during their lifetime.
Multiple-hop MAs can perform the same repeated task for each host they visit. They can also perform different tasks, and can adapt their behavior depending on the tasks achieved in the previously visited hosts.
2.3.5 Fixed and Dynamic Itinerary
In fixed itinerary, the agent migration path is known at its creation and it does not change during the agent execution. An example of a fixed itinerary agent is an MA that has to
travel to a determined list of servers to collect data. In this example, the itinerary is in general supplied by the user of the agent. In contrast, agents that support dynamic itinerary may change their migration path during their execution. In this case, the mi-gration is not necessarily specified at the moment the agent is created, but instead, is decided on-the-fly during agent execution. A discovery agent that is sent to discover new components in a network is a type of agent with dynamic itinerary, since its migration path can change when new components or subnetworks are detected.
2.3.6 Passive and Active Migration
Passive migration means that the migration decision is taken by another entity than the MA itself. Passive migration provides stricter control over the agent autonomy as far as its itinerary is concerned. Itinerary management is completely left to the user of the MA.
Passive migration can be combined with either a fixed or a dynamic itinerary.
Active migration means that the MA takes the decision to migrate by itself. Again it can be used either with a fixed or a dynamic itinerary. With a fixed itinerary, the agent still has to decidewhento migrate, although it cannot decide which host to visit next.
Summary
We showed in this section that although MA frameworks share the same basic infrastruc-ture, the supported types of MAs can differ significantly. Different types of MAs can by itself significantly lead to different approaches to the same application. In our opinion, an ideal MA framework has to provide support for building mobile agents of different types and features. This allows to select the optimal kind of MAs depending on the ap-plication for which they are deployed.