How to Integrate Mobile Agents into Web Servers�

Stefan Funfrocken

Department of Computer Science, Darmstadt University of Technologie,Alexanderstr. 10, D 64283 Darmstadt, Germany

Email: fuenf@informatik.th-darmstadt.de

Abstract

Mobile agents are a new paradigm for communicationand cooperation in distributed computing. To combine thenew paradigm with the promising World Wide Web platfrom,we integrated mobile agents into Web Servers. In this way,mobile agents may travel from Web server to Web server toaccess their local data. The paper describes how we inte-grated mobile agents support into a Web server. We presentthe state of implementation, and we give an outlook on ourfuture work.

1. Introduction

‘Mobile Agents’ are programs that can move from hostto host to fulfill a task on behalf a user. To overcome theproblem of heterogeneity, mobile agents are mostly pro-grammed in an interpreted language for which an interpreteris available for a wide range of computer systems. Usingan interpreted language also solves, to a certain extent, oneof the most important problems for mobile agent systems:security. Since the interpreter which executes the mobileagent is local to a computer system, it can be modifiedto intercept all ‘dangerous’ commands of the interpretedlanguage which interact with system resources. In thisway, foreign agents interact with the local system througha trusted third party. Currently, there is only one languagewhich was designed for use as an agent language: Tele-script by General Magic [17]. There are several interpretedlanguages which offer a so-called ‘secure interpreter’, likesafe-tcl [4] or safe-python [13]. Most of them, however,lack agent-related language constructs and concepts (e.g.,a language-provided command to initiate agent transporta-tion, or security concepts) and depend on external librariesfor such functionality.

Application areas for mobile agent technology includetasks as simple as information retrieval, but is also used

�Copyright 1998 IEEE. To appear in the proceedings of the WET-ICE’97 Workshop on Collaborative Agents in Distributed Web Applica-tions, June 18-20, 1997, Boston, MA

in mobile computing [15], telecomunication applications[12], electronic commerce [17], and other traditional areasof computer science. One special application area is theWorld Wide Web which is still growing at an exponentialrate, and buzzwords like ‘Web centric computing’ or ‘In-tranet’ promote traditional Internet technology everywhere.There we have a widespread, well-accepted architecture, towhich more and more existing traditional data and data pro-cessing applications (e.g., databases, newspapers, financialportfolio applications) are adapted and integrated.

To combine mobile agent technology with the potentialsand infrastructure offered by the World Wide Web, we de-veloped a Web server extensions module which allows Webservers to host mobile agents, so-called Web agents.

The infrastructure we present was developed as part ofthe WASP project. With the ‘Web Agent-basedServiceProviding (WASP)’ project, we aim at providing serviceson Web data and using mobile agents to implement theseservices. The underlying hypothesis is that services for theWorld Wide Web is one application domain for which themobile agent paradigm is a well-suited model.

One major goal of the WASP project is to offer means tosupport Web serviceproviding. This support includes on theone hand an infrastructure for Web agents which are used toimplement the services, and on the other hand tools to helpa service provider to generate and manage those agents.

The remaining part of this paper will focus on how we in-tegrated mobile agents into a Web server, that is, the WASPinfrastructure.

2. WASP Infrastructure

Integrating mobile agents into a Web server means toenable Web servers to start, receive, and execute mobileagents. Additionally, Web agents may access the Web dataof the server, may want to communicate with a user, andhave to be managed. Starting, executing, accessing Webdata, and management of agents is done by a special exten-sion module: theServerAgentEnvironment (SAE). In thisway, the code of Web servers does not need to be changed.

Of course, this implies that the server has to provide a well-defined interface like CGI, Jeeves’ servelets [8], or Jigsaw’sresource interface [2], which is able to pass all relevant in-formation to the SAE.

As an implementation language for our system and foragent-programming, we chose Sun’s Web language Java[1], which already provides code shipping by the means ofapplets and persistent, movable objects by the means of ob-ject serialization. Because of this, we found that it is veryeasy to implement a system that provides rudimentary mo-bile agent functionality. This is also supported by the factthat there are several other research projects that deal withJava-based mobile agent systems like Mole [7], Aglets [10],Java-to-go [16], and MOA [14]. To gain insight in Java’spotential as an agent programming language, and becauseof announced Java API packages (i.e., security and elec-tronic commerce) that offer valuable functionality in a stan-dardized way, we decided to build a system of our own - thisalso allows us to customize our environment to our specialneeds.

