An Infrastructure for Mobile Agents: Requirements and Architecture
چکیده
Mobile agents constitute a new approach to the architecture and implementation of distributed systems. A mobile agent is a program with a persistent identity which moves around a network and can communicate with its environment and other agents. Possible applications for mobile agents include network management, information retrieval, distributed simulation, remote device control, active documents and mobile computing. We are developing an infrastructure for the support of mobile agents which is based on a network of ‘agent servers’. Each of these controls the agents visiting a host, allows for status checks and intervention by the agents’ owners and provides a means of communication for the agents under its control. Mobile agents can be written in a number of programming languages such as Tcl and Perl; the agent environment provides runtime support through dedicated libraries that add relocation and communication capabilities to the respective language. Our implementation is based on HTTP (the Hypertext Transfer Protocol) as used on the World-Wide Web; this allows us to leverage off the massive research effort which currently focuses on issues like Web security and enables convenient access to the agent environment via the Web. INTRODUCTION With the recent explosive development of computer networkingand the Internet, a gap has developed between the sheer amount of information that is available and the ability to process or even locate the interesting pieces. This does not only apply to ‘application-oriented data’ such as scholarly publications, stock exchange quotes, or weather satellite images, but also to the monitoring and operation of huge computer networks. The increased number of available services has also lead to a profusion of mutually incompatible user interfaces, making it difficult for people to actually take advantage of all that is offered. Agents may show a possible way out of this dilemma – programs that help their users perform routine chores and assist them during complex tasks. In a computer network, mobile agents may move around on behalf of their users, seeking out, filtering and forwarding information or even doing business in their name. The issues surrounding the infrastructure needed for such agents and, in particular, their communications and security are being studied by numerous researchers. This paper outlines our research efforts at the University of Frankfurt, where we have been developing an experimental infrastructure for the support of mobile agents. After introducing the concepts of agents and, in particular, mobile agents in more detail and giving examples of their possible applications, we examine the basic functional complexes required for mobile agents such as transport, communications and security. We then give a short description of our experimental agent environment. A brief overview of ongoing projects in our group concludes the paper. MOBILE AGENTS Definition of an Agent Agents, intelligent agents and agent-based systems have attracted considerable interest from many fields of computer science, most notably artificial intelligence, distributed systems, computer communications and software engineering. Unfortunately there is little consensus among researchers about exactly what they consider an agent to be: A radically AI-based viewpoint is held by Selker (‘Agents are computer programs that simulate a human relationship, by doing something that another person could otherwise do for you’ (Selker, 1994)) while Minsky, less anthropocentrically, defines an agent as ‘a system that can serve as a go-between, because of possessing some specialist skill’ (Minsky and Riecken, 1994). Genesereth and Ketchpel’s agents are ‘software components that communicate with their peers by exchanging messages in an expressive agent communication language’ (Genesereth and Ketchpel, 1994). Finally, John Ousterhout’s approach forms a purely distributedsystems/software engineering point of view: agents are a means of overcoming the incompatibility of programming interfaces, data formats and protocols in a heterogeneous computer network: ‘the data is the application: agents’ (Ousterhout, 1995). Our dictionary defines an agent in the general sense of ‘anybody who acts on behalf or in the interest of somebody else’ (Div., 1971). When we started doing research into agents, we decided to approach the problem ‘from the bottom up’. That is, we are more interested in the technical question of how best to support agents (whatever they are) in a computer system rather than the philosophical question of whether or when agents (whatever they are) can be called ‘intelligent’— we’ll be glad to let the AI community settle this question. Our working definition of an agent is ‘a program that helps a user perform some task (or set of tasks), possibly by maintaining persistent state and communicating with its owner, other agents or its environment in general’. (This definition is, of course, very broad indeed, but suffices as the basis for our current work.) Agents can relieve users of routine work or facilitate complex tasks; another important application of agents is the interconnection between incompatible software products to generate new, synergistic solutions (Ousterhout, 1995). One can also view agents as a generalization of the clientserver paradigm of distributed computing: access to servers is mediated by agents which apply special knowledge of, e. g., where certain informationmay be found and how to obtain it. In this sense, World-Wide Web indices such as ALIWEB (Koster, 1994) can be considered agentbased. Agent Mobility Given the agent definitions outlined in the previous paragraphs, we can easily conceive of agents that go about their tasks not only on their owners’ computers, but by moving about in a network of computers, seeking out information on their owners’ behalf or even negotiating or concluding business deals for them. This notionof mobile or itinerant agents is analyzed, e. g., by (Harrison et al., 1995) and (Chess et al., 1995). It is important to remark that mobile agents have the potential of moving between hosts of their own volition, i. e., the agent code includes explicit commands that cause the agent to ‘go elsewhere’ and continue working just like before the move. This is in contrast to ‘server-side scripts’ which are available in current database servers. Agent mobility is a natural generalization of the concept of ‘stationary agents’ above. It also carries the extension of the client-server model even farther: with mobile agents, clients conceptually send parts of themselves to the server (or several servers) for execution (Chess et al., 1995). Another angle of approach is from the point of view of active mail—electronic mail messages that contain programs which are activated during various phases of delivery or perusal (Borenstein and Rose, 1993). Many of the issues that surround active mail, such as program transport, security and so on, are also important to mobile agents, and much of the work that went into the specification of standards for active mail (Borenstein and Freed, 1993) is helpful in this context. Applications of Mobile Agents Mobile agents can be useful for many applications. Most obviously, information retrieval on the network can be supported much more efficiently if an agent representing a query can move to the place where the data are actually stored, rather than having to move all of the data across the network for sifting (and subsequently discarding most of the transmission). This works especially well for nonanticipated queries, i. e., the implementor of a database system cannot in general foresee everything users might want to find out and provide code to do the relevant analysis. Thus, if users have to write their own custom retrieval software, an agent-based approach can save a lot of network traffic. This is even more evident when taking into account that agents can move to other sources of information if that seems more promising. Techniques such as semantic routing—dispatching a query according to where it is most likely to be answered, rather than according to some predetermined addressing information— can be used to further boost such a system’s utility and ease of use. Another area where mobile agents can profitably be used is network management. In big networks, comprising hundreds or thousands of connected computers, operations monitoring and fault detection is very difficult and involves large amounts of logging data. It is not possible to prefabricate diagnostic programs for every eventuality, but it would be feasible to use mobile agents to keep tabs on the system, home in on possible trouble spots or perfomance bottlenecks and bring them to the attention of the maintainers. Goldszmidt and Yemini introduce such a system based on ‘delegation agents’ (Goldszmidt and Yemini, 1995) which are dynamically linked into remote processes. As an aside, the potential of mobile agents for network management is of apparent interest to telecommunications companies, especially since current deregulation schemes keep increasing the importance of ‘quality of service’ as perceived by their customers (Lawrence, 1995). Electronic commerce is another domain which seems amenable to mobile agents: Business on the Internet is becoming a reality, and, as standards for electronic payment are deployed, commercial ‘premises’ accessible via the net will probably mushroom. Mobile agents can help locate the cheapest offerings, negotiate deals or even conclude business transactions on behalf of their owners. Of course, the legal and commercial implications of largescale electronic commerce are daunting and cannot be discussed in this paper. Mobile agents may be a way for customers to stay on top of these developments. Finally, an important application of mobile agents concerns mobile computing. Portable computers become smaller and more powerful, but wireless access to a fixed information infrastructure is likely to stay slow and cumbersome due to restrictions on radio transmission. Besides, to minimize power consumption and transmission costs, users will not want to remain on-line while some complicated query is handled on their behalf by the fixed computing resources. Mobile agents offer a promising way out of this dilemma: users simply submit mobile agents which embody their queries and log off, waiting for the agents to deposit their results ready to be picked up at a later time. Obviously, none of these applications absolutely require the use of mobile agents—most could be handled by stationary programs and some suitable communications paradigm such as RPC. However, this could only be done at a price of increased system (and network) load and, possibly, at the inconvenience of the users. Thus there is merit in researching the details of mobile agents for these applications. It is also important to point out that agents are not forced to move, even though the system may allow them to do so. Some agents may be too big to move comfortably, and for others there may be no necessity. Such stationary agents could still communicate with their mobile counterparts to take part in an agent-based system. AGENT INFRASTRUCTURE REQUIREMENTS Agents must interact with their hosts to make use of their services and negotiate with other agents about services. Mobile agents must also be able to move about in a heterogeneous computer network. We call the underlying mechanics that allow them to do so the agent infrastructure and the entity providing support for agents on a particular host an agent server. Besides these basic services, an agent infrastructure must also provide security to protect the host (and the agents) from unauthorized access and eavesdropping. This section discusses these basic requirements in detail. Structure of an Agent While the previous section looked at agents from the point of view of their users, we must now examine their structure from the system’s perspective. We have already noted that agents consist of code as well as persistent state. Obviously an agent’s code can, in principle, be written in whatever programming language is convenient. However, there are practical issues that render certain kinds of language potentially more useful for mobile agents in heterogeneous networks. The first important consideration is that an agent’s code should run in an identical fashion on every host it can move to. In this respect, traditional languages like C are at a disadvantage because they are usually compiled to an architecture-specific machine language and thus must be transported as source code. This would not be a problem in itself, but it turns out that even between, e. g., various implementations of Unix the C language environments, their completeness and standard conformance vary to a degree that renders automatic, transparent recompilation infeasible. Making this scheme work and extending it to cover MS-DOS, Macintosh and VMS (to name but a few other operating systems that might be taking part in a heterogeneous network) seems a difficult task indeed. There is much more promise in languages which are either interpreted directly or compiled to a portable intermediate interpreter-based language which can then be easily transported and executed without recompilation. Languages of the first kind include Tcl (Ousterhout, 1994) and Perl (Wall and Schwartz, 1990), while Java (Gosling and McGilton, 1995) serves as an example of a language of the second kind. For both approaches, only the (intermediatecode) interpreter must be ported once to allow for the direct execution of all the programs written in that language. Interpreting a program as opposed to executing it in a system’s native machine code naturally entails a speed penalty, but in many cases the benefits of easier mobility outweigh this, especially when CPU-intensive tasks like searching full-text indices can be offloaded into local libraries that execute at full speed. Besides, the speed loss suffered through ‘virtual’ machine code as exhibited by languages like Perl and Java can be much less than an order of magnitude, depending on the application. Currently there is no consensus about which programming language is ‘best’ for agents. In fact, most of the projects being undertaken use their own languages (e. g., General Magic’s Telescript (White, 1994), IBM’s research project using Object REXX (Atkinson et al., 1995), Sun’s HotJava (Gosling and McGilton, 1995)), many of which are proprietary. In our opinion a viable, open infrastructure for mobile agents should not force users into accepting some fixed language but rather encourage them to use the one best suited to their applications, while maintaining a common base of interoperability so agents written in various languages can still communicate and work together. Besides its code, an agent carries persistent state that allows it to take up its work after a move to another host at the point where it left off before moving. In the simplest case, the agent’s global variables must be preserved across the move, as well as a notion of where the agent’s code is to be reentered. This can be supported trivially by putting a multiway branch at the very beginning of the agent code to jump to the correct place according to the contents of some global variable, although more sophisticated schemes could encode a representation of the agent’s execution stack (complete with subroutine call frames and local variables) as part of the state. This would let the infrastructure reinstate the agent exactly where it executed the ‘movement’ command on the previous host. (Whether this is actually possible depends on the implementation language of the agent rather than the agent infrastructure.) In some languages it would be possible to represent an agent’s state as part of its code during transmission, for example by prepending an appropriate sequence of assignment statements to the code proper, but this does not appear sufficiently general to support, e. g., the encoded-stack example cited above. The third part of a mobile agent consists of the attributes which describe the agent, its requirements and history to the infrastructure. This includes data such as a unique agent identifier, the agent’s owner as a target address for intermediate results, error messages or complaints about an agent’s misbehaviour, the place and time of origin and a movement history. The attributes may also state limitations on an agent’s mobility (e. g., an expiration date or constrains like ‘do not move more than 3 hops from foo.bar.com’, ‘stay within the baz.edu domain’) or a search horizon (‘return at most 100 references with a score of at least 20’). Agents may be required to express their resource requirements (‘needs 5 megabytes of RAM’) or limitations (‘$5.49 left to pay for information retrieval services’) as well as requirements on the environment that they need to perform their tasks, such as ‘access to a bibliographic database according to the FOO or BAR standards’. Finally, an agent must carry authentication information which lets the infrastructure verify the credentials of any user who wants to stop or recall the agent or check on its progress as well as any passwords or keys it needs to gain access to restricted information, if this is necessary. Transport One of the key features of mobile agents is their power to move from one host to another. The difference between this type of mobility and the one encountered in, e. g., load balancing systems that allow for the relocation of processes is that such a move happens at the agent’s explicit request rather than through some decision by the operating system (without the agent even noticing). That is, the implementation language of the agent includes a statement or library call of the form ‘MOVE-TO hhosti’, where hhosti is the host the agent wants to visit next. When this call is executed, the agent is suspended, encoded for transmission, transmitted to the new host, decoded and installed to resume running at its new location, more or less where it left off. An important question in this context is how an agent picks a host to move to. In the simplest case, a mobile agent can carry along an itinerary of places, visiting them one after another while carrying out its chores. It is of course more interesting to let the agent modify its destination according to the discoveries it has made during its previous exploits. For example, during a bibliographic search at some site an agent notices a large number of relevant papers written by researchers at the University of Foobar. The agent might then try moving there in order to maybe find even more interesting information locally. Another possibility would be for an agent server to advise an agent about interesting places in the ‘neighbourhood’ (not necessarily geographical)—in our example, other collections of bibliographic information. This information can be tailored according to the origin or purpose of the agent in question. The advantage of this scheme is that no server needs complete information about all the possible destinations for mobile agents. It suffices for each server to know about its own vicinity, but agents will still be able to traverse ‘interesting’ subsets of the whole network using, for example, depth-first search (Tarjan, 1983). This approach also facilitates the construction of ‘firewalls’ or bounded domains that restrict agent movement. Yet another approach to the dispatching of agents is known as semantic or deep routing, which tries to determine an agent’s destination on the basis on what it wants to accomplish rather than explicit address information. For example, an agent whose stated goal is to subscribe its owner to a certain publication could be transparently routed by the infrastructure to the appropriate publisher. Chess et al. consider deep routing a part of their ‘agent meeting point’ (Chess et al., 1995), but in our opinion this functionality does not have to be part of the agent infrastructure itself. It can be provided just as well by another (stationary) agent which communicates with its clients through the mechanism put forward in the next section. There seems to be a market for ‘directory agents’; some agent’s first move might be to a site where a directory agent can point it to the appropriate place. This approach is especially useful in the context of mobile computers, which should not be expected to dedicate scarce resources like CPU time or memory to the support of a full semantic router. Communications To do useful work, agents must be able to communicate with the host system, other agents, and possibly their owners. A basic model for inter-agent communications exploits the notion of an abstract information space. This is an entity maintained locally on each agent server by the agent infrastructure on behalf of the agents in its charge. The information space can hold triples of the form (key; access; value); where key is a unique name for a triple, value is an opaque content of arbitrary size and access is an access control list which enables access to the triple for specific agents, groups of agents or all agents. The operations supported by the information space include writing a triple and reading it either destructively (it is removed from the information space after having been read) or non-destructively (it remains in the information space). All these operations are assumed to be atomic in order to avoid race conditions, and more advanced communication schemes such as synchronous or asynchronous RPC, multicast or broadcast can be constructed on top of these primitives. Additional operations which would be nice to have include the ability for an agent to register interest in changes to a specific triple in the information space or in additions to the information space as a whole. This would prevent agents from having to busywait or periodically poll variables for changes and would increase the overall efficiency of the system. The main purpose of the information space is to allow agents to communicate with one another, but it can also be used to implement communication between agents, the agent infrastructure and the host system. For example, the agent server can use the information space to make available data of general interest to agents, e. g., a list of the agents currently running on the host. We can also envision a trusted stationary agent whose privileges allow it to collect data on a host and distribute summaries to visiting agents via the information space. It would be obvious to generalize this communication model to include access to a server’s information space from elsewhere on the network. Such a ‘global information space’ would, however, not be arbitrarily scalable without losing its efficiency. Besides, given that agents can move easily between hosts, it is not at all clear that extending the model for agent communications in this way will actually buy much. Of course, the existence of the information space does not preclude agents’ access to different means of communication. If high-bandwidth data transfer between agents is desired, the agents in question may be allowed to use dedicated connections or even shared memory. This is of less concern to the agent infrastructure proper than to the runtime support lent to the agents. For example, the infrastructure could arrange to pre-open the necessary communication channels when agents are invoked so the agents themselves do not need to be endowed with the general privilege of network or IPC access. The section on runtime support examines this in more detail. Finally, agents should be able to communicate with their owners and vice-versa. The simplest approach to this is to let the agent send electronic mail messages to the owner’s address given by its attributes. This asynchronous style of communications ties in nicely with the fact that the agent owner may be logged off or using a mobile terminal and thus may not be on-line when the agent’s message comes in. If an agent needs to communicate synchronously, for example to ask confirmation for some action, it will have to be suspended until the answer is received but this does not pose much of a problem in principle. Runtime Support The agent infrastructure must provide runtime support to agents for number of reasons: Since agents need to take advantage of the infrastructurefor mobilityand communication services, appropriate operations must be available in the agent’s implementation language. This includes operations to let the agent move to another server, to access the information space and to communicate intermediate results or questions back to its owner. A facility which lets an agent inspect its attributes would also be quite desirable. Another important reason for specialized agent runtime support is that agents are not supposed to misuse their access to the host system, e. g, by mailing its password file to some cracker or by formatting the system’s main hard disk. The best way to enforce this kind of security is to disallow such operations in the first place, or to control them tightly such that the arguments to ‘unsafe’ operations are carefully vetted and the operations rejected if they seem suspect. Safe-Tcl (Borenstein and Rose, 1993; Borenstein, 1994) implements this by distinguishing a trusted and an untrusted environment—the agent runs in the untrusted environment and may perform safe calls using operations exported from the trusted environment. The trusted environment checks their validity and forwards them to the underlying system for execution if they are acceptable. This approach parallels the one seen in operating systems which commonly distinguishes user mode and kernel mode; the computer hardware can only be accessed directly by code running in kernel mode (such as the operating system), which executes operations (system calls) on behalf of software running in user mode. It is important to be aware that the level of trust extended to an agent may differ considerable depending on the agent. For instance, a locally developed agent is going to be rather more trustworthy than some random piece of software which has just arrived over the net. By suitably constructing the runtime environment for various types of agents, more trustworthyagents may be allowed more extensive access to the host system’s resources. The runtime environment of an agent can also be enhanced by special, problem-oriented functionality suitable for the purpose of the agent. For example, an agent whose goal consists of bibliographic research could ask for access to a full-text search engine which would be provided by the database suppliers so the agent does not have to carry its own version along with it. Of course this needs agreement between the suppliers and the agent authors, but a judicious standardization effort in this context can go a long way to make agents simpler and enhance their mobility. Besides, rather than overfilling an agent’s runtime environment, operations such as the mechanics of database search can be executed on behalf of visiting mobile agents by dedicated stationary agents that make their results available via the informationspace. This would also allow for increased efficiency, for example by caching the answers to often-encountered queries inside the stationary agent. In the simplest case, the runtime environment for agents may be implemented in a language-specific manner, supporting each agent implementation language by a runtime package written in that language. Eventually, a set of standard operations may emerge that could then be made available using language-independent services such as CORBA (Object Management Group, 1991). Security Maybe the most important issue for the wide acceptance of agent-based systems concerns security. Many people associate mobile agents with the well-known threats posed by malicious software such as viruses, worms or Trojan horses. In the previous subsection, we have seen how we can protect an agent host system from interference by evil agents. It is less clear how to keep a server from tampering with agents in its charge, or even from looking at the code of an agent that implements, e. g., a competitor’s negotiation strategy. Given current operating system technology, there is no practical way a determined attacker can be prevented from re-engineering an agent’s code while it is executing on a system under the attacker’s control—a sufficiently motivated person could always single-step the agent process or analyze its memory image. The only answer to this dilemma, for the time being, seems to be the use of neutral ‘premises’ operated by a trustworthy, disinterested third party which serve as a meeting place for mobile agents that want to conduct sensitive negotiations, auctions or similar events. Agents can be protected from eavesdropping and manipulation during a move by suitable encryption methods. Given the scheme outlined above, where the agent server on a host knows about the servers in its vicinity, it is easy to support public-key encryption for agents being transmitted: Part of a server’s knowledge about its neighbourhood can consist of the appropriate public keys to be used for the various destinations. Since key management can be regarded as part of the management of the local agent infrastructure, the agents themselves do not have to deal with the encryption/decryptionprocess at all (Rivest et al., 1978). A PROTOTYPICAL INFRASTRUCTURE We have been implementing a prototypical infrastructure for agents according to the discussion above in order to support various experiments in agent-based systems. This section briefly surveys our design goals, the prototype’s structure and its implementation. Design Goals Agent-based systems are still a comparatively new idea. Therefore a platform for research into mobile agents should embody maximum flexibility to support various schemes and architectures which appear worth trying. While there is no obvious answer to the questions of which languages are most suitable for agent implementation and communication, which interaction patterns mobile agents should use and how they should discover their destinations, different approaches must be evaluated. Our prototype makes no assumption about the languages agents are written in, nor does it limit the optionsavailable for their communication. Its goal is to provide ‘mechanism, not policy’ for agent-based systems. The mechanisms offered by our prototype remain on a fairly low level compared to those postulated by Chess et al. (1995); this is quite intentional because we are interested, at this stage, in the essential support needed to get an agentbased system off the ground. Besides, we believe that it is important to keep the basic infrastructure as simple as possible in order to expose the underlying concepts more clearly, and also to keep the implementation less prone to errors. Many of the advanced services like semantic routing can be provided in a modular way within the framework of cooperating agents. Our prototype also encourages interoperation of agents implemented in various languages; the low-level abstraction of the information space is accessible to imperative and declarative approaches to agent communications alike and allows for a seamless integration of the two. Implementation We decided to use the Hypertext Transfer Protocol (HTTP) (Berners-Lee et al., 1995) as the basis for our agent infrastructure. HTTP is the basis of the World-Wide Web (Berners-Lee et al., 1994a), and it is a widely accepted, well-understood protocol which is currently undergoing formal standardization. It contains all the necessary primitives to provide agent mobility and communications as outlined above, and its specification expressly leaves room for custom extensions which could be defined if necessary. There is a lot of ongoing research into issues like encryption or electronic payment in the context of the World-Wide Web that will be easy to integrate into an HTTP-based agent infrastructure. Furthermore, the essential device-independence and widespread usage of Web software like browsers make it easy to provide an interface to the agent infrastructure which is available to just about everybody withno significant learning effort. A common protocol base will also facilitate the integration of agent-based services with those offered on the WorldWide Web. Therefore agent support becomes a ‘valueadded service’ that can straightforwardly be supplied by Web sites. For transmission by HTTP, agents are encapsulated using the MIME Internet standard (Borenstein and Freed, 1993). A mobile agent is represented in MIME as a multipart content of type application/agent with attributes giving the implementation language, type and ‘context’ to help the agent server infer the kind of runtime environment desired. The multipart content consists of at least three parts (content subtypes agent-code, agent-state and agent-attributes) which make up the agent as discussed above. Suitable transfer encodings allow for the transmission of agents which are compiled into portable byte-codes as well as those that use binary state information; the encoding and decoding of agents for transmission is part of the agent infrastructure’s job. In the context of HTTP this is usually not much of a problem, since HTTP is defined to be 8-bit transparent, but the same conventions could be used to transmit agents by MIME mail, where safe transmission cannot be guaranteed in general. This similarity between mobile agents and active mail (Borenstein and Rose, 1993) seems worth pursuing at a later date. Our implementation relies on a custom HTTP server written in Perl (Wall and Schwartz, 1990). This server accepts mobile agents through the usual HTTP protocol requests (POST) to specific URLs (Berners-Lee et al., 1994b) as well as queries about agents’ whereabouts and status. We consider the server where an agent is initially submitted the home server for that agent; it will subsequently serve as a base for interaction between the agent and its owner. The agent is assigned a home URL as a handle for future reference. If the agent moves to some other server, that server generates a visitor URL for the agent and communicates this back to the home server, so that future queries and interaction will be forwarded to the right place. This is done using the HTTP facilities for transparent redirection, which common Web browsers handle without involving the user. For example, some agent’s home URL is http://foo/home/a1. The agent is now moving from host bar to host baz and is assigned the visitor URL http://baz/visit/a33. Host baz notifies host foo that the agent a1 is now running on baz by POSTing the visitor URL to http://foo/home/a1, the agent’s home URL on foo. If the user wants to find out where her agent is currently located, she points her Web browser at the home URL (http://foo/home/ a1). The local agent server returns a HTTP response stating that the agent has ‘moved temporarily’ (HTTP response code 302) and is now to be found at the visitor URL. The user’s Web browser now transparently fetches the agent status from http://baz/visit/a33. This way the user does not have to keep track of an agent’s progress for herself. Requests for interaction like recalling or stopping an agent are handled in a similar manner, as is the ‘information space’. It can be accessed via special URLs, but this is restricted to agents under control of the same server by a ‘magic cookie’ authentication mechanism (Berners-Lee et al., 1995). The initial implementation of our infrastructure supports agents written in Safe-Tcl and Perl, although other agent implementation languages can easily be added. The server consists of about 1500 lines of Perl code and can be easily deployed on a Unix-based workstation. We plan to make a cleaned-up version of the infrastructure available to the public in December 1995. CONCLUSIONS AND FUTURE WORK We have given a general introduction to the issues underlying mobile agents and their applications, their structure, transport, communications and security aspects. We have also briefly sketched our experimental implementation of an agent infrastructure based on the Hypertext Transfer Protocol. Our group is currently researching various applications of mobile agents, such as distributedscheduling of meetings, semantic routing as well as information retrieval (based on Usenet news). Other areas that we hope to investigate include the mapping of declarative agent communication languages like KIF/KQML (Genesereth et al., 1992; Finin et al., 1994) on the ‘information space’ paradigm and an application of HTTP security mechanisms to our agent infrastructure.