7.2 Mobile Agents

7.2 Mobile Agents

7.2.1 Introduction

The ultimate goal of me-centric computing is to allow fast and pervasive access to information and services, through desktop machines at work, school, and home, through televisions , phones, pagers , and car dashboards, from anywhere and everywhere. Mobile code and mobile agents are essential for allowing such access.

Mobile agents are programs that can migrate from host to host in a network, at times and to places of their own choosing. An agent is an autonomous, intelligent , collaborative, adaptive computational entity. Here, intelligence is the ability to infer and execute needed actions, and seek and incorporate relevant information, given certain goals. The state of the running program is saved, transported to the new host, and restored, allowing the program to continue where it left off. Mobile agent systems differ from process-migration systems in that the agents move when they choose, typically through a "jump" or "go" statement, whereas in a process-migration system, the system decides when and where to move the running process (typically to balance CPU load). Mobile agents differ from "applets," which are programs downloaded as the result of a user action, and then executed from beginning to end on one host.

Mobile agents are an effective choice for many applications, for several reasons, including improvements in latency and bandwidth of traditional client-server applications and reducing vulnerability to network disconnection. Although not all applications will need mobile agents, many other applications will find mobile agents the most effective implementation technique for all or part of their tasks .

Although we believe that current trends in Internet technology and usage lead to the use of mobile agents, several technical and non-technical hurdles must be addressed along the way. These hurdles represent significant but not insurmountable challenges, so we predict that many major Internet sites will accept mobile agents within a few years . If we look at mobile agents, they are built on the same feature set as immobile software agents. They are autonomous, which allows them to pursue an agenda independently of its user. This requires aspects of periodic action, spontaneous execution, and initiative, in that the agent must be able to take preemptive or independent actions that will eventually benefit the user.

Agents also need to be personalizable . This allows agents to support people to do some tasks better. Since people don't all do the same tasks, and even those who share the same task do it in different ways, an agent must be able to learn new aspects of a given task. Ideally, there should be components of learning built into the agent. The typical end-user should not have to program the agent. The agent should know what to do. Some agents can already learn by looking over the user's shoulder. Another very important aspect is the memory of the agent to make sure that whatever the agent learned can be reused next time.

A very important aspect of agents is the ability to communicate with the user. The agent should be able to give some feedback to assure the user that the agent is executing the right task with the right parameters. This generally requires a discourse with the agent, a two-way feedback in which both parties make their intentions and abilities known, and mutually agree on something resembling a contract about what is to be done and by whom. This conversation may be very short, involving only a request and a response, or a higher-level discourse in which the user and the agent repeatedly interact, but both parties remember previous interactions.

7.2.2 Mobile Code

If we come back to the levels of abstraction, we can see that in the past it was difficult to exchange code between devices, operating systems, or services. In the past, mobile code was usually machine-dependent and could run only on very specific machine architectures. Also, obtaining such code involved the whole process of searching for applications on FTP sites, downloading the applications, sometimes compiling them, and then running them on the local machine.

With mobile code, the code has been encapsulated to make the movement of the code possible. Mobile code is code that traverses a network in its lifetime and executes on a destination machine. Mobile code allows for pushing or pulling code (i.e., procedures or even programs) to or from remote sites, and for executing the transferred code at these sites. Examples for mobile code systems are Java applets, remote evaluation (RPCs where the procedures are transferred before calling them), or even Postscript files (which are programs that are executed on printers, for example).

Mobile code is the basis for mobile agents. Mobile code allows distributed systems and the abstractions to be more flexible to build and use. Mobile code enables distributed systems to adapt to application needs. Rather than fixing the interface to a resource and the pattern of interaction with it, a minimal interface can be defined and code implementing higher-level interfaces placed alongside it as required.

These higher-level interfaces can be application-specific, allowing for interaction patterns that were unknown at the time the resource was made available. Sending code close to a resource can also reduce network usage because the point of interaction with it moves.

Through mobile code, a richer functionality can be given to the interaction between processes. This means that application-level operations can be done on the network. By sending higher-order language features across the network, distributed components can be tightly bound together when they communicate. At the same time, familiar distributed systems can be built using mobile code.

Mobile code helps to support user mobility. Personalized environments that support state-saving can follow a user between computers. Heterogeneous state-saving allows a user's programs to be relocated between computers. By using a mobile code system with language support for state-saving, applications can direct arbitrary component migration without priming program servers with specific support.

One big issue connected to mobile code is security. Unfortunately, not all mobile code is good, but some code comes in the form of a virus trying to destroy data on other computer systems. Viruses are a kind of mobile code and, at the most abstract level, can't be distinguished from mobile agents; therefore, it is necessary to implement some security measures to reduce the risk of a virus infection. When mobile code arrives from an unknown or untrusted source, it would be a good idea to ensure that the software is safe to run. This can be done by applying certain restrictions to this untrusted software.

Untrusted mobile code should not overwrite critical system data, thereby causing a system crash. It should also only access memory in its own address space and not memory belonging to other applications and processes. Illegal disk operations, as a default policy, should also be forbidden.

The application's safety policy is a set of restrictions placed upon locally run untrusted code to ensure that the program does not behave in a manner that is detrimental to the system or to the system security. In Java, this is called the "the sandbox model," because each agent is restricted to operate in its own "sandbox." This policy should include at least the following safety properties: control flow safety, memory safety and stack safety. This means that mobile code should never jump to and start executing code that lies outside of the program's own code segment. All function calls should be to valid function entry points and function returns should return to the location from which the function was called. It should also never be allowed to access random locations in memory. The program should only access memory in its own static data segment, live system heap memory that has been explicitly allocated to it, and valid stack frames . And last, but not least, the mobile code should be allowed to access only the top of the stack. Access to other areas of the stack should be completely restricted.

Depending on the environment in which agents should run, additional and more complicated safety policies can be put in place. Only if these policies are in place and correctly enforced should one allow mobile code to be run on its computing device.