File

SAE

File

SAE

Agent

User’s Web Browser Web Server

normal HTTPRequest

normal HTTPResponse

read File

User’s Web Browser Web Server

Request

Response

Agent

Agent Redirect

Figure 1. General WASP Infrastructure

Figure 1 shows the overall architecture of the WASP in-frastructure which consists of a user’s Web browser, ourWeb server, and the server’s SAE. To traditional HTTP re-quests our Web server responds in the traditional way: itprovides the user with the desired data through a HTTP re-sponse containing the data. But when it receives an agentrelated request, the server hands it to its SAE to fulfill therequest. There is no need for the server to understand anySAE related request, it is sufficient that it identifies the re-quest as a SAE request to forward it to its SAE. In this way,any changes in SAE requests do not affect the Web serverimplementation. So far, we only need two SAE relatedrequests: one for agent startup and one for agent transfer.

Both are normal HTTP requests, which implies that we donot need a special protocol such as ATP (Agent TransportProtocol), which is used by the aglets [10] system.

Generally speaking, our scenario is divided into twophases: the agent startup and configuration phase, and theagent service phase. In the first phase, a user wants to accessan agent which is located at a Web server. The user uses itslocal Java-enhanced Web browser to connect to the serverand requests the start of the Web agent. Since all agentrelated actions are executed by the SAE, the server redi-rects the user’s request to it. The SAE loads and starts theagent. The first action of a Web agent is to get customizedto the user’s demands. To do so, it sends its graphical userinterface to the user’s browser, which returns the requiredconfiguration data to the agent after the user is done withthe configuration. After that, the second phase begins: de-pending on the configuration, the service is provided by ex-ecuting the Web agent. This normally requires that the Webagent accesses the local Web data of the server and may in-clude migration to other Web servers to access their Webdata. After completing its task, the agent may return to theserver by which it was started and possibly notify the userabout results of its work.

2.1. WASP HTTP Server

To have full control over the whole architecture, we use aJava Web server that was developed earlier by us. This Webserver was enabeled to accept Java scripts over the networkand execute them at the server location. After start of theWASP project, we redesigned the server and used it to inte-grate our SAE. Figure 2 shows the architecture of the WASPWeb server. Any incoming HTTP request, represented by arequest object, is handed to the request manager, which isresponsible to generate a HTTP response according to therequest. The request manager has a pool of managers whichit can instruct to process the request. Since HTTP requestsmay require different actions, there is a manager for eachtype of processing. So far, our server can handle requestswhich require to retrieve the content of a file, requests whichrequire the execution of cgi-bin programs and scripts, andagent related requests which require to contact the SAE.The requests are processed by the content manager, the cgimanager, and the agent manager respectively. The contentmanager is assisted by a mime manager, which is responsi-ble to set the correct mime content type of the response. Themime manager retrieves its knowledge at startup time fromthe system mime.types file. The content and cgi-bin man-ager, which both deal with files, use the document managerto access the files. The document manager, which is in factan interface to our W3 Data Interface (see Section 2.5), isused to hide the way a document is stored, thus offering anabstract view to the content and cgi manager: a documentmay be read, written, or executed, independent of the way

Response

Request

RealmManager

HTTPD

File

RequestManager

File System

Database

ManagerAgent

SAE

Web Server

ContentManager

W3 Data Interface

Agent

startrestart

read writeDocument Manager

execute

ManagerCGI

Figure 2. WASP httpd Architecture

the document is stored. Before any request is executed, theserver checks whether the request may need an identifica-tion of the user making the request (see Section 2.6).

To allow our Web server to host mobile agents, we de-veloped the SAE, which processes any agent related requeston behalf of the server’s agent manager.

2.2. Server Agent Environment

The SAE (see Figure 3) serves as an execution environ-ment for Web agents. Its primary task is to load Web agentseither from the local disk when an agent gets started, orfrom the network when a Web agent migrates itself fromsome other SAE. It has to execute the agent and guaranteeaccess and security restrictions specified by the administra-tor of the Web site during agent execution. Unlike otheragent environments, it provides Web agents with a uniforminterface to the server’s Web data (see Section 2.5) so that aWeb agent doesn’t have to care about the way Web data isstored locally. In addition to agent related tasks like agent

