Agents
One kind of mobility might more properly be called "transportability". A transportable program is any program that can run in more than one environment - typically a separate machine. Software that requires a single, unique environment is not transportable. A program able to run on any instance of a class of machines (such as for example a program designed for Macintosh computers) is transportable.
Clearly transportability is a fairly trivial variety of mobility and most people would be unlikely to think of that attribute as mobility at all. However, a lot of the issues of transportability (and a related idea, that of portability) are also issues with mobility - these will be discussed below.
A higher level of mobility is that evidenced by systems such as Java (Sun, 1995); the ability to be moved from one environment to another and to execute independently in that other environment, but without the ability to move themselves and without the ability to choose to move themselves. A Java program is moved from machine to machine by cooperating higher-level programs (servers and browsers); Java programs operate as tightly controlled subsystems of those higher-level programs.
The highest level in this little ad hoc taxonomy of mobility is what Chess et. al (1995) and others call "itinerant agents". Although still transported by a higher layer of software, such agents select their own destinations according to their goals. Importantly, since these agents can select their own destinations and are operating independently, they can move from destination to destination. They are not limited to one step. It is these agents that most people seem to mean when they use the term "mobile agent".
This last group of mobile agents can be further divided into agents which can be moved only before execution and those which can move during execution. Probably the best known of the latter group is Telescript from General Magic Inc., a commercial language and environment for the creation of mobile agents (White, 1995). Telescript is capable of preserving its internal state during a transfer from one machine to another (ibid., p.6).
When discussing mobility, it is tempting to think of the obvious separation, the obvious mobility of an agent moving between physically distinct machines. Some authors (e.g. Harrison (1995, p.iii) and White (1995) regard mobility exclusively in this light [1]. However, mobility is as valid a concept even if applied within a single machine - an agent may be mobile between virtual machines, between different users' dataspaces or between filesystems. Its extent may be as wide as the worldwide Internet, or as limited as a single multitasking system.
In a sense, mobility extends the environment of the agent to encompass the various locations in which it can operate and the mechanisms it uses to move between those locations. Certainly this is a simple way to allow the formalisms proposed by Goodwin (1993) to remain valid for mobile agents. However, simply expanding the term "environment" in this way is probably not useful, because it takes the focus away from the special set of problems that face mobile agents.
We have already discussed some issues of knowledge representation that are of concern for interacting or communicating agents. Mobile agents face all these problems and more.
All software requires some degree of support from its environment. At the most basic level, compatible hardware is needed. For all but the most basic software, other, lower layers of support software are needed also. Even on a single machine, the complete system is typically an extremely complex set of interacting components.
For mobile agents, each supporting component must be present at each destination, or at least a supporting component must be present that the agent can detect and adapt to (activities which themselves require some level of support).
The kinds of problems that directly face mobile agents include compatibility of hardware, operating systems, file formats, filesystem architectures, memory architectures and so on. These problems will be familiar to anyone who has ported software designed for one environment into another; agents must deal with these difficulties directly and dynamically.
On top of these fairly fundamental obstacles, we then have "meta-problems" such as routing.
Routing may be generically defined as the process of deciding where something is, then deciding how to move towards that location. Given that an agent requires a certain resource (such as a piece of information), how can it know where that information is?
Deciding where something is requires at some level a mapping of locations to things. There is a potentially unlimited set of desirable things, and a potentially unlimited set of locations where they may be found.
There is a limited set of general solutions to this question: The agent can inspect its environment, seeking the required information. The agent can consult a local directory - a set of pointers to locations either developed from experience or provided a priori. The agent can consult a meta-directory (pointers to directories held at other locations) and move to those locations to consult the directories there. Finally, the agent can request some other entity to provide the information.
The first two solutions scale exceptionally poorly. The third scales well, but is susceptible to synchronisation problems. The fourth simply defers the problem to the other entity.
The use of meta-directories or proxies also involves using communication bandwidth of some description, which in an environment containing many agents may be a significant drain on the resources available in that environment. In practice, some combination of these techniques is usually employed when dealing with this sort of problem (cf. name resolution in the Internet) but the basic issues remain.
Naturally the appropriate solution to this class of problems will depend very much on the size of the environment within which the agent is mobile. For an agent limited to a single machine, it may be that the set of locations can be exhaustively described or learned in its entirety.
For larger (or potentially unlimited) environments, only proxies or meta-directories are feasible solutions, though local caching of limited subsets of these may improve performance. Using any such information resource of course raises the related issues of trust and security.
Is mobility an essential attribute of an agent? It seems not. It is easy to imagine an intelligent, independently operating entity staying in a single environment and operating towards useful goals. However, there is no doubt that mobility in agents is a very interesting and useful concept.
There are numerous advantages to the use of mobile agents over more traditional techniques - Harrison (1995) and Chess et al. (1995) offer excellent discussions of advantages and disadvantages. By way of example, mobile agents can reduce the use of bandwidth by going to sources of information, performing local searches and sorts or other high-bandwidth operations and then reporting back with summarised information. A mobile agent removes the need for a permanent connection between a resource and the user - the agent can be dispatched to perform its task while the user drops offline.
The advantage is perhaps best summed up by White (1995, p.4), who puts it thus: "ongoing interaction does not require ongoing communication"
![[previous]](./larrow.gif)
![[index]](./b_arrow.gif){kind=icon}
![[next]](./rarrow.gif)