Robust remote interaction

RPC-based client-server computing was developed for LAN-based systems, where strong assumptions regarding communication integrity and server/infrastructure availability could be made. These assumptions are not valid in their strong form when moving from LAN structures to wide area networks (WAN), leading to reduced reliability of RPC-based client-server applications. Although RPC itself could be enhanced to better cope with such new environments, it would take great efforts to adopt all existing components to the improved protocol. Two properties of the mobile agent paradigm offer advantages in this field [5]:

Messaging- As opposed to RPC, messaging is dependent on reliable communications to a much lesser extent, because it does not require the receiver to answer a message before the sender continues processing.

Recovery- Mobile agents by nature have to deal with required servers or services being unavailable. Therefore, mobile agents have to carry the ability with them to deal with such situations, i.e., they have to "know" alternatives or how to find them.

While one might argue that RPC could be implemented using messaging, i.e., unreliable communication layers as well, it is clear that due to the method's synchronous nature, re-transmission delays in larger and more unreliable networks would eventually become unacceptable.

Recovery mechanisms are a more complex issue. Considering the case where a particular server is down, the simplest solution is to have a back up server that provides the same information and which is explicitly known to the agent. More sophisticated strategies for solving unavailability issues build on generalization of the information needed: the agent could "ask" other agents or hosts for alternatives. In such a scenario, the agent would not have to know what backup servers there are initially. Several techniques have been proposed to address this issue, many of them based on the Knowledge Query and Manipulation Language (KQML, see http://www.cs.umbc.edu/kqml/ [15]).

Technology of current agent systems

A number of agent construction tools have been developed recently, out of commercial and academic interest. While in the early days extensions of scripting and proprietary languages were used for the implementation of mobile agent systems, the rapid evolution of the World Wide Web and its underlying technologies has lead to a strong shift toward standards-centered approaches. Many of the younger agent systems are frameworks based on Java or extensions to that language. Examples include Aglets [9], MOLE [1], and Grasshopper [10]. To overcome one of the biggest obstacles to the widespread usage of mobile agent technology—the lack of interoperability between different (mobile) agent systems—a common standard for mobile agent system interoperability facilities has been proposed by the Object Management Group (OMG) [12].

The purpose of the following section is to identify the requirements that state-of-the-art agent environments must fulfill in order to achieve the aforementioned advantages. The ideas that have been promoted to meet these requirements will then be examined; however, the scope of this examination will be limited to such techniques that build on standards, and to standards themselves, like OMG's mobile agent system interoperability facilities specification (MAF) [12] or FIPA (Foundation for Intelligent Physical Agents) [6].

Requirements for agent systems

In this section we discuss what major issues have to be resolved in mobile agent systems, with special focus on the utility of those systems for the development of distributed systems. We concentrate on three areas: security, mobility, and communication/interoperability.

Mobility

The ability to relocate itself, i.e., initiate its own transport to another location raises the question how an agent system should deal with this situation with respect to an agent's context information. In particular, the following issues have to be addressed [3]:

serialization of the execution stack.

validity of object references.

When a mobile agent is to be transported to another place, it should in theory halt its execution at the current instruction and resume at the next one in the new environment. That is, it should preserve its execution stack as well as its heap data. This concept is known as strong mobility, whereas the less restrictive transfer of only the code without migration of the execution state is called weak mobility [16]. An interesting point to note here is the question of what happens if there is more than one thread belonging to the agent in question and strong mobility cannot be implemented. While in the case where there is only one thread it seems feasible to restore the execution state through the use of entry routines and explicit state variables, the overhead and potential sources of error of such an approach in a multi-threaded application clearly rule out this possibility [2].

The other major issue when discussing agent mobility support is tracking the validity of object references [3, 12, 13]. When an agent moves to another place, references to objects, for example, dynamically loaded classes or database handles that were used in the previous environment, become invalid. Agent systems therefore have to provide mechanisms to properly track, and re-establish on migration, object references needed by an agent.

It should be noted that code mobility is not a new concept introduced by the mobile agent paradigm. Process migration techniques had already been investigated some time before agent computing as a new area of research [16].

[1]  [2]  [3]  [4]  [5]  [6]  [7]