AgentGUIRealm

Manager

SAE AgentScheduler

ResourceManager

CommManager

Server’s Web Data

SAE

Security Man

ager

Net

wor

k

ManagerSAE Agent

Web Data Interface

read write

Agent

read write

start/restart

Agent

use server

realms

Server Realm Manager

ManagerServer Agent

Figure 3. SAE Architecture

management, agent scheduling, security, and resource con-trol, an execution environment has to address problems likeconfiguration, administration, controlled startup and shut-down, persistency in case of crash and recovery, which wealso care about by offering a configuration and administra-tion tool. A site administrator can use it by loading it intohis Web browser after identifying himself to the system.Concerning persistency, Java’s object serialization offers anappropriate way to implement object persistency in general.

2.3. Agent Startup

Web agents are physically divided into two parts: the ser-vice part which encapsulates the agent’s functionality, andthe agent’s graphical user interface which the agent presentsto the user at startup time. In this way, it is possible to of-fer more than one user interface to users. The agent maychoose its graphical user interface depending on a startupparameter, thus presenting different views to the same func-tionality. This architecture makes it possible to update andadd agent user interfaces without changing the code of theagent.

Figure 4 shows the agent startup scenario. All agentsthat are installed and may be started at a Web server are de-scribed on a normal HTML page, which contains a descrip-tion of the service each agent offers and a link to the agent.When a user requests the start of an agent by a HTTP getrequest to the agent URL, the server hands this request toits SAE that identifies and loads the agent. After loadingand starting, the agent sends its interface to the user’s Webbrowser. This is done through an agent-generated HTMLpage, which points to the agent’s GUI applet and serves asresponse to the user’s HTTP get request. The browser loadsand executes the Web agent’s GUI applet, which requestsall necessary information from the user. After the user isdone, the configuration data is sent back to the Web agent.Technically, the communication between the agent GUI and

Manager

redirect to SAE

Agent

Agent Gui

AgentGuiDisplay

Web BrowserGET Agent

Agent sends Pagepointing to its GUI

GET GUI

Agent GUI Applet

Web Server

Server’sWWW Data

inactive Agent

active Agent

SAE

Agent

A-Gui

Agent

managerRequest

starting AgentConfigurationInformation

Figure 4. Agent Startup Scenario

the agent is done through the communication manager ofthe SAE (see Figure 3 and Section 2.6). After starting aWeb agent, the agent informs the communication manager

that it awaits its GUI callback. In this way, the GUI can con-nect to the communication manager and request connectionto its Web agent to hand back the data.

By using a communication manager, it is possible thatthe Web agent’s GUI can wait for the return of its agentto pass back any result the user awaits. For this, the Webagent requests connection to its GUI from the communi-cation manager. For services which require some time, theagent may, after configuration, respond to the user with a re-sult URL. The user has to monitor this URL for the resultsof the service.

2.4. Migration

Web agents have to conform to a certain interface in or-der to enable the SAE to control the agent. Since we useJava as an agent programming language, we can providethis interface by a class from which any Web agent imple-mentation has to be subclassed. This, together with Java’spossibility to declare methods final and therefore unchange-able by subclasses, allows us to fill this template with pre-defined functionality.

In our scenario, Web agents migrate themselves to otherWeb servers by calling their go-method (inherited from theWeb agent template) with the new destination. This methoduses Java’s object serialization functionality to dump theWeb agent and initiates a HTTP post request to the spec-ified target Web server. The target URL is a SAE-specificURL which the target Web server identifies as a request ofan agent in migration to enter the system and hands it to itsSAE which handels the deserialization of the agent.

Since we use object serialization, the migration of Webagents is not transparent to the agent as for example in Tele-script [17] or ARA [15]: the flow of control cannot automat-ically be reestablished to that point in the code of the Webagent where it executed the go method. We consider this notto be a conceptual drawback, although this puts some bur-den on the programmer of the Web agent. As other systemsthat use this scheme of migration (Mole [7], Aglets [10],FFM [11], Tacoma [9]), we provide a special method whichis called by the target SAE when it restarts the flow of con-trol for a migrated Web agent. The agent programmer hasto fill this method in such a way that its agent will executethe correct code depending on its internal state.

