By David Reilly
Abstract : Mobile agents are agents that can physically travel across a network, and perform tasks on machines that provide agent hosting capability. This allows processes to migrate from computer to computer, for processes to split into multiple instances that execute on different machines, and to return to their point of origin. Unlike remote procedure calls, where a process invokes procedures of a remote host, process migration allows executable code to travel and interact with databases, file systems, information services and other agents. The technology behind mobile agents is examined, and an analysis of its uses and implications is offered.
Mobile agents have been the focus of much speculation and hype in recent years. The appeal of mobile agents is quite alluring - mobile agents roaming the Internet could search for information, find us great deals on goods and services, and interact with other agents that also roam networks (and meet in a gathering place) or remain bound to a particular machine. Significant research and development into mobile agency has been conducted in recent years , and there are many mobile agent architectures available today . However, mobile agency has failed to become a sweeping force of change, and now faces competition in the form of message passing and remote procedure call (RPC) technologies.
In general, the following things are required to allow agents to migrate across a network
If a process is to migrate from one host to another, then both hosts must share a common execution language. In a homogenous networking environment, it's conceivable that assembly language or machine code could be sent across the network for execution. However, such a system would be extremely limited, and not very future proof.
A more likely scenario for mobile agency is a heterogeneous environment, where many different system architectures are connected. In this case, an interpreted scripting language or emulation of a system that is capable of executing machine code  solves the problem of a common execution language.
For processes to migrate to remote machines, they must be capable of saving their execution state, or spawning a new process whose execution state will be saved. This property is called persistence. Persistence involves converting the object's state (variables, stack, and possibly even the point of execution) and converting it into a data form suitable for transmission over a network. Agents should not have to be responsible for achieving this themselves, and process persistence would likely be built into the mobile agent language or architecture.
Some communication mechanism must exist to transfer agents across networks. An agent might be transferred using TCP/IP, or by using a higher level of communication such as RMI, IIOP, SMTP or even HTTP. Mobile agent architectures may even use a variety of transport mechanisms, giving greater flexibility.
An agent's executable code must be transferred, which may consume a large amount of network bandwidth, unless shared code is located at the agent host. Techniques such as shared libraries of code, or caching, may be of benefit. In addition, the persistent state of the agent must be transferred.
Security is critical when executable code is transferred across a network. Malicious or badly written code could wreak havoc when unleashed upon an unsuspecting host, and agents themselves need protection against hostile hosts that would seek to dissect or modify them. There is no magic solution that will solve all the security problems of mobile agents, but precautions can be taken to minimize risk.
When an agent leaves for a new host, extreme care must be taken to prevent unauthorized modification or analysis of the agent. Agents may carry with them confidential or sensitive information and logic, which shouldn't be accessible to the agent host. Encryption may be of benefit, but the data and code must be decrypted at some point in time for the agent to execute. Once this occurs, the agent becomes vulnerable, and is at the mercy of the agent host. In a scripting language, the internal logic of the agent is exposed, but even compiled languages can be decompiled with a disturbing degree of success .Other than using trusted hosts, there is little that can be done to protect the agent from snooping eyes.
For agent hosts, the news is a little more positive. Through the use of digital signatures, the identity of an agent and its user can be authenticated. However, in many commercial environments, even un-trusted agents will need to be accepted. These agents may carry with them dangerous payloads, such as code that needlessly consumes CPU time and memory, that attempts to damage the agent host or carries back information that would make it vulnerable to hacking. Such is the risk an agent host must take, though limiting access to resources such as disks and the network may offer some solution.
If mobile agents were to gain widespread commercial adoption (to the degree that say, web browsing or email has), then what type of a network would we have? The following list of implications is by no means exhaustive, but does provide an interesting set of observations.
One of the goals of mobile agency is to conserve bandwidth, by placing an agent directly at the point of information, rather than sending dozens or even hundreds of queries across the network (General Magic, 1998). This is based on the premise that these queries would have consumed more bandwidth than sending an agent over the network, and bringing it back again .
Bandwidth conservation is an admirable goal, but whether mobile agents will help realize this goal is questionable (Harrison, 1995). For bandwidth to be conserved, the bandwidth consumed by sending across a mobile agent, and waiting for its results, must be less than that of a series of queries sent via a messaging or RPC system. This is a determination that must be made in practice, and cannot be fully verified just by theory.
Many scenarios can be foreseen. Perhaps mobile agents could comb through large amounts of resources on a single site, and bring back a small number of matches, in a similar nature to a search engine. However, some electronic commerce models suggest that mobile agents would be sent out to multiple sites, perhaps to negotiate low prices with vendors (a shopping-bot). This sort of activity has the potential to result in an incredible explosion of bandwidth consumption.
Indeed, searching is a task that many people would like to see mobile agents performing. Currently, a small number of indexing agents collect information for search engines, while millions of queries are made by users. Imagine if the same number of queries were made instead by mobile agents that traveled across the network to sites. Two scenarios are possible. Either a much larger amount of bandwidth (and CPU usage for the agent hosts) will be consumed, or a much lesser amount of bandwidth will be consumed as users receive more accurate search results because their agents have more control over the search process. Instinct suggests, however, that a simple keyword query entered via a web browser will consume less resources and bandwidth than sending an agent with specialised searching algorithms across the network.
The Internet, as it stands today , is made up of many millions of computers, some of which are permanently connected but the majority of which connect via dial-up modem connections for short periods of times. Imagine if you could delegate tasks to mobile agents, that would roam the network for you while not connected. This goal would be extremely desirable in the short term, until permanent connections became more prevalent. Here mobile agents may have found a sound market. This market could potentially be profitable, for the mobile agent technology vendors and the agent hosts that allow offline usage of their network.
Delegation of tasks to mobile agents could also be used as a form of load sharing in distributed systems. Agents could perform tasks on remote systems, moving from system to system as required to balance the load. Mobile agency also gives greater flexibility, because new tasks and new code can be added to the system without the need for a fixed codebase.
The ability of mobile agents to fragment themselves into many pieces that travel to different points across the network sounds promising. It might enable new forms of interaction, such as negotiating agents that travel to vendors seeking the best deal, or meeting places where agents can "get together" and communicate. The attraction of mobile agents for electronic commerce is great, and it might make sense to deploy mobile agents for electronic commerce. However, such uses could also be accomplished by message passing, or direct communication using application protocols like HTTP. Mobile agency is promising, but it is not the only mechanism for new uses of software agents.
If mobile agents were to become commonplace, serious privacy concerns would be raised. Aside from deliberate attempts to decompile or interrogate an agent (or its encrypted data), agent hosts could also monitor the actions of agents, and create consumer profiles. Even knowledge of the types of queries, or the way in which an agent searched, could reveal information about its owner. When individuals query a search engine, there is some degree of anonymity, but there is less control with mobile agency .
Mobile agency faces stiff competition from other technologies that can achieve similar outcomes, such as message passing or advanced forms of remote procedure calls. Some of the more notable technologies that offer competition to mobile agency are discussed.
Software agents need not always travel across a network to communicate with information sources, or other agents. One of the most important message passing systems for agents is the Knowledge Query Manipulation Language (KQML). KQML is an important mechanism for communication, because it allows much more complex forms of interaction than query/response mechanisms. KQML allows agents to communicate using a rich set of messages called performatives, and is capable of communicating attitudes about information, rather than just data and facts (Finin, 1998). Message passing systems like KQML don't require mobility, they can simply pass a message and have it delivered through some transport mechanism.
Remote method invocation allows Java developers to write distributed systems that share objects. New objects can be transferred across the network, and RMI is becoming a popular mechanism for agent communication. RMI can be used to facilitate mobile agency (acting as a transport mechanism), or as a replacement that allows agents to invoke methods of other agents.
CORBA is a platform and language independent mechanism for invoking remote object methods. Unlike RMI which is specific only to Java Virtual Machines, CORBA can be used to create distributed systems that execute on many platforms, in many languages. CORBA holds great potential, because of its portability and flexibility. CORBA is a direct threat to mobile agency, and would allow developers to create agents that are capable of complex communication without ever traveling across a network.
Mobile agency has yet to achieve widespread acceptance, and there are significant barriers to be overcome before it does. Competing technologies, increasing network bandwidth, and barriers to mobile agency make it unlikely that mobile agency will leave the domain of research and enter the domain of electronic commerce. This is not to say that mobile agency does not have its place - specialized situations and environments will continue to use and develop mobile agents. Load sharing across a network of agent hosts, and delegation of tasks to agents for offline processing hold great potential. Additionally, as more research and development into mobile agency is made, the picture may become brighter for other applications. As it stands, however, mobile agency does not appear to be commercially viable for widespread usage by industry and the general public.
Finin, Tim, KQML Web, 1998 [online] at http://www.cs.umbc.edu/kqml/
General Magic, Mobile Agents White Paper, 1998 [online] http://www.genmagic.com/technology/techwhitepaper.html
Harrison et al, Mobile Agents: Are they a good idea?, March 28 1995 [online] at http://www.research.ibm.com/massive/mobag.ps
These additional resources may be of benefit to readers interested in experimenting with mobile agency.
General Magic Odyssey http://www.genmagic.com/technology/odyssey.html
IBM Aglets http://www.trl.ibm.co.jp/aglets/
ObjectSpace's Voyager CORBA http://www.objectspace.com/products/voyager/index.html
1 - General Magic has been at the forefront of mobile agent development, with their Telescript language, and other mobile agent research such as Odyssey.
2 - A full list of mobile agent architectures is beyond the scope of this report. Some architectures use custom scripting languages, while others use Java which helps to solve the problem of portability. Recent Java systems include IBM's Aglets, and General Magic's Odyssey.
3 - Java is a good example of this. Java byte code is capable of executing inside a 'virtual machine', which is then implemented on many architectures to achieve a degree of portability.
4 - Decompilation and reverse engineering is always a risk when releasing executable code, and when agents containing highly useful information or programming are made available, the rewards of decompilation can be great. For more information on decompilation, see http://www.davidreilly.com/jcb/articles/decompilers_friend_or_foe.html
5 - Virus like activity could easily be concealed within a mobile agent. Even legitimate purposes, such as accessing a database, could be misused, if many agents grouped together to form a denial of service attack.
6 - Efficient mobile agent mechanisms might only bring back the data that has changed, since the executable code would still be present at the point of origin. Others mechanisms might just send back a summary of the agent's results, or additional code/objects that the agent may have collected
7 - Today being November 1998