An agent based framework for mobile users Aurelio La Corte1 , Antonio Pulia to2, Orazio Tomarchio1 1
Istituto di Informatica e Telecomunicazioni, Universita di Catania Viale A. Doria 6, 95025 Catania - Italy E-mail:flacorte,
[email protected] 2 Dipartimento di Matematica, Universita di Messina Salita Sperone - Contrada Papardo, 98166 Messina - Italy E-mail:
[email protected]
Abstract
developed, so that the user can operate as much transparently as possible with regard to how he/she moves. In particular, a possible framework, based on the mobile agents technology, will be presented. Mobile agents are usually seen as software modules able to move through the network autonomously, in order to carry out the task that they were given by the user [2, 3, 5, 8]. 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. From our point of view, mobile agents can be an effective tool for mobile computing: in fact, the basic features of agents include the support for asynchronous and standalone mode operations. We can therefore build a scenario in which users submit their requests through an agent, which runs their request within the network, and enables the user to obtain the results in another moment, after a disconnection from the network, too. Besides, this enables us to exploit the xed calculation resources within the network, enabling the user to work with mobile devices of limited calculation power and operation autonomy [1, 6]. In this paper we present the support for mobile users that has been designed and implemented for the mobile agents platform MAP 1 (Mobile Agents Platform) [9], which is a platform for the development and the management of mobile agents, implemented at University of Catania. In particular, in Section 2 the architecture and management mechanisms of MAP are we brie y described. In Section 3 general issues which arise when using software agents for mobile users support are discussed. In Section 4 the changes made to MAP for the support of mobile users is presented. Finally, in Section 5 author conclusions and the future working directions for the development of the platform created are presented.
User mobility together with an easy access to distributed resources is one of the greatest challenge to be faced in the future years. At the same time, agent technology is seen as a very promising approach to deal with distributed computing and user mobility. In this paper an agent-based strategy for support of mobile users is presented. It is based on a mobile agent platform developed at the University of Catania, which has been enhanced in order to allow the user to access network services in a mobile environment. Main functionalities and architecure of the above platform are described.
1 Introduction
The quick expansion of wireless communication technologies and of portable computing devices, has made mobile computing more and more important. The user wishes to access the information he/she needs at any moment, independently of the place where he/she is. The ever increasing computing power available in notebooks, makes them a valid working tool for the user who needs to move from a place to another. Today technology has made such devices very similar to desktop-like systems and in some cases, notebooks are a valid alternative to them. Huge computing power is available at low cost which widened the need for integrated devices, with which users can meet their requirements in terms of access to information distributed in the Web, access to company databases, traditional interpersonal communications, etc. Yet, in this area no clear solution has been found. At the same time, wireless communication technologies have made mobile telephones very common for interpersonal communications and mobile computing. Besides, when talking about mobile computing, we can either refer to a user who moves while the computing resources remain in a wired network, or to a user who, after doing a task, roams from a communication environment to another one (for example, from a wired to a wireless network, or from a radio-electric coverage area to another one). Several issues need to be faced in such reference scenario. In this paper we are not going to deal with the issues connected with wireless networks, but we are going to focus our attention on the environment in which the user operates, and on the application support that can be
1
1
MAP is available at http://sun195.iit.unict.it/MAP
2 MAP architecture
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. The Context is one of the basic objects in a MAP server. In fact, it knows all the agents present on the server, saved on an appropriate list, and gives the user all the functionalities needed for their management. The Context puts some methods at disposal, 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. 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. If one of the classes to which the agent refers is not actually present locally, the NetworkClassLoader will search for it in the network: once the class is found, it is loaded from the remote site and saved in a cache memory managed by the Context, so that it can be accessed and used, if necessary, also by of the other agents of the server. 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.
MAP 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. It has been entirely developed in Java, and this guarantees its total portability on the di erent hardware and software architectures. Java is also used as a language for programming agents: the programmer will not therefore need to learn several and/or speci c languages, but only the API that are made available by the platform. The migration implemented in MAP is a weak migration: the agents are able to carry the data-state of data with them, but not the execution-state. Besides, it integrates the paradigms of remote execution and code on demand [4], thanks to the exploitation of the mechanisms of dynamic loading of the classes present in Java. A graphic interface manages the agents in execution. This interface allows to verify which agents are active in the local server, and which ones are present in remote servers. Besides, through this interface we can trigger the execution of any agent present in the system, independently of where the code is resident.
2.1 Reference Architecture The architecture of the MAP is based on the concepts of server and agents. The servers provide the basic environment in which agents run. Agents are active entities that can move from a server to the other, by communicating with the other local agents and accessing the services made available by each server. Agents Server
The platform MAP enables the user to take advantage from a graphic interface (shown in Fig. 2) that permits an easier management of the agents in a MAP server. The graphic interface shows a window where all the agents running locally are listed.
Context
Network ClassLoader
Serialized Object
2.2 Managing the platform
CodeServer
Agent
Instancer
Message
Instancer
Agent
Daemon Agent
Figure 1: MAP server architecture Figure 1 shows the scheme of the elements that form a MAP server, that contains all the entities needed for the operation of the platform itself. In a host there can be more than one Server, each identi ed by the DNS address of the host and by the TCP port number on which the server is listening for accepting agents or messages coming from the network. The Server is the main object of a MAP server, in which the entities Daemon and Context and local agents 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.
Figure 2: MAP User Interface If we select an agent from the list, we can do on it any operations available in the platform, through the buttons present in the upper toolbar (suspend, resume, deactivate, activate, dispose, go). Conversely, by using the button Run, we can make an agent run (resident on a speci c MAP server, not necessarily local) to a di erent MAP server, where the class of the agent can even be absent. Figure 3 helps us to explain this feature better. 2
The user has activated the MAP User Interface on the machine pc10a, and can make an agent run on any node where the MAP server is active. To do this, we only need to indicate the name of the class that implements the agent desired (in this case MyAgent), and the URL of the node where we want to make it run (pc10e). The class that implements the agent does not need to be resident in the node where there is the user (pc10a), or in the one where the agent will run (pc10e): in fact, 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 in gure 3). Thanks to this functionality, the platform presented enables us to use at best paradigms based on remote evaluation and code on demand described before. The button Server enables us to obtain some information about the MAP servers active in the system, and about the agents in execution on such servers. pc10a
pc10d
applications whose results can be returned by email. Actually, in agents applications the result of a transaction is closely linked to the platform used, and its "translation" into an email message might cause a loss of information. In the second approach two cases are possible: in the rst each server maintains a list of all of the other active servers in the system. When a user disconnects from the system (by deactivating the agents server of its node) this is noti ed to all of the other servers. The same thing happens when the user reconnects to the system. When an agent (triggered by a user who disconnects immediately after) ends its task, it remains on the last useful host of its route, waiting for the user to reconnect to the system. When this happens, it migrates again to the node of the user, and brings the results of the search with itself. In the second case a centralized element is present (in the domain) that maintains some information concerning a node designated as proxy (on the xed network) by a user. When an agent ends its task and the user who has triggered it is not connected to the system, the agent migrates to the proxy node of the user and suspends its execution. When the user reconnects to the system, its server sends a message to the proxy, notifying the reconnection to the system. The solution used in MAP refers to this mechanism, and will be described in next section. In fact, we think that maintaining the list of the active servers in the rst mechanism is very hard. In the solution used we envisage appropriate mechanisms of replication of data, in order to increase fault tolerance.
pc10e
MAP User Interface
MyAgent.class
Execution of MyAgent
MAP Server
MAP Server
MAP Server
Figure 3: Running an Agent on Di erent Machines
3 Software agents for Mobile computing
4 Mobile computing in MAP
Mobile agents naturally support asynchronous operations. In the typical scenario of an agents system, a user forwards a request to the system through an agent. This agent, more or less independently, searches for such information, by exchanging data with other agents and various servers, even on di erent networks. In case the user, after triggering this request, leaves the initial workstation and then connects again in another moment either to the same workstation or to a di erent one, the agent needs to know the location where it has to return the results. Two di erent types of mechanisms are possible: the rst one is linked to the use of means outside the platform, such as email [7]. In such solution, the agent, once it has nished its task, sends to the user an email message containing the results or a reference to them (in case they require too much storage space: e.g. multimedia data). This solution gives some immediate bene ts: 1) the user can disconnect and obtain the desired results with no need for reconnecting to the agents platform; 2) various devices (even non-traditional ones, such as the PDA) support email; 3) the software for the management of email is very widespread and very cheap. But this mechanism has also the big disadvantage of forcing the user to use an outside mechanism for accessing some information that he/she requested through an agent. The di erent types of software for the management of email might cause some issues concerning the uniformity of presentation of data. Besides, this approach would only be limited to those
The general architecture for the support of mobile users is shown in gure 4. There are one or more lookup servers, and some data servers. The lookup server maintains the information about where an agent temporarily stores its results, waiting for the user to reconnect to the system. Conversely, data servers are simple nodes on which agents store their results if, when they contact the user again, detect that he/she is no longer connected to the system. Host A
Data server
1 2 3
11 00
Lookup Server
11 00
5
Data server
User Agent
Mobile Manager Agent Data Manager Agent
4
1. NOHOME 2. DATASERVER URL
6 Host B
7
00 11 11 00
3. RESULT 4. HERE 5. RETRIEVE URL
user moves from host A to host B
6. DATA 7. RESULT
Figure 4: Supporting mobile users in MAP In gure 4 we also show the steps that are done by the system, in order to satisfy a mobile user's requests. Such steps are described below: 1. a user agent X triggered by a user cannot reach the node A from which it has been activated, either be3
5 Conclusions
cause the user has disconnected or because an interruption in the connection has occurred. Then it sends a message NOHOME to the mobile manager agent present in the lookup server
In this work we have presented a preliminary strategy, based on mobile agents, for the support of mobile users. We have considered MAP as a reference platform, and we have described the appropriate functionalities created for enabling an adequate support of the operations of a generic user who connects to the system from di erent workstations in di erent moments. In the work that is being done on MAP, we are going to equip it with adequate security mechanisms, so to be sure to authenticate the users of the services made available by the platform.
2. the mobile manager agent, when receiving this message, selects a data server (from the list of the ones maintained by the data server in which it runs), and sends the information (DATASERVER URL) to the agent X that has done the request; then it updates a table inside the lookup server, by storing the user's ID, the ID of the agent and the URL of the data server communicated
Acknowledgments: the work has been carried out un-
3. the agent X sends a message RESULT to the agent data manager present in the data server. The agent X speci es its identi er, the one of the user, and the data to be stored. Then the agent ends its execution. The data manager agent will store the data received on the data server
der the nancial support of the Italian Ministero dell'Universita e della Ricerca Scienti ca e Tecnologica (MURST) in the framework of the MOSAICO (Design Methodologies and Tools of High Performance Systems for Distributed Applications) Project.
References
4. when the user reconnects from a new station (host B), the server MAP sends a message HERE to the mobile manager agent, in order to indicate the user's reconnection and the new URL from which he/she has connected.
[1] D. Chess, B. Grosof, C. Harrison, D. Levine, C. Parris, and G. Tsudik. Itinerant agents for mobile computing. IEEE Personal Communications, 2(5):34{49, October 1995. [2] D.M. Chess, C.G. Harrison, and A. Kershenbaum. Mobile Agents: Are they a Good Idea? Technical Report RC19887, IBM T.J. Watson Research Center, March 1995. [3] O. Etzioni and D.S. Weld. Intelligent agents on the Internet: Fact, Fiction, and Forecast. IEEE Expert, 10(4):44{49, August 1995. [4] A. Fuggetta, G.P. Picco, and G. Vigna. Understanding Code Mobility. IEEE Transaction on Software Engineering, 24, 1998. [5] M. Genesereth and S. Ketchpel. Software Agents. Communications of the ACM, 37(7):48{53, July 1994. [6] R. Gray, D. Kotz, S. Nog, D. Rus, and G. Cybenko. Mobile agents: the next generation in distributed computing. In Proc. of the Second Aizu Int. Symp. on Parallel Algorithms/Architecture Synthesis (pAs97), Fukushima, Japan, March 1997. [7] A. Lingnau and O. Drobnik. Agent-User Communications: Request, Results, Interaction. In Proceedings of the Second Int. Workshop on Mobile Agents (MA98), Stuttgart, Germany, October 1998. [8] V. A. Phan and A. Karmouch. Mobile Software Agents: An Overview. IEEE Computer, 31(7):26{37, July 1998. [9] A. Pulia to, O. Tomarchio, and L. Vita. MAP: Design and Implementation of a Mobile Agent Platform. Journal of System Architecture. to be published.
5. the mobile manager agent consults the inside table of the lookup server, and gives back the user all of the information needed for retrieving its results 6. the server MAP on which the user is, therefore sends a request DATA to the data manager agents, and requires the data of the requests triggered before disconnecting. 7. data managers respond by sending the results of the execution of the agent X, originally triggered by the user. The mechanism has been described for the case in which the request triggered by the user envisages a collecting of information by the agent. Once the information has been collected, there is no need for maintaining the agent alive. For this reason, the agent in the described algorithm ends its execution and at the end the user is returned only the data he/she is interested in. In some cases, we might need to maintain the agent originally triggered by the user alive. In this case, the agent in step 3 will not end its execution, but will suspend its execution in the data server. When the user reconnects to the system, it will be resumed and will migrate to the new node of the user, where it will bring the results of its previous execution, and will be able to interact with the new environment. In the description of the algorithm used, we have referred to several data servers in which the results of the agents can be stored. This is done in order to increase the reliability of the whole system, but also for balancing the load on di erent servers. 4