Inside the post request, Web agents are transported asMIME [3] message. If the server requires any authentica-tion to perform the post request, the agent has to providethat information at the time it is sent (i.e., when the postrequest is constructed). For that purpose, the Web agenttemplate defines (unchangeable) methods which yield thenecessary security information, and provides the Web agentwith means to fill in that information (see Section 2.6).

2.5. Web Data Interface

To provide Web agents with a uniform way to access anyWeb data, we aim at developing a Web data interface whichhides the fact that the same type of Web data is stored andretrieved in different ways. Generally, a Web agent can readand write Web data such as a HTML page and it should notmatter whether the page comes from a file, is generated bya program, or by a database. Our current research in thispart of the project deals with integrating database-generatedWeb pages into this interface. Writing to such a generatedpage is nontrivial because not only the database data usedin the document has to be updated (which may include aschema modification) but possibly the generating programtoo. To offer the advantage of our Web Data Interface notonly to local Web agents, we use it as a document managerin our Web server implementation. This complements theview a remote user has of local Web data: he or she onlyrequests documents (i.e., document contents), independentfrom the way the data is stored at the server. We enforce theusage of our Web Data Interface by using a security man-ager which does not allow agents to use any standard Javalibrary I/O-method.

Web agents will not only be able to read and modify ex-isting data. To avoid restricting the service classes whichcan be implemented on top of our infrastructure, we allowagents to generate new Web data at a server. To preventany denial of service attacks of malicious agents that writea huge amount of data, we provide our SAE with a resourcecontrol and security model (see Figure 3 and Section 2.6).Technically, writing more data than allowed (either by re-source negotiation or by server rule) will yield an exceptionto which the Web agent should react or will get terminatedby the security manager on the next attempt to write moredata.

2.6. Security

For mobile agent systems, security is one of the mostimportant concerns. Site administrators allowing foreignagents to enter their system must be sure that the agent sys-tem prevents compromising their system. There have to bemeans to control agent access to the system, any resourceusage by agents, and access rights to local data. Becauseof the importance of security, we planed our infrastructurefrom the beginning with a security model in mind.

Data security is provided in our system by the means of‘protection domains’, so-called realms. A realm consists ofa set of data, specified by local URLs, to which access isrestricted. Any user or agent accessing the protected datahas to identify itself to the system by the means of a pass-word which, together with the user’s name or deduced formthe agent’s ids, is stored with the configuration data of therealm. For every realm there is an owner (human or agent)

who can define access rights for the realm (read, write, exe-cute).

In addition to specify access rights, it is important tohave a Web agent identifying scheme. For Web agents itis natural to have a manufacturer, who signs unchangableparts of the Web agent with its manufacturer id when re-leasing it. Additionally, there is an agent id which in com-bination with the manufacturer’s id has to be unique. Wheninstalled on some Web server, the server can assign a serverid to the agent. When started, an agent also gets assignedan incarnation id. An agent’s server id together whith theincarnation id can be used to identify Web agents that werestarted at a server, migrated, and returned. We are currentlyexamining which cryptographic technique and algorithmswe will use to achieve this.

When an agent wants to enter the system, it sends a httppost request to the Web server it wants to migrate to. TheURL of the post request points into the server’s SAE. Toallow only some well known Web agents access to the SAE,the site administrator can configure a realm consisting ofthe SAE entry URL and add the allowed Web agents to thatrealm.

Once the system is entered, access to any Web data maybe restricted by realms. There is no difference between auser or a Web agent accessing local data. When an agentaccesses restricted data, the Web data interface checks forthe agent’s presence in the list of allowed users and agentsfor that data and authenticates the agent by requesting itsids. In case of a human user, he or she is asked for its userid and password by his or her Web browser on behalf of theWeb server.

Every agent system offers critical system resources likeCPU cycles, main memory, disk space, and network accessto foreign agents. Because of this, agent systems have totake care about system resources and monitor their usage toavoid misuse. In our system, all Web agents are granted acertain amount of each system resource. When trying to usemore units than granted, the agent will receive an exceptionand is terminated when ignoring that.

