1
W-MAP: A Web-accessible Mobile Agents Platform
Marco Avvenuti (1), Antonio Pulia to (2), Orazio Tomarchio (2)
(1) Dipartimento di Ingegneria dell'Informazione Universita di Pisa Via Diotisalvi 2, 56126 Pisa - Italy
[email protected] Abstract |
We present W-MAP, a Web-accessible platform for the development and the management of mobile agents. The language used both for developing the platform and for carrying out the agents is Java. The platform gives the user all the basic tools needed for creating some applications based on the use of agents. It allows to create, run, suspend, resume, deactivate, reactivate agents, to stop their execution, to make them communicate each other and migrate. Keywords: mobile agents, Java, WWW, code mobility. I Introduction
Mobile agents are software modules able to move through the network autonomously, in order to carry out the task that they were given by the user [1], [2], [3]. As the word itself suggests, an agent is an entity acting on behalf of someone else. It helps a user to run a speci c task, either by communicating with the user who launched it, or with other agents, or with the environment in which it is. The main aspects that contributed the success of agents are their ability to operate autonomously and intelligently, and their ability to migrate. In fact, agents are applications able to carry out the task for which they were created autonomously, moving (if necessary) from a node of the network to the other, in order to obtain the information they need. We can therefore speak of mobile agents that, if necessary, carry the state (in which they were at the time of the suspension) with them, that is the set of the values taken by some variables inside the agent itself. The use of Java [4] favoured the design and the creation of several platforms for agents. Some of the mobile agent systems developed in Java are Aglets [5] by IBM, Odyssey [6] by General Magic, Voyager [7] by ObjectSpace, and other systems produced by university research such as Mole [8], and JavaToGo [9]. We can refer to the work [10], for a comprehensive review of such platforms. The main features common to such systems include some agent servers that, in each node, create the environment of execution for agents. Such servers supply the basic services to agents. Agents of such systems can move from a node to the other by using several mechanisms, and carrying a part of their state with them. In this work we present W-MAP, a Web-accessible platform for the development and the management of mobile agents, which was completely developed by using Java. W-MAP is derived from the platform MAP, originally developed at the University of Catania [11], and enhances its features through the possibility to easily access all the services by means of a Web browser. W-MAP enables to create, run, suspend, re-
(2) Istituto di Informatica e Telecomunicazioni Universita di Catania Viale A. Doria 6, 95025 Catania - Italy fap,
[email protected]
sume, deactivate, reactivate agents, to stop their execution, to make them communicate with each other and migrate. The user is then given all the basic tools for the development and use of agent-based applications. The HTTP protocol has been integrated in other agent systems, either as a support for agent interaction like in ffmain and Tabriz [12], or as a mechanism for launching and retrieving agents like in the Fiji extension for Aglets [13]. Similar to the one of Fiji, our approach provides the Web user with remote access to the complete set of operations available in the platform, in a transparent way. Yet, W-MAP does not rely on a substitute agent server running in the client side, but uses a combination of HTML forms, Java applets and servlets to move only the GUI components to the browser, while agent programs still execute on remote agent servers. Consequently, we need no extensions to Web browsers and only a few classes to be installed on HTTP servers. The rest of the paper is organized as follows: In Section 2 we describe the basic architecture and some key concepts of the design of MAP. In Section 3, we present the Web interface to the platform and describe its management mechanisms. Finally, in Section 4 we present the conclusions, together with the future working directions for the development of the platform created. II MAP: Mobile Agents Platform
MAP 1 is a platform for the development and the management of mobile agents that gives all the primitives needed for their creation, execution, communication, migration, etc. We decided to use Java for developing the whole architecture due to the following features: it is object-oriented (and so a modular development of the code is favoured, and the user can write one's agents with limited e orts, starting from the classes provided by the platform); it is portable on an increasing number of hw/sw architectures; the presence of mechanisms for the dynamic loading of classes from di erent sources and for their dynamic linking at run-time in the current application; possibility of serializing the objects thus enabling their transfer through the network; MAP implements a weak migration by relying on the mechanisms of Object Serialization present in version 1.1 of Java. Object Serialization is a mechanism that enables 1 MAP is available at the following http://sun195.iit.unict.it/MAP/map.html
Web
site:
2
us to represent an object as a stream of bytes. When an agent has to migrate, it is serialized and the stream of bytes obtained is sent to the destination node through the network. Here the stream is deserialized, and the execution of the agent is restarted with the stored state. While serializing an object, the code of the class to which the object belongs is not stored, but only a reference to it is stored. Thus, since in our system the classes needed are not always in the arrival node, we had to take advantage from another feature of Java: the possibility to load some classes dynamically in runtime from di erent sources. This was done by using a NetworkClassLoader, whose task is to load the classes that are necessary for the execution of an agent. Such mechanism permits therefore to exploit the network at best. The transfer of the bytecode of a class will occur only when required (in case of migration of several instances of the same agent, we do not need to transfer the same class); in any case, we can always do the transfer from the "closest" node, and not necessarily from the departure node of the agent. Thanks to such mechanisms for the dynamic loading of classes present in Java, the paradigms of code on demand and remote execution have been integrated within of our platform. Such mechanisms are available for each agent, that can therefore change its behavior according to the classes that it can load on each node. The designer can therefore integrate the di erent paradigms of mobility that are more suitable to the speci c application, even if only one working environment is used. The ability of an agent to communicate with other agents is another basic characteristics that must be given by such a system. Several communication mechanisms are possible. In the MAP the communication among the agents takes place through the exchange of messages that may be synchronous or asynchronous. In our opinion, this solution (unlike some mechanisms based on RPC) is very
exible and enables us to implement several schemes of communication and synchronization among agents. Anyway, the platform gives the basic mechanisms for the communication: any advanced schemes of communication and co-operation (see for example KQML/KIF [14]) can be implemented beyond the primitives supplied. II.A Reference Architecture The MAP basically consists of agents that can move to the various nodes of a network, and of agent servers that constitute the environment in which the agents will run. The architecture of the MAP is shown in Fig. 1, in which the constituent parts of the platform, which will be described later, are pointed out. A node belonging to the platform MAP consists of an object called Server that contains, all the entities needed for the operation of the platform itself. In a node there can be more than one Server, each identi ed by the DNS address of the node and by the TCP port number on which the Server is listening for accepting agents or messages coming from the network. Server The Server is the main object of a MAP server, in which the entities Daemon and Context and local agents
Server
Context Network ClassLoader
CodeServer
Instancer Agent
Agent
Daemon Instancer Message
Agent
Fig. 1. MAP architecture
are instanced. The presence of a Server on a node characterizes it as belonging to the platform MAP. Its activation enables the node to accept and have agents coming from the network run, as well as to activate other agents locally. Daemon The Daemon is the entity of the MAP that listens on a certain port, waiting for agents coming from other nodes and for messages to be delivered to local agents. Both messages and agents travel in a serialized form. Each time a stream arrives from the network, the Daemon creates a speci c entity called Instancer, whose task is to instance the serialized object, both if it is an agent and a message. In both cases, the object, once it is instanced, is passed to the Context, whose task will be to make it run (if it is an agent), or to send it to the receiver agent (if it is a message). Context The Context is one of the basic objects in a MAP server. In fact, it knows all the agents present on the node, saved on an appropriate list, and gives the user all the functionalities needed for their management. The Context, provides methods which enable to create an agent, to make it run, even on a Server in which its code is not present, to suspend it, to deactivate it, to resume its execution, and even to kill it, if necessary. Besides, the Context gives an agent that is running on a speci c Server the possibility to obtain some information about the agents that are running on the same Server or on a remote Server. CodeServer The CodeServer is an internal entity of the Context, dynamically created; in fact, the Context of a platform instances a new object CodeServer each time it is requested a class by a NetworkClassLoader, either local or remote. The CodeServer is given a table of the Context in which all the classes available in the platform are saved. NetworkClassLoader The NetworkClassLoader of the platform MAP is used for enabling the agents to run on a speci c MAP server, even when their class is not present there, and to exchange (through messages) also objects of classes not de ned locally. The Daemon, in order to use such classes transparently, once a stream of data comes from the network, creates a new Instancer object by loading it with the NetworkClassLoader. From now on, each object to which the Instancer will refer will be automatically instanced with the same NetworkClassLoader. Thus, if one of the classes to which the agent or the message refers is not actually present locally, the NetworkClassLoader will search for it in the network, in a list of MAP servers xed within the Context. Once the class is found, it is loaded
3
from the remote site and saved in a cache memory man- extend the MAP server interface with such services. Inaged by the Context, so that it can be accessed and used, stead, we chose to delegate the invocation of the correif necessary, also by of the other agents of the Server. sponding methods to an static agent, say WebAndMAP, to which messages carrying method invocations are delivered. III The Web Interface On receiving such messages the agent, which lives in those In order to provide the user with an easier management MAP servers exporting Web access, rst identi es the user of agents and with remote access to the complete set of and then, if he has permissions, performs on his behalf the MAP operations, we enhanced the platform with a Web- method invocations required. accessible graphical interface. The resulting W-MAP allows the user to seamlessly get such an interface either III.A Managing the platform from the local agent server, or from a remote one using the HTTP. In the latter case, the underlying mechanism moves the GUI components to the universal interface engine of a Web browser and supports their interaction with objects running on some remote MAP server. This feature is particularly addressed to mobile users, and provides an e ective support to applications operating in disconnected mode. Web Browser Applet
HTTP Server Servlet
Daemon HTTP TCP/IP
WebAndMAP
MAP Server
Thread communication
Fig. 2. W-MAP architecture
As our goals include simplicity, we designed W-MAP requiring no extensions to the Web browser and only a few classes to be installed on the HTTP server to make it able to communicate with MAP servers. Under this setting, the main problems to be solved are those arising from the stateless nature of the HTTP protocol and the lack of communication between the browser and the MAP server. The solution we adopted uses a combination of HTML forms, Java Applets and Servlets (Figure 2). Applets are used to download and visualize the interactive GUIs on a Java-supported browser. From the implementation point of view, we have to deal with the fact that, in order to satisfy user requests, the Applet has to communicate with di erent remote MAP servers. As the applet security policy allows applets to communicate only with their codebase, we added to an already installed HTTP server a special Servlet. Such a Servlet acts as a lightweight proxy, forwarding the message trac between the Applet and the MAP server. Messages are exchanged in the form of serialized objects. Those messages referring to services included in the agent server's API, or requesting new classes to be downloaded, are delivered by the Daemon to the Context directly. Conversely, messages requesting operations on agents (e.g.: run, suspend, resume, terminate, migrate etc.) refer to actions to be performed from within the MAP server onto resident objects. Because of security reasons, we did not
Fig. 3. The MAP User Interface on the browser
As described above, in a typical W-MAP session the user is presented with some graphic interfaces, through which he can interact with agents by invoking operations available on a remote MAP server. The connection to the MAP server running on a given node, say pania, takes place by selecting the special URL: http://info:8000/Agent/W-MAP?ServerName=pania
that causes the MAP User Interface be displayed on the browser, as shown in Figure 3. The graphic interface shows the hostname of the MAP server we are connected to (the Server Name form), and a window where all the agents running on that server are listed, together with some information for each of them. If we select an agent from the list, we can do on it any operation available in the platform by means of the self-explained buttons present in the upper toolbar (Suspend, Resume, Deactivate, Activate, Dispose, Go). Using the button Run, we can make an agent resident on a speci c MAP server run to a di erent MAP server, where the class of the agent can even be absent. Figure 4 helps us to better explain this feature. The user activates the MAP User Interface on node pc10a and then invokes the Run operation, through which he can make an agent run on any node where the MAP server is active. To do this, he only needs to indicate the name of the class that implements the agent desired (in this case MyAgent), and the URL of the node where he wants to make it run (pc10e).
4
The class that implements the agent does not need to be resident on node pc10a, or in the node where the agent will run (pc10e): it only needs to be in a node where the MAP server is active and that the user will have to indicate as source URL (pc10d). Thanks to this functionality, the platform presented enables us to use at best paradigms based on remote evaluation and code on demand.
IV Future works and Conclusions
We presented the design and the implementation of WMAP, a platform for the development and execution of mobile agents. We discussed the main design issues concerning the mobility, the communication between agents and the capability to access the platform through the Web. The integration of the HTTP protocol enhances the exibility of W-MAP and is particularly addressed to mobile users. In fact, it makes the platform ubiquitously available, even through resource constrained portable computers operating in disconnected mode. We are currently working to equip the W-MAP with adequate mechanisms of security and of access control. In particular, a SecurityManager will be placed between the Context and the agents requiring the Fig. 4. Running an Agent on di erent hosts services to check the single actions of each agent. Each agent will have an owner and, according to this, will be Besides managing the platform, the user may also want associated with a list of authorizations about the resources to interact with application agents through their speci c that can be used. GUIs. For instance, in order to retrieve results from an Acknowledgment agent we simply select this agent from the list of suspended/deactivated agents (e.g., finggui) and then reThis work has been partially funded by the Ministero sume/activate it by means of the corresponding button. dell' Universita e della Ricerca Scienti ca e TecnologAs a result, the class implementing the agent GUI, if any, ica (MURST) in the framework of the Project "Design will be encapsulated in an applet and sent to the browser. Methodologies and Tools of High Performance Systems for The button Server enables us to obtain some global in- Distributed Applications" formation about W-MAP. The window that appears shows References in a column the list of MAP servers that are currently ac[1] D.M. Chess, C.G. Harrison, and A. Kershenbaum, \Mobile tive. By selecting a server, a second column will show the Agents: Are they a Good Idea?", Tech. Rep. RC19887, IBM agents in the selected server and their state. On a third colT.J. Watson Research Center, Mar. 1995. umn the classes available on the selected server are shown. [2] M. Genesereth and S. Ketchpel, \Software Agents", Communications of the ACM, vol. 37, no. 7, pp. 48{53, July 1994. The user can add a new server to the list at any moment. [3] O. Etzioni and D.S. Weld, \Intelligent agents on the Internet: Finally, the Refresh button can be used for updating the Fact, Fiction, and Forecast", IEEE Expert, vol. 10, no. 4, pp. 44{49, Aug. 1995. information displayed in the MAP User Interface. This is [4] K. Srinivas, V. Jagannathan, Y.V.R. Reddy, and R. Karinthi, necessary when we operate through a Web browser, due to \Java and Beyond: Executable Content", IEEE Computer, vol. the stateless nature of the HTTP protocol. 30, no. 6, pp. 49{52, June 1997. pc10e
pc10a
pc10d
MAP User Interface
MyAgent.class
Execution of MyAgent
MAP Server
MAP Server
MAP Server
III.B HTTP-related implementation details To better explain the roles of modules shown in Figure 2, let us refer to the W-MAP session described in the previous Section. When the user select the URL: http://info:8000/Agent/W-MAP?ServerName=pania
the browser submits the request to the HTTP server info, using port 8000. The W-MAP part of the URL activates Servlet, which in turn takes the contents of variable ServerName as the name of the MAP server to contact, creates a socket for communicating with Applet, and writes to the output a HTML page. The page, which is sent by the HTTP server to the browser, includes the applet that implements the MAP User Interface. Messages sent in response to the Server and the Refresh commands request the list of agent classes and the agent state. As they refer to services included in the MAP server's API, they are delivered to the Context directly. Conversely, messages sent in response to the Suspend, Resume, Deactivate, Activate, Dispose, Go and Run commands refer to actions to be performed from within the MAP server onto resident objects and are delivered to the static agent WebAndMAP.
[5] D.B. Lange and M. Oshima, \Programming Mobile Agents in Java with the Java Aglet API", Tech. Rep., IBM Tokyo Research Division, 1997. [6] General Magic, \Agent Technology: General Magic's Odyssey", http://www.genmagic.com/, 1997. [7] ObjectSpace, \Voyager Core Technology: Technical Overview", http://www.objectspace.com/voyager, 1997. [8] M. Strasser, J. Baumann, and F. Hohl, \MOLE - A Java Based Mobile Agent System", in Proceedings of the 2nd ECOOP Workshop on Mobile Object Systems, July 1996. [9] W.W. Li and D.G. Messerschmitt, \Java-To-Go: Itinerative Computing using Java", http://ptolemy.eecs.berkeley.edu/dgm/javatools/java-togo, Sept. 1996. [10] J. Kiniry and D. Simmermann, \A hands-on look at Java Mobile Agents", IEEE Internet Computing, vol. 1, no. 4, pp. 49{52, July 1997. [11] A. Pulia to, O. Tomarchio, and L. Vita., \MAP: Design and Implementation of a Mobile Agents Platform", Tech. Rep., University of Catania, 1998. [12] P. Domel, A. Lingnau, and O. Drobnik, \Mobile Agent Interaction in Heterogeneous Environments", LNCS, vol. 1219, pp. 136{148, Apr. 1997. [13] IBM Corporation, \Fiji - running aglets in web pages", http://www.trl.ibm.co.jp/aglets/infrastructure/ ji/ ji.html, 1998. [14] T. Finin, D. McKay, R. Fritzon, and R. McEntire, \The KQML Information and Knowledge Exchange Protocol", in Third Int. Conf. on Information and Knowledge Management (CIKM'94), Nov. 1994.