In addition to our agent system’s inner security scheme,we secure all network communication, which occur in ourarchitecture when an agent migrates or when a Web agentreceives its configuration data by its GUI. In the first case,we encrypt the agent before transmitting it to the target SAEby using a session key. In the second case, we encryptthe data transferred. By doing this, we avoid that an agentin transfer is recorded, modified, and then resubmitted tothe target system, or is fooled by someone trying to submitchanged or illegal configuration data to the agent.

3. Using the SAE with Other Servers

We plan to offer our SAE as plug-in for Web servers,so that usage of it is not limited to our own Web server

implementation. To make use of our SAE, a foreign Webserver has to provide an interface which allows to hand theincoming request to the SAE and allows to hand back anyresponse. Most existing Web servers offer the cgi-bin inter-face, which provides this. Java based Web servers as Jigsaw[2] or Jeeves [8] can integrate our SAE directly. We devel-oped a Jigsaw resource object which connects our SAE tothe Jigsaw resource tree and are working on a Jeeves SAE-servelet.

In addition to connecting the SAE to the server, there isanother problem to solve: since Web agents executing in theSAE access local data which should be protected by the pro-tection scheme a Web server is using, the SAE has to respectthat scheme. Most existing Web servers offer simpler pro-tection domains than our server is offering: they limitanyaccess to the protected domain to the users registered in therealm. Our scheme has a finer granularity, by offering read,write and execute rights for priviledged and nonpriviledgedaccesses. Because of that, we have to incorporate the realmdefinitions of other servers in our realm system. The waywe have to incorporate the realms differs with the way theSAE is connected to the server: when using the SAE as cgi-bin, we have no other choice then reading the servers realmdefinition file. This also means that any changes made tothe realms have to be written to that configuration file. Incontrast to that, Jigsaw offers the possibility to access theJigsaw realm objects. In this way, we can make use of thatobjects. We are currenty investigating how we can incorpo-rate the realms offered by the Jeeves server.

Summarizing, one can say that connecting our SAE toother Web servers is done very easily by using a cgi-binapproach. But because the SAE has to respect the accessrestrictions the server imposes onto its data, we have to pro-vide a special SAE plug-in for each type of server.

4. State of Implementation and Future Work

Our current implementation consists of the Web serverwith its SAE, which provides agent and script submis-sion and execution. At this time we are using a simpleuser/agent name and password protection scheme for speci-fying realms which can grant read, write, and execute rightsto human users or agents. One can additionally specifyrights to access the network for agents. Configuration ofthe server and its SAE is done by reading a configurationfile; this will soon be replaced by an online utility. Re-source control is done by offering a fixed amount of eachresource. Our Web Data Interface is able to read HTMLdocuments from the file system or data base. Reading andwriting database-generated HTML documents is not fullyimplemented yet.

After implementing the proposed infrastructure, our fu-ture work will concentrate on Web services. We will inves-tigate how we can support a Web service manufacturer by

tools that ease the implementation and organization of thoseservices. This will also include investigations about suit-able electronic payment systems for such services which weconsider important for any commercial usage. Interfaces toemerging electronic cash systems will be provided throughJava’s electronic commerce API, which we plan to makeuse of.

5. Related Work

There are several research projects that deal with the im-plementation of general purpose agent systems [15] [9] [11][6], some of them are using Java as an implementation lan-guage [7] [10] [14]. All these systems have a different fo-cus: they aim at a platform supporting agents in general,which includes agent communication and agent control. Sofar, this is of minor interest to us, although it represents ageneral concern in our project. Our goal for the WASPproject is to implement Web centric services, for whichwe developed the infrastructure that uses the server mod-ule SAE and a uniform access method to Web data. We arecurrently investigating what type of agents that come fromother Java based agent systems could be integrated in oursystem.

Concerning our Web server implementation, there ex-ist several other Web servers based on Java. The Jeeves[8] project developed a server-side-include interface called‘servelets’ which enables servers to load and execute CGI-like Java programs directly into the Java virtual machine ex-ecuting the server code. Serveletts can be bound to a URLand are loaded by the server, when a user requests the URL.The server can load the servelet from the local file systemor over the network. In both cases it is the server requestingthe servelet. Thus servelets cannot be compared to mobileagents. Our Web server will support the servelet interface.Additionally, servelets can also be sent to the server overthe network.

Compared to Jigsaw [2], our server has a more fine gran-ular access restriction scheme which originates from theneeds for Web services and is enhanced by the Web agentserver module.

In our efforts to offer our server module as a plug-in forother Java-based Web servers, we developed a Jigsaw re-source representing our SAE and investigate whether it ispossible to provide it as servelet. For servers which arenot Java-based, we plan to offer a CGI version of our SAEwhich may require a special interface module to the SAE.

Summarizing, one can say that there is ongoing re-search which uses similar approaches but focuses on dif-ferent aims. As far as we know, WASP is the first projectthat integrated mobile agents into Web servers and proposesservices on Web data implemented by Web agents.

6. Conclusion

In this paper we presented the architecture developed inthe WASP project, which aims at the development of WorldWide Web specific service applications implemented by us-ing mobile agents.

For the WASP project, we realised a Java-based Webserver, a plug-in server execution environment for Webagents, and a uniform access method to Web data. Thesecomponents are the basis for our proposed infrastructurefor Web agents. By using the user’s Web browser as GUI,to which one is familiar to, and the widespread networkof Web servers as a basis, we hope that there will be agood chance for a widespread dissemination of our plat-form, which provides easy but secure access to services andWeb data.

References

[1] Arnold K., Gosling J.,The Java Programming Language, Addison-Wesley, 1996 (ISBN 0-201-63455-4)

[2] Baird-Smith A., Jigsaw Java HTTP Server, by WWW Consortium,http://www.w3.org/pub/WWW/Jigsaw/

[3] Borenstein N., Freed N.,MIME (Multipurpose Internet Mail Exten-sions), Network Working Group, RFC1521, 1993

[4] Borenstein, N.,EMail with a Mind of Its Own: The Safe-Tcl Lan-guage for Enabled Mail, ftp://ftp.fv.com/pub/code/other/safe-tc.tar

[5] Gensereth M.R, Ketchpel S.P.,Software Agents, Comm. of the ACM,Vol.37, No.7, July 1994

[6] Gray R.S.,Agent Tcl: A flexible and secure mobile-agent system,Proc. of the Fourth Annual Tcl/Tk Workshop, Monteray CA, 1996,http://www.cs.dartmouth.edu/agent/papers.html

[7] Hohl F., Konzeption eines einfachen Agentensystems und Implemen-tation eines Prototyps, Diploma Thesis, Univ. Stuttgart, Dept. of CS ,Nr. 1267 (1995)

[8] Jeeves Team,Overview of the Java Http Server Architecture, JeevesDocu, Sun, 1996

[9] Johanson D., van Renesse R., Schneider F.,An Introduction to theTACOMA Distributed System, Univ. of Tromso, Dept. of CS, CSTech. Report 95-23, June 1995

[10] Lange D., Chang D.T.,IBM Aglets Workbench – Programming Mo-bile Agents in Java, White Paper, IBM Corporation, Japan, August1996,

[11] Lingnau A., Drobnik O., D¨omel P.,An HTTP-based Infrastructurefor Mobile Agents, WWW Journal - Fourth Inter. WWW ConferenceProc., Boston, MA, Dec 1995

[12] Magedanz T., Rothermel K., Krause S.,Intelligent Agents: AnEmerging Technology for Next Generation Telecommunications?,IEEE INFOCOM 1996, San Francisco, USA, March 1996

[13] Majewski S.D.,Distributed Programming: Agentware, Component-ware, Distributed Objects, Notes for the discussion on Safe-Python atthe NIST Python Workshop, 1994,

[14] Milojicic D., Condict M., Reynolds, F., Bolinger D., Dale P.,Mo-bile Objects and Agents (MOA) Project, OSF, position paper, ”Dis-tributed Object Computing on the Internet” – Advanced Topics Work-shop, COOTS

[15] Peine H., The Ara Projekt, University of Kaiserslautern,http://www.uni-kl.de/AG-Nehmer/Ara/ara.html

[16] Weiyi L., Messerschmitt D.,Java-To-Go, Itinerative Computing Us-ing Java, Univ. of California at Berkeley, Department of EE and CS,

[17] White J.E.,Telescript Technology: The Foundation for the Elec-tronic Marketplace, Whitepaper by General Magic, Inc, Sunnyvale,CA, USA