<%BANNER%>

Azimas: Web Mobile Agent System


PAGE 1

AZIMAS: WEB MOBILE AGENT SYSTEM By SUBRAMANIAN ARUMUGAM A THESIS PRESENTED TO THE GRADUATE SCHOOL OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT OF THE REQUIREMENTS FOR THE DEGREE OF MASTER OF SCIENCE UNIVERSITY OF FLORIDA 2003

PAGE 2

Copyright 2003 by Subramanian Arumugam

PAGE 3

TO MY MOM AND DAD

PAGE 4

ACKNOWLEDGMENTS I would like to express my sincere gratitude to my advisor, Dr. Abdelsalam Helal, for being a source of continuous support and encouragement throughout my graduate studies. My thanks also go to the members of my thesis committee, Dr. Michael P. Frank and Dr. Beverly A. Sanders, for reading previous drafts of this thesis and providing suggestions that helped improve its contents and presentation. I would also like to acknowledge the CISE department for its support that enabled me to present this work at the IEEE International Conference on Mobile Agents in Barcelona, Spain. iv

PAGE 5

TABLE OF CONTENTS page ACKNOWLEDGMENTS.....................................................................................................iv LIST OF FIGURES.............................................................................................................vii ABSTRACT.....................................................................................................................viii CHAPTER 1 INTRODUCTION.............................................................................................................1 1.1 Agents Explained.........................................................................................................1 1.2 Motivation...................................................................................................................3 2 RELATED WORK............................................................................................................5 2.1 Integrating Mobile Agents With Web Servers................................................................5 2.2 Previous Work On AZIMAS.........................................................................................7 3 AZIMAS SYSTEM ARCHITECTURE...............................................................................9 3.1 Client Side Components................................................................................................9 3.2 Server Side Components.............................................................................................10 4 AGENTS IN AZIMAS.....................................................................................................12 4.1 Naming......................................................................................................................13 4.2 Agent Communication................................................................................................15 4.3 Event Management.....................................................................................................15 4.4 Mobility and Agent Persistence...................................................................................16 4.5 Security.....................................................................................................................17 5 USAGE...........................................................................................................................19 5.1 User Interaction with AE............................................................................................19 5.2 Writing Agent Programs.............................................................................................20 5.3 Request Processing in the AE......................................................................................22 5.4 Application Scenarios.................................................................................................23 5.4.1 Spider Mobile Web Crawler Agent..................................................................23 5.4.2 YoYo Information Synthesizer........................................................................25 v

PAGE 6

6 IMPLEMENTATION AND PERFORMANCE..................................................................27 6.1 Implementation.........................................................................................................27 6.2 Performance Evaluation..............................................................................................28 7 CONCLUSION..............................................................................................................31 APPENDIX A AZIMAS AGENT ENVIRONMENT MODULES.............................................................32 B SERVLET-BASED APPROACH......................................................................................35 LIST OF REFERENCES......................................................................................................37 BIOGRAPHICAL SKETCH................................................................................................38 vi

PAGE 7

LIST OF FIGURES Figure page 2-1 Architecture of earlier aZIMAS system................................................................................8 3-1 The aZIMAS high-level design.............................................................................................9 3-2 The aZIMAS Agent Environment (AE)...........................................................................10 4-1 Agent Naming Hierarchy....................................................................................................14 5-1 Agent Environment (AE) Web Interface..........................................................................19 5-2 Spider Mobile Web Crawler Algorithm..............................................................................24 5-3 Spider Mobile Web Crawler Agent Interface......................................................................25 6-1 Impact on web servers response time.................................................................................29 6-2 Impact on available system memory...................................................................................30 vii

PAGE 8

Abstract of Thesis Presented to the Graduate School of the University of Florida in Partial Fulfillment of the Requirements for the Degree of Master of Science AZIMAS: WEB MOBILE AGENT SYSTEM By Subramanian Arumugam May 2003 Chair: Abdelsalam A. Helal Major Department: Computer and Information Science and Engineering Mobile agents technology opens up new avenues in personalizing and customizing the web experience of users. It provides new possibilities for deploying distributed applications using existing web infrastructure. One reason why mobile agents are not yet popular on the Web is the lack of an easily deployable framework that would facilitate their existence. Existing mobile agent systems usually require heavy infrastructure that lacks interoperability if deployed on the Internet. In this paper, we describe aZIMAS (almost Zero Infrastructure Mobile Agent System)--a framework that will enable the execution of lightweight mobile agents on the Internet. aZIMAS uses existing platform independent protocols like HTTP to achieve code mobility and agent interaction. Our approach involves adding a minimal infrastructure layer, called Agent Environment (AE), over existing web servers and using web browsers as clients. By basing our framework firmly on existing web servers and browsers, we hope to leverage the pervasiveness of web browsers and servers and achieve similar pervasiveness for mobile agents. viii

PAGE 9

CHAPTER 1 INTRODUCTION Mobile agents have generated a lot of interest in recent years and are becoming increasingly important because of the flexibility they provide and their ability to utilize distributed resources. In this chapter, we provide the reader with a brief introduction on agent technologies, its applications and limitations. We then describe the motivation behind this work and summarize our contributions. 1.1 Agents Explained An agent can be defined as a software abstraction that acts on behalf of an entity and has the ability to make autonomous (independent) decisions on behalf of the entity. The entity can be a user, program or an organization. Mobile agents are agents that have the ability to migrate across nodes in a network. Agents normally reside within the context of an agent system. An agent system is a software entity that provides the execution environment for agents and supports their lifecycle (agent creation, execution, termination, migration). One other perception of agents is to view them as an advanced structuring technique in programming. As computing has evolved, structuring techniques for programs also have grown in sophistication: subroutines/ functions, abstract data types, objects and now finally agents. The agent paradigm has potential use in three application domains: 1. Information processing. Data-intensive applications where the data is remotely located can be structured using agents. The application launches an agent that moves near the data source, performs computation on the data locally, and finally returns back to the application with the collected results. Compared with traditional client-server model, this approach is efficient since it conserves bandwidth and limits network resource consumption. 2. Disconnected computing. Applications residing on mobile nodes like laptops, PDAs, and smart phones have limited resources and often have to deal with a weak network connection. These applications can be designed as an agent and shipped to an agent system, which normally has better resources. 1

PAGE 10

2 3. Extending server functionality. It would be impractical to expect a server to satisfy all possible needs (special-purpose computations) of its users. Employing the agent paradigm, an interested user can ship the desired computation to the server and extend the functionality of the server dynamically. Some of the challenges the agent community faces are: the security concerns that mobile agents pose to the host machines, lack of standards among agent systems that hinder interoperability, lack of an easily deployable framework for agent systems, and lack of a killer application that would force widespread adoption of agent paradigm. Given the amount of interest in agent system research, many of these challenges seem to be resolvable in the near future. For example, efforts are underway to standardize agent systems. Acceptable solutions to many security concerns have been developed (Gritzalis and Spinellis 1997). The deployment problem is especially important in our opinion. Many current agent systems use non-standard protocols and require special infrastructure. This prevents widespread uniform deployment of the agent system. In this paper we describe an agent system solution that can be easily deployed in a uniform manner on a wide variety of systems. In our solution the agent system is based web servers and uses existing protocols like HTTP to achieve code mobility and interaction. By basing the agent framework firmly on web servers, we hope to leverage the pervasiveness of web servers to achieve pervasiveness of mobile agents. It is our strong belief that the popular agent model will be based on the Internet. This makes web servers a natural choice as a deployment framework. The Internet is the fastest growing repository of information and its data enormity and complexity make it an ideal domain for agent systems to solve a variety of interesting problems. Some applications for Internet based agents are: complex queries that require synthesizing information from a number of sources, mining large data repositories at the data source, and managing user information on the web providing seamless synchronization with various user devices (personal computer, laptop, PDA).

PAGE 11

3 1.2 Motivation The motivation for this work arises from the fact that agent technology and the Internet together opens up new avenues in personalizing and customizing the web experience of users. It provides new possibilities for deploying distributed applications using existing web infrastructure. There are two important factors that we believe will make mobile agents a critical part of the Internet in the near future. First, due to the explosive growth of content on the web, the average user is subjected to overwhelming amount of information. It has become increasingly necessary for the underlying software to take an active role in presenting useful information. This involves information processing tasks like data filtering based on user preferences, automating common tasks etc. Many commercial software attempts to alleviate this problem (Stroud 2002). With the advent of web services, more resources are available in a structured and easily accessible form than ever before. The second phenomenon is the increasing number of mobile users. Unlike connected computers, mobile users often have to deal with a weak network connection, limited resources (power, memory, screen area). Hence, it is attractive to consider options that would move resource and bandwidth consuming processes to remote locations. Some of the problems arising out of both these trends can be attributed to the passive role played by existing software tools, which merely display retrieved information. Whereas through the use of mobile agents one can develop tools that actively participate in a users web interaction process. Mobile users can benefit immensely in areas like remote processing and data rendering, whereas the average web user can tap on agents to cope with the information overload. With the Internet having been identified as the most desirable platform for distributed applications, agents can also help realize richer and dynamic forms of collaboration and cooperation. Given these advantages, the goal of our work is provide a framework for agents to operate on the Internet and access common web services. The framework should integrate seamlessly with existing infrastructure tools realizing agents as a natural part of the World Wide Web.

PAGE 12

4 Our previous work (Nalla et al. 2002) investigated the merits of an agent system that is based upon existing web infrastructure software like web servers. The work resulted in the project aZIMAS (almost Zero Infrastructure Mobile Agent System), a mobile agent system based on the apache web server. The system had a very simple architecture and provided no support for features like agent communication and collaboration. Since the system was custom designed for Apache, deploying it in other web servers required extensive modification. We realized the need to extend the aZIMAS framework. This resulted in our current improvised version, which consists of a simple framework called Agent Environment (AE) that can plug-in to a web server through means a server extension module specific to a web server. The contributions of this paper can be summarized as follows: 1. We demonstrate a new agent system that is based on existing web technologies and which requires no additional client-side components 2. We present a new technique for integrating agent systems with web servers that is based on a lightweight web server-specific module. This approach enables the deployment of the agent system in any web server with no modification 3. We investigate the performance implications of deploying an agent system along with a web server The rest of this paper is organized as follows: In Chapter 2, we give an overview of research that deals with web integration of agent systems. In Chapter 3, we present the architecture of the aZIMAS System with a detailed description of its Agent Environment (AE). Chapter 4 provides an overview about aZIMAS agents and describes how issues like agent communication, mobility, and security are handled. We then describe usage examples and application scenarios in Chapter 5. In Chapter 6, we discuss our implementation and present some preliminary performance results. Chapter 7 concludes the paper with a note on our current work.

PAGE 13

CHAPTER 2 RELATED WORK In this chapter, we first present a survey of research that deals with the issue of integrating mobile agents with web servers and describe how our approach is different. We then give an overview of our earlier work and detail the specific contributions of this work. 2.1 Integrating Mobile Agents With Web Servers There are a number of research projects that deal specifically with the issue of integrating mobile agents into web servers. The approach taken by these projects fall in one of the following two categories: Custom Web Server based. Develop a custom web server integrating an agent execution component. The agent component handles agent related requests. Projects like WASP (Funfrocken 1997) (Web Agent-based Service Providing), and Agent Server (Lingnau et al. 1995) take this approach Script based. Make use of server-side facilities like common gateway interface scripts to launch applications that handle agent requests. M&M framework (Marques et al. 2001) and WebVector (Goddard and Sunderam 1997) fall under this category In the custom web server approach, agent system architecture is usually bound tightly to a specific web server. The web server normally consists of an embedded agent server environment which enables it to host mobile agents. Agent specific requests are exchanged via HTTP POST messages with unique MIME-types. The web server recognizes messages with specific MIME types as agent related and passes it on to the agent server for further handling. The problem with this approach is that existing web sites may not want to replace their current web infrastructure in favor of a custom-made web server. Custom-made web servers may not match the power, reliability, and efficiency of production-quality commercial web servers. Thus, it is likely that any agent enhancement solution that gains acceptance among web content providers is based on existing web infrastructure software. Another issue with this approach is that the tight coupling 5

PAGE 14

6 between the web server and the agent architecture makes it difficult to deploy the solution in a wide variety of web servers uniformly. In projects that make use of server-side scripts, a script normally handles the task of receiving agents, and supporting their operation. In M&M agent system, web deployment is achieved by making use of servlet technology. WebVector uses common gateway interface scripts to receive and transport agents. If the custom server based approach makes the level of coupling tight, the CGI/Servlet approach tends to decouple the web server and the agent system completely. This has some important performance consequences: 1. The web server will incur a significant overhead if the agent system is bulky 2. Since the web server has no awareness of the agent system, neither the agent system nor the web server can take advantage of internal optimizations 3. To access local resources, the agent system will have to act like any other normal HTTP client From a design perspective, a servlet-based approach would provide a uniform way to deploy the AE on web servers that support servlets (see Appendix B for a discussion on how the server modules can be implemented as servlets). aZIMAS seeks to strike a compromise between the two approaches discussed above. Our solution consists of an agent environment with a well-defined interface, so that it can easily plug-in into existing web servers. In our approach, the agent environment remains the same for all web servers. The agent environment is integrated into a web server through use of a simple server module developed specifically for the server. Though this approach makes the server module specific to each web server, we believe this is not a constraint to the deployment of the aZIMAS AE. This is because the only task performed by the server module is to forward an agent-specific HTTP request to the AE, get the reply back from the AE and communicate it to the client. Hence, developing a server module for any given web server should be a relatively easy task. We have developed an extension module for the popular apache web server to route requests to the agent environment. We are currently investigating if a similar architecture can be achieved

PAGE 15

7 on an IIS Server through the use of ISAPI extensions. For IIS server, an ISAPI extension that could interface with the AE would be needed. Developing a server module for other web servers should be a relatively easy task as almost all commercial web servers provide a library of routines to help developers in creating extension modules. Using a server module to integrate an AE offers number of other advantages. The web server usually loads server modules during start up, so server modules incur little or no overhead in processing a request. In addition, all important server data structures are usually available for the server modules; hence clever optimizations can be done to improve request processing. Finally, by moving web server specific tasks to the server module, we can keep the agent environment the same for any web server. 2.2 Previous Work On AZIMAS An earlier version of aZIMAS is shown in Figure 2-1. The goal of our earlier work was to evaluate the feasibility of mobile agent integration with existing web servers. To this end a demonstrative prototype agent system was custom-built for Apache web server. The system consisted of a runtime layer that provided basic agent services. The users of the system created agents by using an Agent Manager application present in the client side. The agents were encapsulated in a HTTP request and sent to the Apache web server. Agents used the runtime services provided by the Apache web server to move from its current location to the next server in its itinerary. While moving between hosts the agent carried its entire code and data. Though the system well served its purpose as a demonstrative prototype, it had significant limitations: the system lacked a well-defined architecture with clearly defined interfaces and since the system was custom-built for Apache, it was not possible to deploy it uniformly in a wide variety of Web Servers. Most importantly, many standard features that one would expect of an agent system were not supported in the system.

PAGE 16

8 Figure 2-1. Architecture of earlier aZIMAS system The redesigned aZIMAS system eliminates many of the earlier limitations. They are many improvements in the current system: Generalization of the system from being just apache-specific. The current system can be deployed in any web server with little effort A module-based architecture that provides flexibility and allows system extension (see appendix A for a list of modules and their functionality) The entire system is web-based, eliminating the need for special client-side components Provides support for many standard features expected in agent systems like support for naming, richer communication primitives and event management facilities

PAGE 17

CHAPTER 3 AZIMAS SYSTEM ARCHITECTURE Figure 3-1 shows the high-level design consisting of both the client and server components of the aZIMAS System. Web Browser aZIMAS Agent Environment (AE) A n y Web Server Server Module Figure 3-1. The aZIMAS high-level design 3.1 Client Side Components Client components in agent systems are typically used by users to launch new agents, check the status of launched agents, and in general to monitor and direct the actions of an agent. In contrast to many available agent systems and to the previous version, the current aZIMAS system does not require a separate client side component for launching agents. Instead, users interact with the aZIMAS Agent Environment using a web browser. Azimas WebInterface module exposes the functionality of the aZIMAS System. Interaction with the AE takes place through means of HTTP POST requests. The request structure requirements in AE for HTTP POST messages are well defined, making it easy for user applications to issue requests to the AE. We have also developed a preliminary programming model called Web Agent Programming Model (WAPM) that would enable even non-programmers use the functionality of the agent system. WAPM defines a simple scripting language that can be used to direct and define an agents action in a very high-level language. We have adopted HTTP POST as the basic communication mode to interact with the AE since it is easy to define a request structure using POST. Also, POST enables us to deal with arbitrarily large data blocks. 9

PAGE 18

10 3.2 Server Side Components The server side components consist of the server extension module and the aZIMAS Agent Environment (AE) (Figure 3-2). A E Web Content Provider From / To Web server Module HTTP POST Messages Messaging WebInterface AgentEngine Logger AgentServices Authentication SecurityManager AgentAPI Agents AgentSpace Resource Controller Data Store Communication Manager Name Registry Figure 3-2 The aZIMAS Agent Environment (AE) The server extension module captures HTTP requests that are intended for the AE (identified by a specific request extension .env) and routes it to AE. aZIMAS AE is a minimal layer framework that consists of a Messaging and WebInterface component, an AgentEngine component, and an AgentSpace component. The Messaging component acts like a gateway in the AE. It sends and receives messages between the web server module and the AgentEngine. WebInterface component acts like a content publisher. It exposes the functionality of the agent environment through static and dynamic web pages and provides the World Wide Web interface to the AE. The AgentEngine provides services like verification of request structure related to agent messages, and authorization and authentication of incoming messages. The AgentEngine passes incoming agents to the AgentSpace after verification. The Agent Engine also includes a Logger to log system activities. The AgentEngine also has an integrated SecurityManager to control access to the Azimas AgentAPI. The AE exposes its services via the Azimas API.

PAGE 19

11 The AgentSpace component forms the heart of the Azimas Agent Architecture. AgentSpace deals with supporting the lifecycle of an agent directly. It provides all necessary functionality needed by the agents like migration, agent communication, persistence, etc. On receiving the agents from AgentEngine, AgentSpace registers them in a Name Registry and then loads their state/code for execution. AgentSpace keeps track of the various agents in the AE and provides the interfaces to the Agent API. To some extent, AgentSpace also controls usage of resources like memory and disk space by agents through a Resource Controller. A Communication Manager handles message transfer among agents as well as transporting agent packets as HTTP messages to other hosts. Storage requirements of agents are handled using a Data Store.

PAGE 20

CHAPTER 4 AGENTS IN AZIMAS We define an azimas agent as a program that acts on behalf of an entity, and which has the ability to move autonomously from one host to another. The entity, which owns the agent (owner), can be a user, program or an organization. Agents in azimas can only exist within the context of the AgentSpace in Agent Environment (AE), which provides the functionality necessary for the agents to operate. In aZIMAS, every agent is associated with a home base, which refers to the AE at which the agent was first created. For an agent, hosts other than the home base are referred to as foreign bases. An azimas agent can be described by the following attributes: -ID, which uniquely identifies it within an AE -Home base, the AE at which the agent was first created -Credentials to prove its authenticity -Data (like program state and output, itineraries, agent type etc.,) and -Code that forms the agent program The attributes of an agent are packaged and represented as an AgentTravelPack when an agent is transferred between azimas hosts. In aZIMAS, agents are classified as either Interactive or Non-Interactive: Interactive Agents. Agents that have the ability to respond to the activity of their owners, and possibly other agents. Interactive agents can cooperate with other agents in realizing a common goal. These agents have the ability for synchronous and asynchronous collaboration and can be used to build distributed Internet Applications. Interactive agents can optionally specify AppletContexts, which provides an applet interface for their owners to direct their actions. Non-Interactive Agents. Agents that are primarily concerned with processing information available at various sources on the Internet. Non-interactive agents are suitable for information search and filtering applications. These agents have the ability to replicate or clone themselves. A non-interactive agent and its clones form a group, within which synchronous and asynchronous communication is possible. Non-interactive agents normally do not interact with agents outside their group and typically communicate results and messages to their owners in an asynchronous manner. 12

PAGE 21

13 Every incoming agent is expected to identify its type (interactive/non-interactive). The purpose of this classification is to aid the aZIMAS AE in decisions of load balancing. When the number of agents in the system exceeds a given threshold (available system memory, disk space), the AEs Resource Controller gets invoked. The Resource Controller typically suspends some agents to ease the strain on the AE. Usually low priority agent threads get suspended in no particular order, with preference given to interactive agents and agents belonging to the AEs domain (home base agents). 4.1 Naming Naming Service in aZIMAS provides agent location services. It enables one to locate an agent by using a logical name. Naming service enables us to create an agent in one application and invoke it using some other application. Both the Agent Environment and Agents are named in aZIMAS. Name Registry is a lookup service provided in every AE that assists in locating an agent. Many existing systems like Aglets and Odyssey do not have a Distributed Naming service. Aglet and Odyssey both have a simple local lookup table that allows one to associate a string with an agent's URL. Voyager from ObjectSpace supports Distributed Naming. In Voyager, a name is an ordered pair (URL:port). Once an agent is created it can be referred from any application by using its logical name, irrespective of where the agent is currently residing. In aZIMAS, a hierarchical naming scheme is followed. Agents are named after the agent environment in which they are created. All agents created at a given Agent environment, called its home AE, have a unique name. This is ensured by using a unique sequence number to each agent. Sequence numbers generated at a given AE are always in an increasing order (1,2,3...). However, this does not ensure a globally unique name. To provide a globally unique name, we can make use of the name of the AE. Thus an agent is referred as an ordered pair (AE Name,Agent Name). This ensures globally unique agent name.

PAGE 22

14 A gent 3 A gent 2 A gent 1 AE harris:80 A gent 1.1 A gent 1.2 A gent 1.3 Figure 4-1. Agent Naming Hierarchy By way of example (Figure 4-1), consider an Agent Environment (AE) hosted by the web server at http://www.harris.cise.ufl.edu:80/ Consider 3 Agents created at this AE. Once they are registered with the local name server they can be referred locally as Agent1, Agent2, and Agent3. The fully qualified global name would be: http://harris.cise.ufl.edu:80/Agent1 http://harris.cise.ufl.edu:80/Agent2 http://harris.cise.ufl.edu:80/Agent3 When an agent creates a clone, the cloned agent is named after the parent agent and follows the same naming convention as the parent. Thus, if Agent1 has three children, they will be named Agent1.1, Agent1.2, and Agent1.3. They can be then be referred as: http://harris.cise.ufl.edu:80/Agent1.1 http://harris.cise.ufl.edu:80/Agent1.2 http://harris.cise.ufl.edu:80/Agent1.3 Consider the scenario where an agent has migrated from the home base to a foreign base and later a new agent is created at the home with the same name. Now, the question arises as to whether this would result in two agents with the same global name. This cannot happen in our system, because the home base maintains the persistent state of an agent till the agent is disposed (termination) however long that might take. In the worst case, this might require us to maintain the state information of thousands of agents in the home base and hence may consume some storage. The storage costs would be irrelevant since hosting thousands of agents would anyway require us to have a high-end system. A completely autonomous agent where the agent has no specific home base is interesting. It would be very difficult to trust any agent in such a model. In

PAGE 23

15 our model, agents are created at a home base, where a user has initially registered. This registration process provides a means for the host system to ensure that the user meets certain guidelines and hence can trust future agents created by the user. Hosts do not trust foreign agents and may not provide them with the same set of privileges that they would for locally created agents. 4.2 Agent Communication For cooperation and collaboration between agents to succeed, we need an effective communication medium. A communication medium facilitates agent interaction with other agents and its owners. aZIMAS provides support for both synchronous and asynchronous agent communication. Asynchronous communication is implemented through use of mailboxes. Every agent is allocated a mailbox, which stores incoming messages for the agent. A message sent by an agent is stored in the receiver's mailbox. An agent can do a blocking or non-blocking wait for messages. When an agent blocks waiting for a message, it is notified upon the arrival of a message. If the agent is non-blocking then it has to explicitly check its mailbox to retrieve the messages. Synchronous communication is established through a rendezvous point established by the aZIMAS system. A rendezvous point opens up a connection between two agents in an AE, through which data transfer is possible. aZIMAS provides limited location transparency support, made possible through use of a forwarding service provided by every AE. Thus, when an agent receiving messages in an asynchronous manner chooses to migrate to a new location it will continue to receive messages at its new location. 4.3 Event Management aZIMAS uses a type of publisher-subscriber model for event management. In this model, a publisher acts as an event generator. Subscribers receive events generated by publishers. An event manager facilitates event management and acts as the deliverer of events to the subscribers. Publishers register themselves with the event manager and deliver events to it. Agents can query the event manager for available publishers and can subscribe to specific publishers. An agent can

PAGE 24

16 act as both a publisher and a subscriber simultaneously. A subscriber in an aZIMAS AE will continue to receive event notification even after it has moved to a different host. Events are Java objects in aZIMAS, which provide a general description of the event along with its details. 4.4 Mobility and Agent Persistence Mobile agents, by their very nature, need to have the ability to move from one host to another. aZIMAS supports only weak migration for Agents. In weak migration, only the code and state of the agent is transferred as opposed to strong migration, where the execution state is transferred. Attempts have been made to provide for strong migration (Bouchenak 1999) by either extending the Java Virtual Machine or by capturing the execution state through use of a backup object. Though strong migration has a number of positive aspects, the high overhead introduced by these techniques makes it unattractive to our cause. In aZIMAS, agent migration is handled by the AE. An agent issues a migration request through a move method call. The move method when invoked never returns and takes an itinerary string as a parameter. An itinerary string is an ordered triplet (destination_host: method: parameter), indicating the destination host to which the agent wishes to migrate, the method to be invoked upon arrival at the destination along with parameters that needs to be passed to the method. As of now, only simple parameters like strings and primitive types can be passed as method parameters. Agents are passive participants in the migration process and cannot react to events that take place during migration. However, when migration fails we invoke the process() method on the agent object. This gives the agent a chance to decide whether it wants to move to a different host or try migration later on. This is possible because when a move() is invoked, only the agent execution is stopped, the agent object is not destroyed. The state of the agent is preserved in an AE until an agent migrates or terminates. Agent persistence is supported through use of Java's serialization mechanism. An agent's state and code, once serialized, persist physically at the home base. At foreign bases, serialized agent state and code is maintained only in memory. The agents home base always keeps track of

PAGE 25

17 the location information of all agents belonging to its domain (home agents). This is made possible by an update to the location information at the home base whenever the agent moves between hosts. When an AE receives a foreign agent it sends the agents home base AE a status message indicating the agents new location. 4.5 Security A mobile agent system needs to define proper security framework before it can be trusted and deployed widely since they often will have to execute arbitrary code from unknown agents. In addition to the security issues related to the agents in general, new issues arise when mobile agents are deployed on the web. Fortunately, dealing with web security is not as hard as that of agent security and acceptable solution exists to many problems (Gritzalis and Spinellis 1997). To prevent unauthorized web use, aZIMAS AE requires each user to follow a registration process before being allowed to access agent services. This enables the AE to identify each request with a specific aZIMAS user. Since HTTP is a plain-text protocol it is possible for snoopers to gain access to confidential information. Use of secure HTTP where possible should eliminate this problem. It should be noted that in the current system no provision has been made to share user information across AEs. Thus, a user registered at a particular AE can use services of other AEs only indirectly through use of agent programs. To make registration information common across AEs, one can adopt a central registration server. A detailed analysis of security issues in agent systems in provided in (Jansen and Karygiannis 1999). Broadly, there are three main classes of threats in agent systems: 1. Agent-to-Platform. The agent exploits weakness in the agent system to gain unauthorized access to resources, or otherwise launch attacks on the agent system. Numerous techniques have been developed to protect an agent system from harmful agents like safe code interpretation, signed code, proof carrying code, state appraisal etc., 2. Platform-to-Agent. This category of threats represents situations in which the agents security is compromised by attacks from the agent system. Preventing this type of attack is generally difficult since the agent system controls the execution environment of an agent. There are some techniques to prevent attacks from the agent system, but they tend to fall more towards detection that prevention.

PAGE 26

18 3. Agent-to-Agent. In this category, an agent launches an attack against another agent possibly exploiting security weakness of the other agent. These types of attacks can usually be tackled using the same techniques that are employed for protecting the Agent platform. The current system does not have any provision to prevent attacks by the platform. We assume that aZIMAS AEs are hosts trusted by the agents. To prevent attacks by the agents, aZIMAS employs a combination of techniques. Every agent is expected to carry credentials identifying its owner and the home base. As like many other agent systems, aZIMAS makes use of Javas inbuilt security mechanisms to prevent runtime attacks by providing a Security Manager that controls access to potentially harmful system libraries. aZIMAS offers some security features to prevent agent-to-agent attacks. This includes agent blocking, in which an agent can block messages from another agent to it by requesting the AE.

PAGE 27

CHAPTER 5 USAGE In this chapter, we describe how users can use the services of the aZIMAS Agent Environment. We first describe how user interaction with AE takes place and show how to write a simple agent. We outline how the sequence of events that take place inside the AE to process agent requests. Finally, we describe two agent applications developed using our agent API. 5.1 User Interaction with AE Figure 5-1. Agent Environment (AE) Web Interface Users interact with the AE through means of a web-based interface. Users need to be registered with a particular aZIMAS AE before they can send agents to that AE. The registration process allows a user to choose a name and password, and also obtains details system and would see an interface similar to one shown in Figure 5-1, which lists various such as the users email address. Once a login has been created the user can login to the 19

PAGE 28

20 options. To create an agent, the user selects the createAgent option, provides a Logical name for the agent, and also specifies the location of the compiled agent class file. Finally, the user submits the agent to the Agent Environment (AE). Details on how the AE processes the request is provided in the request processing section at the end of this chapter. 5.2 Writing Agent Programs To allow users to create their own agents, aZIMAS provides a development package. Agent programmers need to download this package locally to their machine. The package includes two important java classes: a basic agent class called Azimas, as well as a class called AzimasAPI, which includes all methods that are available for agents to use in an AE. In order to write an agent, one needs to create a java program that extends the abstract base agent class Azimas. The base agent class Azimas provides a number of useful methods that implement functionality that is useful to all agents in aZIMAS. The Azimas class defines two abstract methods, run() and process(). //agentexecutionstartsinrun publicabstractvoidrun(); //messagesreceivedtotheagentaredeliveredtotheprocessmethod publicabstractObjectprocess(Objecto); A class that extends the base agent class Azimas must implement both the run() and the process() method. The AE executes an agent by invoking the run() method on it. The process() method is used by the AE to deliver messages sent to the agent. The messages might be from other agents or requests from the users of the agent. It is entirely up to the agent to decide how to structure the run() and process() methods. aZIMAS also provides a data store for every agent. The data store allows an agent to store and retrieve any generic java object. An agent can access the data store by invoking the store and retrieve method calls present in the AzimasAPI. When an agent migrates, the AE automatically ships the data store along with the agent. The

PAGE 29

21 AgentSpace module in the AE manages the data store. As an example, the code for a simple agent program is shown below the agent retrieves content from a user specified URL. publicclassSimpleAgentextendsAzimas{ publicvoidrun(){} publicObjectprocess(Objecto){ Stringrequest=(String)o; ObjectresObj=null; if(request.equals("visit")){//visitauserspecifiedwebsite Stringsite=retrieve(this,site); Stringemail=retrieve(this,email); AzimasAPI.getURLNoTags(this,site,data); resObj=retrieve(data); } else{//startingpage..displayhtml Stringhtml=; html=SitetoVisit:
; html=EmailAddress:
; html=html+AzimasAPI.includeAuthHTML(this); html=; html=; resObj=(String)AzimasAPI.applyHTMLTemplate(html); } returnresObj; } If no specific request is issued, but the agent is just accessed by the user from the web (by selecting from a list of agents displays by the AE), then the agent just returns some formatted HTML code. The HTML code serves like the index page for the agent. It encodes authorization information as hidden tags (these codes are generated by the AE and are accessed by the agent by a call to the includeAuthHTML() in AzimasAPI). When the user fills out the fields and submits the form, the AE receives the form-data. It first parses submitted form data and stores the name, value pairs in the data store for easy access to the agent. It then invokes the process() method of

PAGE 30

22 the agent. The agent retrieves contents of the site mentioned by the user and filters it to extract only plain-text and returns the result back. This agent merely reacts to user-triggered events and does not do any specific startup initializations in the run() method. All events are delivered to an agents process() method. 5.3 Request Processing in the AE This section explains how an AE processes requests received from the web from users. The AE exposes its services to the user through web pages served by the WebInterface module. Agent requests are identified by an extension .env associated with them. When a user types an URL with an extension .env, they are captured and forwarded to the AE by the server extension module. The web servers server extension module captures the request and passes it on to the Messaging component of the Agent Environment (AE). The user is informed about the successful transmission of request and provided a link to query about the agents status, and output. The status page provides information about the current location of the agent, its trust level etc. After eliminating HTTP headers, the Messaging component transfers control to the AgentEngine. Verification of the clients request structure takes place in the AgentEngine. If verification is successful, the AgentEngine passes the request to the AgentSpace for further processing. A valid HTTP POST request intended for the AE needs to be in conformance to the request structure expectations of the AE. A requestType is a basic field that needs to be present in all messages directed to the aZIMAS AE. It helps the AE in deciding how to process a request. Depending on the type of the request, the AE may expect additional fields. For example, a message containing agent code is handled differently based on the request type: If the request type is createAgent,it implies that a new agent needs to be created at the AE. The AE stores the code of the agent in a separate folder created for the user. The code is then loaded and the agent execution begins, provided necessary resources are available. The AE expects the following fields properly completed in the HTTP request: userName,userAuth,agentName,agentType,agentFileName,agentFile.

PAGE 31

23 If the request type is agentPack, the AE interprets it as a request that contains a bundled agent from a different AE. The AE allocates only temporary space for the agent under a visitors folder. The AE receiving an agentPack also informs the home AE about the successful migration and then restores the state of the visiting agent. The request structure expectations are well defined in aZIMAS. This enables user applications to access aZIMAS services by following the correct request structure. An example POST request illustrating a createAgent request is shown below. -----------------------------30881262316024 Content-Disposition:form-data;name="requestType" createAgent -----------------------------30881262316024 Content-Disposition:form-data;name="agentName" Spider -----------------------------30881262316024 Content-Disposition:form-data;name="agentType" Non-Interactive -----------------------------30881262316024 Content-Disposition:form-data;name="userName" bill -----------------------------30881262316024 Content-Disposition:form-data;name="userAuth" 74VTJFYlcQ0RQ51hUo3qupW7no52yNA7iK5gVRU -----------------------------30881262316024 Content-Disposition:form-data;name="agentFile";filename="Spider.class" [ ClassBytes ] -----------------------------30881262316024 5.4 Application Scenarios In this section, we describe two agent applications. We first introduce Spider a WebCrawler agent that can be used to index, and archive websites. Next, we describe YoYo an agent that can be used to process, filter, and synthesize information from various websites. 5.4.1 Spider Mobile Web Crawler Agent Spider is a Mobile web crawler that can be used to index and archive entire websites. The agent is first uploaded to an aZIMAS enabled web server from a web browser. Given a domain to start with (hereafter called simply, crawldomain), spider first determines whether the domain has an aZIMAS enabled web server. If the crawldomain has agent capabilities 1 then spider moves to the remote server. The Agent Environment at the crawl domains web server receives 1 Agent-enabled/capable server refers to a web server enhanced with aZIMAS Agent Environment (AE)

PAGE 32

24 spider and spider continues its crawling process there. At the crawldomain web server, spider then moves to the Agent Environment at crawldomain web server and starts the crawling process from there. If the crawldomain does not host an agent system, then spider accesses the crawldomain remotely through HTTP connections. Figure 5-2 outlines the steps in the crawl process. Figure 5-2. Spider Mobile Web Crawler Algorithm Spider Mobile Crawler Algorithm 1. User uploads spider to an AE residing at http://www.cise.ufl.edu (CISE) and specifies the domain to crawl as http://www.harris.cise.ufl.edu (HARRIS) and defines LIMIT the number of links to follow or amount of data to mine 2. Spider determines whether HARRIS is agent-enabled. 3. HARRIS is not agent-enabled. Crawling of the crawldomain must be done remotely from the current AE. Go to Step 6 4. HARRIS is agent-enabled. Spider moves to HARRIS 5. The AE at HARRIS receives spider and loads it in its AgentSpace where spider starts executing 6. Start a breadth-first traversal of the crawldomain starting at the root domain. Collect links in the root document and store it in LIST 7. For each unvisited link in the LIST, retrieve the document indicated by the link and store the contents of the document in the DataStore 8. Add links found in the new document to LIST. If LIMIT has not yet been reached go back to step 7 9. If the user has specified an email address, mail the results back to the user 10. If necessary move back to the home AE. Stop Spiders crawling process is just like any other web crawler it does a breadth-first traversal of the crawldomain by starting at the root document and recursively follows the links in the document. The documents retrieved during the crawling process can be archived using the AzimasStorageManager. By default, crawling is limited to a user-specified domain. Crawling can also be controlled by other parameters like amount of data to be mined, or number of links to visit etcetera. During the crawling process, spider also collects a wealth of information like broken links, document access errors, and link referrals. The collected information can be valuable in web site diagnostics and maintenance. Figure 5-3 shows the initial interface. A simple search engine can be easily implemented on top of the collected data repository. Such a search engine can take advantage of the indexes built by the spider.

PAGE 33

25 Figure 5-3. Spider Mobile Web Crawler Agent Interface For a given search string or keyword, a lightweight version of spider can be used to perform a recursive search of a specific web page and all the links in it in real time. By its nature the spider agent is a data-intensive application. The spider approach achieves bandwidth efficiency when spider resides in a domain different from the crawldomain and the crawldomain has an aZIMAS-enabled server. 5.4.2 YoYo Information Synthesizer YoYo is an example of a typical information-processing agent. YoYo accesses content from various websites, then filters and transforms it to a form desired by the user. One typical data transformation function is to extract plain text from a web page, filtering out tags and other media objects. Using YoYo, users can integrate desired information from various websites. With YoYo the user has full control over the data source from which the information is retrieved. In the web, there are many websites that perform domain specific synthesis of information (Google News at news.google.com composes news headlines from various websites).

PAGE 34

26 We have used YoYo to compose information related to movies from various sites. YoYo can answer queries like "Given the title of a movie M and the local zip code, retrieve the following information about the movie (like cast, genre etc.), reviews for the movie, show times of the movie in the local city, and finally some links related to the movie. To answer this query, YoYo uses three Internet databases. It uses the Internet Movie Database (www.imdb.com) to obtain information about the movie, then it accesses the Movie Review Query Engine (www.mrqe.com) to obtain a list of reviews for the movie, Next it accesses Yahoo Movie Showtime Engine (movies.yahoo.com/showtimes) to obtain show time listings for theaters in the users zip code locality, and finally it accesses Netscapes Google search service (search.netscape.com) to obtain a list of links related to the movie. YoYo filters the data collected from the various sites to remove tags and other irrelevant information to obtain a neat summary. The synthesized information is then displayed to the user.

PAGE 35

CHAPTER 6 IMPLEMENTATION AND PERFORMANCE In this chapter, we first give a brief sketch of our implementation. We then present some preliminary performance results about the impact on the web server due to the presence of our agent component. 6.1 Implementation We have implemented most of the framework that has been described in the earlier chapters. Our implementation is in Java and uses the JDK 1.2. We have developed the basic agent environment component, which supports the lifecycle of the agents. We have implemented a server extension module for the popular Apache Web server. As part of our work, we have also developed a simple web server called Pluto, which interfaces with the AE. Pluto makes it easy to see the project in action even on systems with no installed web servers. The Agent Environment is implemented using Java. Java provides a number of features useful to agent systems like serialization mechanism, on-demand code loading, relatively strong security framework etc., which makes it an excellent language to base an agent system upon. Some popular agent systems based on Java [9] include Aglets, Concordia, Voyager, Odyssey, Ajanta etc. The web server dictates the choice of language for the server extension module. In our implementation of the apache module, we have used the C language. The core of the system is accommodated in five Java classes: AzimasMessaging, AzimasWeb, AzimasAgentEngine, AzimasAgentSpace,andAzimas-SecurityManager.The implementation is modeled according to the aZIMAS design described in chapter 3. All aZIMAS agents are derived from a basic agent class called Azimas, which helps enforce certain minimum guidelines for the agent programs. Agents are represented as threads in 27

PAGE 36

28 the AE. The base agent class has an attribute called AzimasSpaceInterface, which needs to be set by the Agent Environment. This is a Java object by means of which the agent accesses many services from the AE. To facilitate invocation as a thread, the system mandates that the agents provide a run() method, from where the agent code normally starts executing. Apart from these requirements, the AEs SecurityManager constrains the agent programs to make calls only to safe library methods. The aZIMAS API provides a safe way to access many useful functions. The method names model closely after the Java library convention. For example, to invoke a request to an external URL the agent just needs to make a call to the getLocationmethod, which takes an URL string as a parameter. The method call if successful returns the data retrieved from the URL. 6.2 Performance Evaluation In this section, we present some of the performance results obtained after deploying our AE on Apache web server. The performance of a web server is critical and should not be adversely affected by the presence of additional components. We carried out our simulation by sending HTTP requests at a gradually increasing rate using OpenLoad, a command line tool that can be used to test web server performance. Figure 6-1 shows the affect on the response time of the web server for various cases. The base case represents the situation when no agents were present in the AE. The second case represents the situation when 10 non-resource intensive agents were present in the AE. These agents typically accessed some site on the Internet and communicated the result back to their owners. Since we expect this type of agents to be more common on the web, we call them as typical web agents. The agents were uploaded in to the AE from a web browser and the base test case is repeated. From Figure 6-1, we can observe that there is only a negligible difference in the response time of the web server due to the presence of typical web agents, this is due to the fact that these agents did not make use of excessive CPU or system memory.

PAGE 37

29 01234505102030405060708090Number of ClientsResponse time (seconds) No Agents inthe AE 10 typicalagents 2-3 resourceintensiveagents 10 resourceintensiveagents Figure 6-1. Impact on web servers response time However, when resource intensive agents were uploaded to the AE, we could observe a noticeable difference in the response time. The effect is very obvious when we repeated the base test case with 10 resource intensive agents in the AE. The response time of the web server worsened by as much as 30 percent! Resource intensive agents, in this case, performed the computation of an N x N matrix multiplication where N = 300. The drastic change in response time occurs due to the fact that resource intensive agents take up much of the available CPU time thus affecting the web server processes. We observed a similar drop in available system memory when resource intensive agents were present in the AE (Figure 6-2). This effect is however easier to control than the previous one as it is easy for the AEs Resource Controller to make sure that the memory used by agent programs does not exceed the threshold set by the AE. Though there is only a negligible impact on the web server when typical agents were present, it is not advisable to co-locate the AE and a busy web server on the same machine. This is due to the fact that it is often not possible to know beforehand whether an agent is resource intensive or not.

PAGE 38

30 010203040506005102030405060708090Number of clientsAvailable real memory (MB) No agents inthe AE 10 typicalagents 2-3 resourceintensiveagents 10 resourceintensiveagents Figure 6-2. Impact on available system memory In our opinion, it is best if the AE is maintained in a machine different from the web server. To test this scenario, we repeated our simulation with the web server and AE located on different machines in the same network and subjecting the AE to large number of resource intensive agents. As expected, the response time of the web server was similar to the base (no agents) case and the performance implications were felt only in the machine where the AE was located.

PAGE 39

CHAPTER 7 CONCLUSION In this paper we described aZIMAS, a novel framework that realizes mobile agent systems within the context of the World Wide Web. The approach interfaces the agent system (Agent Environment) with web servers through means of a minimal server specific extension module and makes use of web browsers as clients. By making only the extension module as server specific it is possible to deploy the agent system uniformly in a wide variety of web servers. Our framework provides a reasonably secure environment for mobile agents to function on the Web. A significant limitation for Internet agents today is the lack of machine processable information on the web. The current web is mainly designed for human user and lacks machine processable structure and semantics. However, with the advent of XML and web services more and more structured information is being made available on the web. Efforts are also underway to annotate web pages with semantics using technologies like Resource Description Framework (RDF). The next generation web is envisioned to be a semantic web (Berners-Lee et al 2001). All these developments make the future of Internet agent systems bright and more promising. We are working on making the Azimas Agent API richer and better. One other area of interest is realizing aZIMAS agents as providers of web services. 31

PAGE 40

APPENDIX A AZIMAS AGENT ENVIRONMENT MODULES This appendix describes the various modules of the azimas system briefly. The Azimas Agent Environment is made up of the following modules (the actual module name indicated in parenthesis). 1. Azimas Messaging (AzimaMessaging) 2. Authentication, Registration, and Code Verification (AzimaInterface) 3. Name/Service Registry (AzimaRegistry) 4. Core Agent Services / Access Control (AzimaServices) 5. Agent Web Interface (AzimaWeb) 6. Agent Space (AzimaAgentspace) 7. Data Storage Interface (AzimaDataInterface) 8. Logger (AzimaLogger) 9. Azimas Database (AzimaStorageDatabase) 1. AzimaMessaging Synopsis: The entry/exit point for agents in the Azimas system. --Receives mobile agents from the apache web server and passes it to the AzimaInterface Module --Receives mobile agents from the AzimaInterface Module and sends it to the agents destination. The agents destination must be another azima integrated apache web server. Allows: AzimaInterface Uses: AzimaInterface 2. AzimaInterface Synopsis: Verifies the agents credentials, Verifies the agents code. If the agent passes verification, then --determines privileges that can be allowed for the agent --allocates data space for the agent, --registers the agent and its privileges in the Name Registry --facilitates web access of the agent and its data space by providing appropriate interfaces (calls AzimaWeb to achieve this) -transfers agent code and state to AzimaAgentSpace Allows: AzimaMessaging, AzimaServices Uses: AzimaServices, AzimaAgentSpace, AzimaLogger 32

PAGE 41

33 3. AzimaRegistry Synopsis: Provides a NameRegistry and ServiceRegistry. --provides convenient storage tables called lists, which can be used by other modules. --NameRegistry keeps track of various agents along with their privileges. --ServiceRegistry keeps track of the services offered by the agents in the system. Allows:*AgentServer* 1 Uses:*AgentServer* (datainterface to backup copies) 4. AzimaServices Synopsis: The Azima API (Application Programming Interface). --API is a list of methods provided by the Azima Agent Environment available for agents to use. In addition to many useful methods, Azima API provides special methods to support agent collaboration (like clone, merge, synchronize). Call to any API method is controlled by an Access Control layer, which determines whether an agent has sufficient privilege to use the API. Allows:AzimaAgentSpace,*AgentServer* Uses:AzimaWeb,AzimaLogger,*AgentServer* 5. AzimaWeb Synopsis: AzimaWeb facilitates web access of the agent and the agents data space. --Only the owner of the agent can access the agent. Provides suitable web authentication for this purpose. The web interface allows the owner of the agent to control the agents behavior. Allows:*AgentServer* Uses: None 6. AzimaAgentSpace Synopsis: Responsible for loading the code of an agent in memory along with its state and starting the agents execution. --The agent code and state is obtained by a call to the AzimaDataInterface. Each agent is allocated a thread before its state and code is loaded into the memory. An agent can start executing when AzimaAgentSpace starts the thread allocated to the agent. All agent threads run under the control of a main thread called azimaThread owned by the AzimasAgentSpace module. More than one azimaThread can exist in the Agent Space. Performs load balancing tasks within the agent space through operations on agent threads like suspend, resume etc., 1 References to *AgentServer* should be read as referring to the following modules that are present in the Azimas Agent Sever, i.e. AzimaInterface, AzimaServices, AzimaDataInterface

PAGE 42

34 Allows:*AgentServer* Uses:AzimaServices 7. AzimaDataInterface Synopsis: Handles all storage needs of agents. --provides methods to create, modify, and delete storage spaces. Handles serialization and deserialization of agent states. Provides methods to perform variety of data processing on files. Provides a logical view of stored data. Actual storage handled by the lower level AzimaStorageDatabase. Allows: All except AzimaAgentSpace Uses: AzimasStorageDatabase 8. AzimaStorageDatabase Synopsis: Stores files in a suitable physical format. --supports only a flat-file system. Allows: AzimaDataInterface Uses: None 9. AzimaLogger Synopsis: Maintains system and agent logs. --All agent requests are logged in the agent logs. All Agent Server operations are logged in the system log. A special migration log maintains agent entry and exit records. Allows: All modules except AzimaAgentSpace Uses: AzimaDataInterface

PAGE 43

APPENDIX B SERVLET-BASED APPROACH In aZIMAS, the Agent Environment (AE) is glued to the web server through means of a server module. The functionality of the module can also be implemented using servlets. In this appendix we provide a brief overview of servlets, and explain how the AE can be deployed using servlets. Servlets: Servlets (Sun 2002) provide a component-based, platform-independent method for building web-based applications, without the performance limitations of CGI programs. Servlets provide web developers with a simple, consistent mechanism for extending the functionality of a Web server and for accessing existing business systems. Containers, some times called servlet engines, are web server extensions that provide servlet functionality. Servlets can interact with web clients via a request/response paradigm implemented by the servlet container. A servlet container can be built into a host web server or installed as an add-on component on the Web Server via that server's native extension API. All servlet containers provide support for the HTTP protocol. Additional protocols like HTTPS (HTTP over SSL) may be supported. In functionality, servlets lie somewhere between the Common Gateway Interface (CGI) programs and proprietary server extensions such as Apache Modules, Netscape Server API (NSAPI), or Microsofts IIS ISAPI extensions. Compared to other server extension mechanisms, servlets have the following advantages: 1. They are generally much faster than CGI scripts because a different process model is used 2. They use a standard API that is supported by many web servers 3. They have all the advantages of the Java programming language, including ease of deployment and platform independence 4. They can access a large set of APIs available for the Java platform Implementing the server module as a servlet: The minimal-server module employed in aZIMAS can be easily realized as a servlet. A servlet (e.g. AzimasInterfaceServlet) can be developed that routes requests from the web server to the agent environment. Below, we summarize the sequence of operations that would be needed to route a request between a web client and the agent environment in a servlet-based approach: 1. A client (e.g. a web browser) accesses a web server and makes an agent-related HTTP request 2. The request is received by the web server and handed off to the servlet container (servlet engine) 35

PAGE 44

36 3. The servlet engine invokes the AzimasInterfaceServlet and passes the request and response objects to it. The request object contains such information like the remote user who issued the request, HTTP POST parameters sent as part of the request and other relevant data 4. The AzimasInterfaceServlet passes the request object to the AE's messaging module and waits for a response 5. The AE processes the request object and sends a suitable reply to the AzimasInterfaceServlet 6. The AzimasInterfaceServlet then sends this data back to the client via the response object The benefit of adopting a servlet-based approach would be that the AE could be deployed uniformly on any web server that supports servlet technology. In the current approach, the server module is web-server specific.

PAGE 45

LIST OF REFERENCES Berners-Lee T, Hendler J, Lassila O. The Semantic Web, Scientific American, May 2001 Bouchenak S. Pickling threads state in the Java system. Third European Research Seminar on Advances in Distributed Systems (ERSADS), Madeira Island, Portugal, 1999 Funfrocken, S. How to integrate mobile agents into Web Servers, Proceedings of the 6th Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises, pages 100-106, IEEE Computer Press, Cambridge MA, 1997 Gritzalis S, Spinellis D. Addressing threats and security issues in World Wide Web technology, Proceedings of 3rd IFIP TC6/TC11 International joint working Conference on Communications and Multimedia Security, pages 33-46, Chapman and Hall, Athens Greece, 1997 Goddard T, Sunderam V.S. WebVector: Agents With URLs, Proceedings of the 6th Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises, pages 100-106, IEEE Computer Press, Cambridge MA, 1997 Horvat D, Cvetkovic D, Milutinovic V. Mobile Agents and Java Mobile Agents Toolkits, Proceedings of the 33rd Hawaii International Conference on System Sciences Volume 8,pages 29-39, IEEE Computer Press, Hawaii, 1998 Jansen W, Karygiannis T. Mobile Agent Security, National Institute of Standards and Technology--Special Publication 800-19, August 1999 Lingnau A, Drobnik O, Peter. An HTTP-based Infrastructure for Mobile Agents, Proceedings of the 4th International WWW Conference, pages 461-471, O'Reilly and Associates, Boston MA, 1995 Marques P, Fonseca R, Simes P, Silva L, Silva J. Integrating Mobile Agents into Off-the-Shelf Web Servers: The M&M Approach, Proceedings of the International Workshop on Internet Bots: Systems and Applications, IEEE Computer Press, Munich, Germany, 2001 Nalla A, Helal A, Renganarayanan V. aZIMAs: Almost Zero Infrastructure Mobile Agents System, Proceedings of the IEEE Wireless Communications and Networking Conference, IEEE Computer Press, Orlando FL, 2002 Stroud F. Internet Agents, CWSApps, URL: http://cws.internet.com/agents.html Accessed on 12th December 2002 Sun Microsystems, Servlet Specification 2.4, URL: http://java.sun.com/servlets/ Accessed on 12th December 2002 37

PAGE 46

BIOGRAPHICAL SKETCH Subramanian Arumugam was born in Madras (Chennai), India. He finished his high school from M.Ct.M, Madras. He joined SVCE for his undergraduate work and received his bachelors degree in information technology from the University of Madras in May 2000. Since then he has been a graduate student in the Computer Science Department at the University of Florida. 38


Permanent Link: http://ufdc.ufl.edu/UFE0000632/00001

Material Information

Title: Azimas: Web Mobile Agent System
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000632:00001

Permanent Link: http://ufdc.ufl.edu/UFE0000632/00001

Material Information

Title: Azimas: Web Mobile Agent System
Physical Description: Mixed Material
Copyright Date: 2008

Record Information

Source Institution: University of Florida
Holding Location: University of Florida
Rights Management: All rights reserved by the source institution and holding location.
System ID: UFE0000632:00001


This item has the following downloads:


Full Text











AZIMAS: WEB MOBILE AGENT SYSTEM


By

SUBRAMANIAN ARUMUGAM













A THESIS PRESENTED TO THE GRADUATE SCHOOL
OF THE UNIVERSITY OF FLORIDA IN PARTIAL FULFILLMENT
OF THE REQUIREMENTS FOR THE DEGREE OF
MASTER OF SCIENCE

UNIVERSITY OF FLORIDA


2003






























Copyright 2003

by

Subramanian Arumugam






























TO MY MOM AND DAD
















ACKNOWLEDGMENTS

I would like to express my sincere gratitude to my advisor, Dr. Abdelsalam Helal, for

being a source of continuous support and encouragement throughout my graduate studies.

My thanks also go to the members of my thesis committee, Dr. Michael P. Frank and Dr.

Beverly A. Sanders, for reading previous drafts of this thesis and providing suggestions that

helped improve its contents and presentation. I would also like to acknowledge the CISE

department for its support that enabled me to present this work at the IEEE International

Conference on Mobile Agents in Barcelona, Spain.

















TABLE OF CONTENTS


A C K N O W L E D G M EN T S ......... ....................................................................................... iv

LIST OF FIGURES .................................. .................................... vii

A B S T R A C T ..........................................................................................v iii

CHAPTER

1 IN T R O D U C T IO N .......... .... ................................................... ........ .. .. ............ 1

1.1 A gents E explained ............................................................ .... ............................. . 1
1.2 M otiv action ................................................................. .................................... . 3

2 RELATED W ORK ........................... ................ ................ 5

2.1 Integrating Mobile Agents With Web Servers .............................. ............................ 5
2.2 Previous W ork On A ZIM A S ......... ........................................................ .............. 7

3 AZIMAS SYSTEM ARCHITECTURE....................................................... ..............9

3.1 C lient Side C om ponents......................................... ....................... ..................... 9
3.2 Server Side Com ponents ......... .................................... ...................... .............. 10

4 AGEN TS IN AZIM A S .............. ................................................. ......... ..... 12

4 .1 N a m in g ...................................................................................................................... 1 3
4.2 Agent Com m unication ............................................................ .... ....... .... 15
4.3 Event M anagem ent .................................................................. ...... ....... 15
4.4 M obility and A gent Persistence ................................................................ .............. 16
4 .5 S e cu rity ............................................................................................... 1 7

5 USAGE ....................................... .............. 19

5.1 U ser Interaction w ith A E .................................................. ................................ 19
5.2 Writing Agent Programs ........................................................... .............. 20
5.3 Request Processing in the AE............................ ................... ............... .............. 22
5.4 A application Scenarios .................. .. .............. ....... ................ ........ .. 23
5.4.1 Spider M obile W eb Crawler Agent............... ............................ .. ........... 23
5.4.2 YoYo Inform ation Synthesizer............... ..................................................... 25










6 IMPLEMENTATION AND PERFORMANCE............................................................. 27

6 .1 Im p lem en tatio n ......... .... ............. .. ................................................ .................. 2 7
6.2 Perform ance Evaluation ......... ................ ...................................... .............. 28

7 CONCLUSION ................. ............................ 31

APPENDIX

A AZIMAS AGENT ENVIRONMENT MODULES ................................................... 32

B SERV LET-BA SED A PPR OA CH .............................................................. ................... 35

LIST O F R EFEREN CES......................... ............................... ....................... 37

BIOGRAPHICAL SKETCH .......................................... ......... 38

















LIST OF FIGURES

Figure pge

2-1 Architecture of earlier aZIM A S system ........................................ .......................... 8

3-1 The aZIM A S high-level design................................................. ................................ 9

3-2 The aZIMAS Agent Environment (AE)................................................................ 10

4-1 A gent N am ing H ierarchy.............................................................................. .......... ...... 14

5-1 Agent Environm ent (AE) W eb Interface............................................................ ...... 19

5-2 Spider Mobile Web Crawler Algorithm ..................................................... ............. 24

5-3 Spider Mobile Web Crawler Agent Interface ........................................... ............... 25

6-1 Im pact on web server's response tim e......................................... ............................ 29

6-2 Impact on available system memory ....................................................... ............... 30
















Abstract of Thesis Presented to the Graduate School
of the University of Florida in Partial Fulfillment of the
Requirements for the Degree of Master of Science

AZIMAS: WEB MOBILE AGENT SYSTEM

By

Subramanian Arumugam

May 2003
Chair: Abdelsalam A. Helal
Major Department: Computer and Information Science and Engineering

Mobile agents technology opens up new avenues in personalizing and customizing the web

experience of users. It provides new possibilities for deploying distributed applications using

existing web infrastructure. One reason why mobile agents are not yet popular on the Web is the

lack of an easily deployable framework that would facilitate their existence. Existing mobile

agent systems usually require heavy infrastructure that lacks interoperability if deployed on the

Internet. In this paper, we describe aZIMAS (almost Zero Infrastructure Mobile Agent System)--a

framework that will enable the execution of lightweight mobile agents on the Internet. aZIMAS

uses existing platform independent protocols like HTTP to achieve code mobility and agent

interaction. Our approach involves adding a minimal infrastructure layer, called Agent

Environment (AE), over existing web servers and using web browsers as clients. By basing our

framework firmly on existing web servers and browsers, we hope to leverage the pervasiveness of

web browsers and servers and achieve similar pervasiveness for mobile agents.















CHAPTER 1
INTRODUCTION

Mobile agents have generated a lot of interest in recent years and are becoming

increasingly important because of the flexibility they provide and their ability to utilize

distributed resources. In this chapter, we provide the reader with a brief introduction on agent

technologies, its applications and limitations. We then describe the motivation behind this

work and summarize our contributions.

1.1 Agents Explained

An agent can be defined as a software abstraction that acts on behalf of an entity and has the

ability to make autonomous (independent) decisions on behalf of the entity. The entity can be a

user, program or an organization. Mobile agents are agents that have the ability to migrate across

nodes in a network. Agents normally reside within the context of an agent system. An agent

system is a software entity that provides the execution environment for agents and supports their

lifecycle (agent creation, execution, termination, migration). One other perception of agents is to

view them as an advanced structuring technique in programming. As computing has evolved,

structuring techniques for programs also have grown in sophistication: subroutines/ functions,

abstract data types, objects and now finally agents.

The agent paradigm has potential use in three application domains:

1. Information processing. Data-intensive applications where the data is remotely located can
be structured using agents. The application launches an agent that moves near the data source,
performs computation on the data locally, and finally returns back to the application with the
collected results. Compared with traditional client-server model, this approach is efficient
since it conserves bandwidth and limits network resource consumption.

2. Disconnected computing. Applications residing on mobile nodes like laptops, PDAs, and
smart phones have limited resources and often have to deal with a weak network connection.
These applications can be designed as an agent and shipped to an agent system, which
normally has better resources.










3. Extending server functionality. It would be impractical to expect a server to satisfy all
possible needs (special-purpose computations) of its users. Employing the agent paradigm, an
interested user can ship the desired computation to the server and extend the functionality of
the server dynamically.

Some of the challenges the agent community faces are: the security concerns that mobile

agents pose to the host machines, lack of standards among agent systems that hinder

interoperability, lack of an easily deployable framework for agent systems, and lack of a killer

application that would force widespread adoption of agent paradigm. Given the amount of interest

in agent system research, many of these challenges seem to be resolvable in the near future. For

example, efforts are underway to standardize agent systems. Acceptable solutions to many

security concerns have been developed (Gritzalis and Spinellis 1997).

The deployment problem is especially important in our opinion. Many current agent systems

use non-standard protocols and require special infrastructure. This prevents widespread uniform

deployment of the agent system. In this paper we describe an agent system solution that can be

easily deployed in a uniform manner on a wide variety of systems. In our solution the agent

system is based web servers and uses existing protocols like HTTP to achieve code mobility and

interaction. By basing the agent framework firmly on web servers, we hope to leverage the

pervasiveness of web servers to achieve pervasiveness of mobile agents. It is our strong belief

that the popular agent model will be based on the Internet. This makes web servers a natural

choice as a deployment framework. The Internet is the fastest growing repository of information

and its data enormity and complexity make it an ideal domain for agent systems to solve a variety

of interesting problems. Some applications for Internet based agents are: complex queries that

require synthesizing information from a number of sources, mining large data repositories at the

data source, and managing user information on the web providing seamless synchronization with

various user devices (personal computer, laptop, PDA).










1.2 Motivation

The motivation for this work arises from the fact that agent technology and the Internet

together opens up new avenues in personalizing and customizing the web experience of users. It

provides new possibilities for deploying distributed applications using existing web

infrastructure. There are two important factors that we believe will make mobile agents a critical

part of the Internet in the near future. First, due to the explosive growth of content on the web, the

average user is subjected to overwhelming amount of information. It has become increasingly

necessary for the underlying software to take an active role in presenting useful information. This

involves information processing tasks like data filtering based on user preferences, automating

common tasks etc. Many commercial software attempts to alleviate this problem (Stroud 2002).

With the advent of web services, more resources are available in a structured and easily

accessible form than ever before. The second phenomenon is the increasing number of mobile

users. Unlike connected computers, mobile users often have to deal with a weak network

connection, limited resources (pI:'\\. memory, screen area). Hence, it is attractive to consider

options that would move resource and bandwidth consuming processes to remote locations. Some

of the problems arising out of both these trends can be attributed to the passive role played by

existing software tools, which merely display retrieved information. Whereas through the use of

mobile agents one can develop tools that actively participate in a user's web interaction process.

Mobile users can benefit immensely in areas like remote processing and data rendering, whereas

the average web user can tap on agents to cope with the information overload. With the Internet

having been identified as the most desirable platform for distributed applications, agents can also

help realize richer and dynamic forms of collaboration and cooperation. Given these advantages,

the goal of our work is provide a framework for agents to operate on the Internet and access

common web services. The framework should integrate seamlessly with existing infrastructure

tools realizing agents as a natural part of the World Wide Web.










Our previous work (Nalla et al. 2002) investigated the merits of an agent system that is based

upon existing web infrastructure software like web servers. The work resulted in the project

aZIMAS (almost Zero Infrastructure Mobile Agent System), a mobile agent system based on the

apache web server. The system had a very simple architecture and provided no support for

features like agent communication and collaboration. Since the system was custom designed for

Apache, deploying it in other web servers required extensive modification. We realized the need

to extend the aZIMAS framework. This resulted in our current improvised version, which

consists of a simple framework called Agent Environment (AE) that can plug-in to a web server

through means a server extension module specific to a web server.

The contributions of this paper can be summarized as follows:

1. We demonstrate a new agent system that is based on existing web technologies and which
requires no additional client-side components

2. We present a new technique for integrating agent systems with web servers that is based on a
lightweight web server-specific module. This approach enables the deployment of the agent
system in any web server with no modification

3. We investigate the performance implications of deploying an agent system along with a web
server

The rest of this paper is organized as follows: In Chapter 2, we give an overview of research

that deals with web integration of agent systems. In Chapter 3, we present the architecture of the

aZIMAS System with a detailed description of its Agent Environment (AE). Chapter 4 provides

an overview about aZIMAS agents and describes how issues like agent communication, mobility,

and security are handled. We then describe usage examples and application scenarios in Chapter

5. In Chapter 6, we discuss our implementation and present some preliminary performance

results. Chapter 7 concludes the paper with a note on our current work.















CHAPTER 2
RELATED WORK

In this chapter, we first present a survey of research that deals with the issue of integrating

mobile agents with web servers and describe how our approach is different. We then give an

overview of our earlier work and detail the specific contributions of this work.

2.1 Integrating Mobile Agents With Web Servers

There are a number of research projects that deal specifically with the issue of integrating

mobile agents into web servers. The approach taken by these projects fall in one of the following

two categories:

* Custom Web Server based. Develop a custom web server integrating an agent execution
component. The agent component handles agent related requests. Projects like WASP
(Funfrocken 1997) (Web Agent-based Service Providing), and Agent Server (Lingnau et al.
1995) take this approach

* Script based. Make use of server-side facilities like common gateway interface scripts to
launch applications that handle agent requests. M&M framework (Marques et al. 2001) and
WebVector (Goddard and Sunderam 1997) fall under this category

In the custom web server approach, agent system architecture is usually bound tightly to a

specific web server. The web server normally consists of an embedded agent server environment

which enables it to host mobile agents. Agent specific requests are exchanged via HTTP POST

messages with unique MIME-types. The web server recognizes messages with specific MIME

types as agent related and passes it on to the agent server for further handling. The problem with

this approach is that existing web sites may not want to replace their current web infrastructure in

favor of a custom-made web server. Custom-made web servers may not match the power,

reliability, and efficiency of production-quality commercial web servers. Thus, it is likely that any

agent enhancement solution that gains acceptance among web content providers is based on

existing web infrastructure software. Another issue with this approach is that the tight coupling










between the web server and the agent architecture makes it difficult to deploy the solution in a

wide variety of web servers uniformly.

In projects that make use of server-side scripts, a script normally handles the task of

receiving agents, and supporting their operation. In M&M agent system, web deployment is

achieved by making use of servlet technology. WebVector uses common gateway interface

scripts to receive and transport agents. If the custom server based approach makes the level of

coupling tight, the CGI/Servlet approach tends to decouple the web server and the agent system

completely. This has some important performance consequences:

1. The web server will incur a significant overhead if the agent system is bulky

2. Since the web server has no awareness of the agent system, neither the agent system nor
the web server can take advantage of internal optimizations

3. To access local resources, the agent system will have to act like any other normal HTTP
client

From a design perspective, a servlet-based approach would provide a uniform way to deploy

the AE on web servers that support servlets (see Appendix B for a discussion on how the server

modules can be implemented as servlets).

aZIMAS seeks to strike a compromise between the two approaches discussed above. Our

solution consists of an agent environment with a well-defined interface, so that it can easily plug-

in into existing web servers. In our approach, the agent environment remains the same for all web

servers. The agent environment is integrated into a web server through use of a simple server

module developed specifically for the server. Though this approach makes the server module

specific to each web server, we believe this is not a constraint to the deployment of the aZIMAS

AE. This is because the only task performed by the server module is to forward an agent-specific

HTTP request to the AE, get the reply back from the AE and communicate it to the client. Hence,

developing a server module for any given web server should be a relatively easy task.

We have developed an extension module for the popular apache web server to route requests

to the agent environment. We are currently investigating if a similar architecture can be achieved










on an IIS Server through the use of ISAPI extensions. For IIS server, an ISAPI extension that

could interface with the AE would be needed. Developing a server module for other web servers

should be a relatively easy task as almost all commercial web servers provide a library of routines

to help developers in creating extension modules.

Using a server module to integrate an AE offers number of other advantages. The web server

usually loads server modules during start up, so server modules incur little or no overhead in

processing a request. In addition, all important server data structures are usually available for the

server modules; hence clever optimizations can be done to improve request processing. Finally,

by moving web server specific tasks to the server module, we can keep the agent environment the

same for any web server.

2.2 Previous Work On AZIMAS

An earlier version of aZIMAS is shown in Figure 2-1. The goal of our earlier work was to

evaluate the feasibility of mobile agent integration with existing web servers. To this end a

demonstrative prototype agent system was custom-built for Apache web server. The system

consisted of a runtime layer that provided basic agent services. The users of the system created

agents by using an Agent Manager application present in the client side. The agents were

encapsulated in a HTTP request and sent to the Apache web server. Agents used the runtime

services provided by the Apache web server to move from its current location to the next server

in its itinerary. While moving between hosts the agent carried its entire code and data. Though the

system well served its purpose as a demonstrative prototype, it had significant limitations: the

system lacked a well-defined architecture with clearly defined interfaces and since the system

was custom-built for Apache, it was not possible to deploy it uniformly in a wide variety of Web

Servers. Most importantly, many standard features that one would expect of an agent system were

not supported in the system.

























MA Web Server


Web Browser


Figure 2-1. Architecture of earlier aZIMAS system

The redesigned aZIMAS system eliminates many of the earlier limitations. They are many

improvements in the current system:

* Generalization of the system from being just apache-specific. The current system can be
deployed in any web server with little effort

* A module-based architecture that provides flexibility and allows system extension (see
appendix A for a list of modules and their functionality)

* The entire system is web-based, eliminating the need for special client-side components

* Provides support for many standard features expected in agent systems like support for
naming, richer communication primitives and event management facilities
















CHAPTER 3
AZIMAS SYSTEM ARCHITECTURE

Figure 3-1 shows the high-level design consisting of both the client and server components

of the aZIMAS System.


Web Server I __ aZIMAS Agent
Browser Module I Environment
(AE)

Any Web Server



Figure 3-1. The aZIMAS high-level design

3.1 Client Side Components

Client components in agent systems are typically used by users to launch new agents, check

the status of launched agents, and in general to monitor and direct the actions of an agent. In

contrast to many available agent systems and to the previous version, the current aZIMAS system

does not require a separate client side component for launching agents. Instead, users interact

with the aZIMAS Agent Environment using a web browser. Azimas Weblnterface module

exposes the functionality of the aZIMAS System. Interaction with the AE takes place through

means of HTTP POST requests. The request structure requirements in AE for HTTP POST

messages are well defined, making it easy for user applications to issue requests to the AE.

We have also developed a preliminary programming model called Web Agent Programming

Model (WAPM) that would enable even non-programmers use the functionality of the agent

system. WAPM defines a simple scripting language that can be used to direct and define an

agent's action in a very high-level language. We have adopted HTTP POST as the basic

communication mode to interact with the AE since it is easy to define a request structure using

POST. Also, POST enables us to deal with arbitrarily large data blocks.










3.2 Server Side Components

The server side components consist of the server extension module and the aZIMAS Agent

Environment (AE) (Figure 3-2).


AE Web Content HTTP POST
Provider Messages
From / To Web server Module
I--------------------- 7-----I


Weblnterface
f


Messaging
I Fs-in


AgentEngine
Logger AgentServices Authentication SecurityManager AgentAPI




I NameRegistry Agents Communication Manager

Data Store AgentSpace Resource Controller



Figure 3-2 The aZIMAS Agent Environment (AE)

The server extension module captures HTTP requests that are intended for the AE (identified

by a specific request extension .env) and routes it to AE. aZIMAS AE is a minimal layer

framework that consists of a Messaging and Weblnterface component, an AgentEngine

component, and an AgentSpace component.

The Messaging component acts like a gateway in the AE. It sends and receives messages

between the web server module and the AgentEngine. Weblnterface component acts like a

content publisher. It exposes the functionality of the agent environment through static and

dynamic web pages and provides the World Wide Web interface to the AE.

The AgentEngine provides services like verification of request structure related to agent

messages, and authorization and authentication of incoming messages. The AgentEngine passes

incoming agents to the AgentSpace after verification. The Agent Engine also includes a Logger to

log system activities. The AgentEngine also has an integrated i _/,,, i,,,r to control access

to the Azimas AgentAPI. The AE exposes its services via the Azimas API.










The AgentSpace component forms the heart of the Azimas Agent Architecture. AgentSpace

deals with supporting the lifecycle of an agent directly. It provides all necessary functionality

needed by the agents like migration, agent communication, persistence, etc. On receiving the

agents from AgentEngine, AgentSpace registers them in a Name Registry and then loads their

state/code for execution. AgentSpace keeps track of the various agents in the AE and provides the

interfaces to the Agent API. To some extent, AgentSpace also controls usage of resources like

memory and disk space by agents through a Resource Controller. A Communication Manager

handles message transfer among agents as well as transporting agent packets as HTTP messages

to other hosts. Storage requirements of agents are handled using a Data Store.















CHAPTER 4
AGENTS IN AZIMAS

We define an azimas agent as a program that acts on behalf of an entity, and which has the

ability to move autonomously from one host to another. The entity, which owns the agent

(owner), can be a user, program or an organization. Agents in azimas can only exist within the

context of the AgentSpace in Agent Environment (AE), which provides the functionality

necessary for the agents to operate. In aZIMAS, every agent is associated with a home base,

which refers to the AE at which the agent was first created. For an agent, hosts other than the

home base are referred to as foreign bases. An azimas agent can be described by the following

attributes:

-ID, which uniquely identifies it within an AE
-Home base, the AE at which the agent was first created
-Credentials to prove its authenticity
-Data (like program state and output, itineraries, agent type etc.,) and
-Code that forms the agent program

The attributes of an agent are packaged and represented as an AgentTravelPack when an

agent is transferred between azimas hosts. In aZIMAS, agents are classified as either Interactive

or Non-Interactive:

* Interactive Agents. Agents that have the ability to respond to the activity of their owners,
and possibly other agents. Interactive agents can cooperate with other agents in realizing a
common goal. These agents have the ability for synchronous and asynchronous collaboration
and can be used to build distributed Internet Applications. Interactive agents can optionally
specify AppletContexts, which provides an applet interface for their owners to direct their
actions.

* Non-Interactive Agents. Agents that are primarily concerned with processing information
available at various sources on the Internet. Non-interactive agents are suitable for
information search and filtering applications. These agents have the ability to replicate or
clone themselves. A non-interactive agent and its clones form a group, within which
synchronous and asynchronous communication is possible. Non-interactive agents normally
do not interact with agents outside their group and typically communicate results and
messages to their owners in an asynchronous manner.










Every incoming agent is expected to identify its type (interactive/non-interactive). The

purpose of this classification is to aid the aZIMAS AE in decisions of load balancing. When the

number of agents in the system exceeds a given threshold (available system memory, disk space),

the AE's Resource Controller gets invoked. The Resource Controller typically suspends some

agents to ease the strain on the AE. Usually low priority agent threads get suspended in no

particular order, with preference given to interactive agents and agents belonging to the AE's

domain (home base agents).

4.1 Naming

Naming Service in aZIMAS provides agent location services. It enables one to locate an

agent by using a logical name. Naming service enables us to create an agent in one application

and invoke it using some other application. Both the Agent Environment and Agents are named in

aZIMAS. Name Registry is a lookup service provided in every AE that assists in locating an

agent. Many existing systems like Aglets and Odyssey do not have a Distributed Naming service.

Aglet and Odyssey both have a simple local lookup table that allows one to associate a string with

an agent's URL. Voyager from ObjectSpace supports Distributed Naming. In Voyager, a name is

an ordered pair (URL:port). Once an agent is created it can be referred from any application by

using its logical name, irrespective of where the agent is currently residing.

In aZIMAS, a hierarchical naming scheme is followed. Agents are named after the agent

environment in which they are created. All agents created at a given Agent environment, called

its home AE, have a unique name. This is ensured by using a unique sequence number to each

agent. Sequence numbers generated at a given AE are always in an increasing order (1,2,3...).

However, this does not ensure a globally unique name. To provide a globally unique name, we

can make use of the name of the AE. Thus an agent is referred as an ordered pair (AE

Name,Agent Name). This ensures globally unique agent name.












AE harris:80


Agent 1 Agent 2 Agent 3


Agent 1.1 Agent 1.2 Agent 1.3


Figure 4-1. Agent Naming Hierarchy

By way of example (Figure 4-1), consider an Agent Environment (AE) hosted by the web

server at http://www.harris.cise.ufl.edu:80/. Consider 3 Agents created at this AE. Once they are

registered with the local name server they can be referred locally as Agentl, Agent2, and Agent3.

The fully qualified global name would be:

http://harris.cise.ufl.edu:80/Agentl
http://harris.cise.ufl.edu:80/Agent2
http://harris.cise.ufl.edu:80/Agent3

When an agent creates a clone, the cloned agent is named after the parent agent and follows

the same naming convention as the parent. Thus, ifAgentl has three children, they will be named

Agentl.1, Agentl.2, and Agentl.3. They can be then be referred as:

http://harris.cise.ufl.edu:80/Agent 1.1
http://harris.cise.ufl.edu:80/Agentl.2
http://harris.cise.ufl.edu:80/Agentl.3

Consider the scenario where an agent has migrated from the home base to a foreign base and

later a new agent is created at the home with the same name. Now, the question arises as to

whether this would result in two agents with the same global name. This cannot happen in our

system, because the home base maintains the persistent state of an agent till the agent is disposed

(termination) however long that might take. In the worst case, this might require us to maintain

the state information of thousands of agents in the home base and hence may consume some

storage. The storage costs would be irrelevant since hosting thousands of agents would anyway

require us to have a high-end system. A completely autonomous agent where the agent has no

specific home base is interesting. It would be very difficult to trust any agent in such a model. In










our model, agents are created at a home base, where a user has initially registered. This

registration process provides a means for the host system to ensure that the user meets certain

guidelines and hence can trust future agents created by the user. Hosts do not trust foreign agents

and may not provide them with the same set of privileges that they would for locally created

agents.

4.2 Agent Communication

For cooperation and collaboration between agents to succeed, we need an effective

communication medium. A communication medium facilitates agent interaction with other agents

and its owners. aZIMAS provides support for both synchronous and asynchronous agent

communication. Asynchronous communication is implemented through use of mailboxes. Every

agent is allocated a mailbox, which stores incoming messages for the agent. A message sent by an

agent is stored in the receiver's mailbox. An agent can do a blocking or non-blocking wait for

messages. When an agent blocks waiting for a message, it is notified upon the arrival of a

message. If the agent is non-blocking then it has to explicitly check its mailbox to retrieve the

messages. Synchronous communication is established through a rendezvous point established by

the aZIMAS system. A rendezvous point opens up a connection between two agents in an AE,

through which data transfer is possible. aZIMAS provides limited location transparency support,

made possible through use of a forwarding service provided by every AE. Thus, when an agent

receiving messages in an asynchronous manner chooses to migrate to a new location it will

continue to receive messages at its new location.

4.3 Event Management

aZIMAS uses a type of publisher-subscriber model for event management. In this model, a

publisher acts as an event generator. Subscribers receive events generated by publishers. An event

manager facilitates event management and acts as the deliverer of events to the subscribers.

Publishers register themselves with the event manager and deliver events to it. Agents can query

the event manager for available publishers and can subscribe to specific publishers. An agent can










act as both a publisher and a subscriber simultaneously. A subscriber in an aZIMAS AE will

continue to receive event notification even after it has moved to a different host. Events are Java

objects in aZIMAS, which provide a general description of the event along with its details.

4.4 Mobility and Agent Persistence

Mobile agents, by their very nature, need to have the ability to move from one host to

another. aZIMAS supports only weak migration for Agents. In weak migration, only the code and

state of the agent is transferred as opposed to strong migration, where the execution state is

transferred. Attempts have been made to provide for strong migration (Bouchenak 1999) by either

extending the Java Virtual Machine or by capturing the execution state through use of a backup

object. Though strong migration has a number of positive aspects, the high overhead introduced

by these techniques makes it unattractive to our cause. In aZIMAS, agent migration is handled by

the AE. An agent issues a migration request through a move method call. The move method when

invoked never returns and takes an itinerary string as a parameter. An itinerary string is an

ordered triplet (destination host: method: parameter), indicating the destination host to which the

agent wishes to migrate, the method to be invoked upon arrival at the destination along with

parameters that needs to be passed to the method. As of now, only simple parameters like strings

and primitive types can be passed as method parameters. Agents are passive participants in the

migration process and cannot react to events that take place during migration. However, when

migration fails we invoke the process () method on the agent object. This gives the agent a

chance to decide whether it wants to move to a different host or try migration later on. This is

possible because when a move () is invoked, only the agent execution is stopped, the agent object

is not destroyed. The state of the agent is preserved in an AE until an agent migrates or

terminates.

Agent persistence is supported through use of Java's serialization mechanism. An agent's

state and code, once serialized, persist physically at the home base. At foreign bases, serialized

agent state and code is maintained only in memory. The agent's home base always keeps track of










the location information of all agents belonging to its domain (home agents). This is made

possible by an update to the location information at the home base whenever the agent moves

between hosts. When an AE receives a foreign agent it sends the agent's home base AE a status

message indicating the agent's new location.

4.5 Security

A mobile agent system needs to define proper security framework before it can be trusted

and deployed widely since they often will have to execute arbitrary code from unknown agents.

In addition to the security issues related to the agents in general, new issues arise when mobile

agents are deployed on the web. Fortunately, dealing with web security is not as hard as that of

agent security and acceptable solution exists to many problems (Gritzalis and Spinellis 1997). To

prevent unauthorized web use, aZIMAS AE requires each user to follow a registration process

before being allowed to access agent services. This enables the AE to identify each request with

a specific aZIMAS user. Since HTTP is a plain-text protocol it is possible for snoopers to gain

access to confidential information. Use of secure HTTP where possible should eliminate this

problem. It should be noted that in the current system no provision has been made to share user

information across AE's. Thus, a user registered at a particular AE can use services of other AE's

only indirectly through use of agent programs. To make registration information common across

AEs, one can adopt a central registration server. A detailed analysis of security issues in agent

systems in provided in (Jansen and Karygiannis 1999).

Broadly, there are three main classes of threats in agent systems:

1. Agent-to-Platform. The agent exploits weakness in the agent system to gain unauthorized
access to resources, or otherwise launch attacks on the agent system. Numerous techniques
have been developed to protect an agent system from harmful agents like safe code
interpretation, signed code, proof carrying code, state appraisal etc.,

2. Platform-to-Agent. This category of threats represents situations in which the agent's
security is compromised by attacks from the agent system. Preventing this type of attack is
generally difficult since the agent system controls the execution environment of an agent.
There are some techniques to prevent attacks from the agent system, but they tend to fall
more towards detection that prevention.










3. Agent-to-Agent. In this category, an agent launches an attack against another agent possibly
exploiting security weakness of the other agent. These types of attacks can usually be tackled
using the same techniques that are employed for protecting the Agent platform.

The current system does not have any provision to prevent attacks by the platform. We

assume that aZIMAS AEs are hosts trusted by the agents. To prevent attacks by the agents,

aZIMAS employs a combination of techniques. Every agent is expected to carry credentials

identifying its owner and the home base. As like many other agent systems, aZIMAS makes use

of Java's inbuilt security mechanisms to prevent runtime attacks by providing a Security Manager

that controls access to potentially harmful system libraries. aZIMAS offers some security features

to prevent agent-to-agent attacks. This includes agent blocking, in which an agent can block

messages from another agent to it by requesting the AE.


















CHAPTER 5
USAGE

In this chapter, we describe how users can use the services of the aZIMAS Agent

Environment. We first describe how user interaction with AE takes place and show how to write

a simple agent. We outline how the sequence of events that take place inside the AE to process

agent requests. Finally, we describe two agent applications developed using our agent API.

5.1 User Interaction with AE


Ij.l.= td, _,- i :.,lc. i:.-l. 'II: Im
4 -Back' e I O Sch (Favoetes IJMedia I L g R a 0
APddes I http //www harris cise ufl edu 8080/azimas env jl PGo


Create Agent I Output/Status
Welcome bill!
To create an agent, please specify a name for the agent, specify the name of the
agent class file, the type of the agent, and the location where the agent class file is located.

Activity IcreateAgent l
AgentName Ispider
AgentFileName [Spider
AgentType I Non-interactive j
AgentFile IC\agents\Spider class Browse...

SubmitAgent



home I re ort I links I hel I


Figure 5-1. Agent Environment (AE) Web Interface

Users interact with the AE through means of a web-based interface. Users need to be


registered with a particular aZIMAS AE before they can send agents to that AE. The


registration process allows a user to choose a name and password, and also obtains details


system and would see an interface similar to one shown in Figure 5-1, which lists various


such as the user's email address. Once a login has been created the user can login to the










options. To create an agent, the user selects the createAgent option, provides a Logical

name for the agent, and also specifies the location of the compiled agent class file. Finally,

the user submits the agent to the Agent Environment (AE). Details on how the AE processes

the request is provided in the request processing section at the end of this chapter.

5.2 Writing Agent Programs

To allow users to create their own agents, aZIMAS provides a development package. Agent

programmers need to download this package locally to their machine. The package includes two

important java classes: a basic agent class called Azimas, as well as a class called AzimasAPI,

which includes all methods that are available for agents to use in an AE. In order to write an

agent, one needs to create a java program that extends the abstract base agent class Azimas. The

base agent class Azimas provides a number of useful methods that implement functionality that is

useful to all agents in aZIMAS. The Azimas class defines two abstract methods, run() and

process ().

//agent execution starts in run
public abstract void run();
//messages received to the agent are delivered to the process method
public abstract Object process(Object o);


A class that extends the base agent class Azimas must implement both the run() and the

process() method. The AE executes an agent by invoking the run() method on it. The

process () method is used by the AE to deliver messages sent to the agent. The messages might

be from other agents or requests from the users of the agent. It is entirely up to the agent to decide

how to structure the run () and process () methods. aZIMAS also provides a data store for every

agent. The data store allows an agent to store and retrieve any generic java object. An agent can

access the data store by invoking the store and retrieve method calls present in the AzimasAPI.

When an agent migrates, the AE automatically ships the data store along with the agent. The











AgentSpace module in the AE manages the data store. As an example, the code for a simple agent

program is shown below the agent retrieves content from a user specified URL.



public class SimpleAgent extends Azimas


public void run() { }


public Object process(Object o)


String request = (String)o;
Object resObj = null;


if(request.equals("visit")) { //visit a user specified website
String site = retrieve(this,"site");
String email = retrieve(this,"email");
AzimasAPI.getURLNoTags(this,site,"data");
resObj = retrieve("data");


else { //starting page..display html
String html = "
";
html = "Site to Visit:
";
html = "Email Address:
";
html = html + AzimasAPI.includeAuthHTML(this);
html = "";
html = "
";
resObj = (String)AzimasAPI.applyHTMLTemplate(html);


return resObj;


If no specific request is issued, but the agent is just accessed by the user from the web (by

selecting from a list of agents displays by the AE), then the agent just returns some formatted

HTML code. The HTML code serves like the index page for the agent. It encodes authorization

information as hidden tags (these codes are generated by the AE and are accessed by the agent by

a call to the includeAuthHTML () in AzimasAPI). When the user fills out the fields and submits

the form, the AE receives the form-data. It first parses submitted form data and stores the name,

value pairs in the data store for easy access to the agent. It then invokes the process () method of










the agent. The agent retrieves contents of the site mentioned by the user and filters it to extract

only plain-text and returns the result back. This agent merely reacts to user-triggered events and

does not do any specific startup initializations in the run () method. All events are delivered to an

agent's process () method.

5.3 Request Processing in the AE

This section explains how an AE processes requests received from the web from users. The

AE exposes its services to the user through web pages served by the Weblnterface module. Agent

requests are identified by an extension .env associated with them. When a user types an URL

with an extension .env, they are captured and forwarded to the AE by the server extension

module. The web server's server extension module captures the request and passes it on to the

Messaging component of the Agent Environment (AE). The user is informed about the successful

transmission of request and provided a link to query about the agent's status, and output. The

status page provides information about the current location of the agent, its trust level etc. After

eliminating HTTP headers, the Messaging component transfers control to the AgentEngine.

Verification of the client's request structure takes place in the AgentEngine. If verification is

successful, the AgentEngiwn passes the request to the AgentSpace for further processing.

A valid HTTP POST request intended for the AE needs to be in conformance to the request

structure expectations of the AE. A requestType is a basic field that needs to be present in all

messages directed to the aZIMAS AE. It helps the AE in deciding how to process a request.

Depending on the type of the request, the AE may expect additional fields. For example, a

message containing agent code is handled differently based on the request type:

If the request type is createAgent, it implies that a new agent needs to be created at the

AE. The AE stores the code of the agent in a separate folder created for the user. The code is then

loaded and the agent execution begins, provided necessary resources are available. The AE

expects the following fields properly completed in the HTTP request: userName,

userAuth, agentName, agentType, agentFileName, agentFile.












If the request type is agent Pack, the AE interprets it as a request that contains a bundled


agent from a different AE. The AE allocates only temporary space for the agent under a


visitors folder. The AE receiving an agentPack also informs the home AE about the


successful migration and then restores the state of the visiting agent.


The request structure expectations are well defined in aZIMAS. This enables user


applications to access aZIMAS services by following the correct request structure. An example


POST request illustrating a createAgent request is shown below.

--------------------------- -30881262316024
Content-Disposition: form-data; name="requestType"
createAgent
--------------------------- -30881262316024
Content-Disposition: form-data; name="agentName"
Spider
--------------------------- -30881262316024
Content-Disposition: form-data; name="agentType"
Non-Interactive
--------------------------- -30881262316024
Content-Disposition: form-data; name="userName"
bill
--------------------------- -30881262316024
Content-Disposition: form-data; name="userAuth"
74VTJFYlcQORQ5lhUo3qupW7no52yNA7iK5gVRU
--------------------------- -30881262316024
Content-Disposition: form-data; name="agentFile"; filename="Spider.class"
[......
Class Bytes
......]
----------------------------30881262316024-


5.4 Application Scenarios


In this section, we describe two agent applications. We first introduce Spider a


WebCrawler agent that can be used to index, and archive websites. Next, we describe YoYo an


agent that can be used to process, filter, and synthesize information from various websites.


5.4.1 Spider Mobile Web Crawler Agent


Spider is a Mobile web crawler that can be used to index and archive entire websites. The


agent is first uploaded to an aZIMAS enabled web server from a web browser. Given a domain to


start with (hereafter called simply, crawldomain), spider first determines whether the domain


has an aZIMAS enabled web server. If the crawldomain has agent capabilities', then spider


moves to the remote server. The Agent Environment at the crawl domain's web server receives




1 Agent-enabled/capable server refers to a web server enhanced with aZIMAS Agent Environment (AE)











spider and spider continues its crawling process there. At the crawldomain web server, spider

then moves to the Agent Environment at crawldomain web server and starts the crawling

process from there. If the crawldomain does not host an agent system, then spider accesses the

crawldomain remotely through HTTP connections. Figure 5-2 outlines the steps in the crawl

process.


Spider Mobile Crawler Algorithm

1. User uploads spider to an AE residing at http://www.cise.ufl.edu (CISE) and specifies the domain to crawl
as http://www.harris.cise.ufl.edu (HARRIS) and defines LIMIT the number of links to follow or amount of
data to mine
2. Spider determines whether HARRIS is agent-enabled.
3. HARRIS is not agent-enabled. Crawling of the crawldomain must be done remotely from the current AE. Go
to Step 6
4. HARRIS is agent-enabled. Spider moves to HARRIS
5. The AE at HARRIS receives spider and loads it in its AgentSpace where spider starts executing
6. Start a breadth-first traversal of the crawldomain starting at the root domain. Collect links in the root
document and store it in LIST
7. For each unvisited link in the LIST, retrieve the document indicated by the link and store the contents of the
document in the DataStore
8. Add links found in the new document to LIST. If LIMIT has not yet been reached go back to step 7
9. If the user has specified an email address, mail the results back to the user
10. If necessary move back to the home AE. Stop
Figure 5-2. Spider Mobile Web Crawler Algorithm

Spider's crawling process is just like any other web crawler it does a breadth-first traversal

of the crawldomain by starting at the root document and recursively follows the links in the

document. The documents retrieved during the crawling process can be archived using the

AzimasStorageManager. By default, crawling is limited to a user-specified domain. Crawling can

also be controlled by other parameters like amount of data to be mined, or number of links to

visit etcetera. During the crawling process, spider also collects a wealth of information like

broken links, document access errors, and link referrals. The collected information can be

valuable in web site diagnostics and maintenance. Figure 5-3 shows the initial interface. A simple

search engine can be easily implemented on top of the collected data repository. Such a search

engine can take advantage of the indexes built by the spider.











File Edit View Favorites Tools Help
-Back 40 Q a:"^ Favorites rJ".u a 1' % a a
Address http://wwwharris.cise.ufl.edu.8080/Spider.env

[--- <, .. ,--.1 L .-,I / -- .-v^ L... I / "I"--',-, I L---', L--". / -1-'- I ---':..'tJ.---- / L--', I

Spider: WebCrawler Agent
About Soider I How it works?
1-~ there! Interested in some website diagnostics?
S Enter a website and your email(optional) below to :
S\ + See the map of the website (Web Graph)
1 -+ Identify broken links t
+ Mine all email addresses "
-- + Get top 10 links in the site and much more...

Website to crawl
-- + [J Your Email+ i-

Submit Request I


''*"^^ '^--------------------------------"^






a recursive search of a spee b Cr page and all the links in it in real time. By its nature the
For a given search string or keyword, a lightweight version of spider can be used to perform

a recursive search of a specific web page and all the links in it in real time. By its nature the

spider agent is a data-intensive application. The spider approach achieves bandwidth efficiency

when spider resides in a domain different from the crawldomain and the crawldomain has

an aZIMAS-enabled server.

5.4.2 YoYo Information Synthesizer

YoYo is an example of a typical information-processing agent. YoYo accesses content from

various websites, then filters and transforms it to a form desired by the user. One typical data

transformation function is to extract plain text from a web page, filtering out tags and other media

objects. Using YoYo, users can integrate desired information from various websites. With YoYo

the user has full control over the data source from which the information is retrieved. In the web,

there are many websites that perform domain specific synthesis of information (Google News at

news.google.com composes news headlines from various websites).










We have used YoYo to compose information related to movies from various sites. YoYo can

answer queries like "Given the title of a movie M and the local zip code, retrieve the following -

information about the movie (like cast, genre etc.), reviews for the movie, show times of the

movie in the local city, and finally some links related to the movie". To answer this query, YoYo

uses three Internet databases. It uses the Internet Movie Database (www.imdb.com) to obtain

information about the movie, then it accesses the Movie Review Query Engine (www.mrqe.com)

to obtain a list of reviews for the movie, Next it accesses Yahoo Movie Showtime Engine

(movies.yahoo.com/showtimes) to obtain show time listings for theaters in the user's zip code

locality, and finally it accesses Netscape's Google search service (search.netscape.com) to obtain

a list of links related to the movie. YoYo filters the data collected from the various sites to

remove tags and other irrelevant information to obtain a neat summary. The synthesized

information is then displayed to the user.















CHAPTER 6
IMPLEMENTATION AND PERFORMANCE

In this chapter, we first give a brief sketch of our implementation. We then present some

preliminary performance results about the impact on the web server due to the presence of our

agent component.

6.1 Implementation

We have implemented most of the framework that has been described in the earlier chapters.

Our implementation is in Java and uses the JDK 1.2. We have developed the basic agent

environment component, which supports the lifecycle of the agents. We have implemented a

server extension module for the popular Apache Web server. As part of our work, we have also

developed a simple web server called Pluto, which interfaces with the AE. Pluto makes it easy to

see the project in action even on systems with no installed web servers. The Agent Environment

is implemented using Java. Java provides a number of features useful to agent systems like

serialization mechanism, on-demand code loading, relatively strong security framework etc.,

which makes it an excellent language to base an agent system upon. Some popular agent systems

based on Java [9] include Aglets, Concordia, Voyager, Odyssey, Ajanta etc. The web server

dictates the choice of language for the server extension module. In our implementation of the

apache module, we have used the C language.

The core of the system is accommodated in five Java classes: AzimasMessaging,

AzimasWeb, AzimasAgentEngine, AzimasAgentSpace, and Azimas-

SecurityManager. The implementation is modeled according to the aZIMAS design

described in chapter 3.

All aZIMAS agents are derived from a basic agent class called Azimas, which helps

enforce certain minimum guidelines for the agent programs. Agents are represented as threads in










the AE. The base agent class has an attribute called AzimasSpaceInterface, which needs to

be set by the Agent Environment. This is a Java object by means of which the agent accesses

many services from the AE. To facilitate invocation as a thread, the system mandates that the

agents provide a run () method, from where the agent code normally starts executing. Apart

from these requirements, the AE's S /(vin ,,, constrains the agent programs to make calls

only to safe library methods.

The aZIMAS API provides a safe way to access many useful functions. The method names

model closely after the Java library convention. For example, to invoke a request to an external

URL the agent just needs to make a call to the getLocation method, which takes an URL

string as a parameter. The method call if successful returns the data retrieved from the URL.

6.2 Performance Evaluation

In this section, we present some of the performance results obtained after deploying our AE

on Apache web server. The performance of a web server is critical and should not be adversely

affected by the presence of additional components. We carried out our simulation by sending

HTTP requests at a gradually increasing rate using OpenLoad, a command line tool that can be

used to test web server performance.

Figure 6-1 shows the affect on the response time of the web server for various cases. The

base case represents the situation when no agents were present in the AE. The second case

represents the situation when 10 non-resource intensive agents were present in the AE. These

agents typically accessed some site on the Internet and communicated the result back to their

owners. Since we expect this type of agents to be more common on the web, we call them as

typical web agents. The agents were uploaded in to the AE from a web browser and the base test

case is repeated. From Figure 6-1, we can observe that there is only a negligible difference in the

response time of the web server due to the presence of typical web agents, this is due to the fact

that these agents did not make use of excessive CPU or system memory.











No Agents in
5 the AE
S4
-A-10 typical
3 -J agents

2
---- 2-3 resource
S1 intensive
C agents
S0 .. .. .. _---- 10 resource
0 5 10 20 30 40 50 60 70 80 90 intensive
Number of Clients agents


Figure 6-1. Impact on web server's response time

However, when resource intensive agents were uploaded to the AE, we could observe a

noticeable difference in the response time. The effect is very obvious when we repeated the base

test case with 10 resource intensive agents in the AE. The response time of the web server

worsened by as much as 30 percent! Resource intensive agents, in this case, performed the

computation of an N x N matrix multiplication where N = 300. The drastic change in response

time occurs due to the fact that resource intensive agents take up much of the available CPU time

thus affecting the web server processes.

We observed a similar drop in available system memory when resource intensive agents

were present in the AE (Figure 6-2). This effect is however easier to control than the previous one

as it is easy for the AE's Resource Controller to make sure that the memory used by agent

programs does not exceed the threshold set by the AE. Though there is only a negligible impact

on the web server when typical agents were present, it is not advisable to co-locate the AE and a

busy web server on the same machine. This is due to the fact that it is often not possible to know

beforehand whether an agent is resource intensive or not.











No agents in
m 60 the AE
50
S40 -A-- 10 typical
3 agents
E 30
S20 2-3 resource
310 intensive
agents
0
< 0 5 10 20 30 40 50 60 70 80 90 --lOresource
intensive
Number of clients agents



Figure 6-2. Impact on available system memory

In our opinion, it is best if the AE is maintained in a machine different from the web server.

To test this scenario, we repeated our simulation with the web server and AE located on different

machines in the same network and subjecting the AE to large number of resource intensive

agents. As expected, the response time of the web server was similar to the base (no agents) case

and the performance implications were felt only in the machine where the AE was located.















CHAPTER 7
CONCLUSION

In this paper we described aZIMAS, a novel framework that realizes mobile agent systems

within the context of the World Wide Web. The approach interfaces the agent system (Agent

Environment) with web servers through means of a minimal server specific extension module and

makes use of web browsers as clients. By making only the extension module as server specific it

is possible to deploy the agent system uniformly in a wide variety of web servers. Our framework

provides a reasonably secure environment for mobile agents to function on the Web.

A significant limitation for Internet agents today is the lack of machine processable

information on the web. The current web is mainly designed for human user and lacks machine

processable structure and semantics. However, with the advent of XML and web services more

and more structured information is being made available on the web. Efforts are also underway to

annotate web pages with semantics using technologies like Resource Description Framework

(RDF). The next generation web is envisioned to be a semantic web (Berners-Lee et al 2001). All

these developments make the future of Internet agent systems bright and more promising.

We are working on making the Azimas Agent API richer and better. One other area of

interest is realizing aZIMAS agents as providers of web services.















APPENDIX A
AZIMAS AGENT ENVIRONMENT MODULES


This appendix describes the various modules of the azimas system briefly. The Azimas
Agent Environment is made up of the following modules (the actual module name
indicated in parenthesis).

1. Azimas Messaging (AzimaMessaging)
2. Authentication, Registration, and Code Verification (Azimalnterface)
3. Name/Service Registry (AzimaRegistry)
4. Core Agent Services / Access Control (AzimaServices)
5. Agent Web Interface (AzimaWeb)
6. Agent Space (AzimaAgentspace)
7. Data Storage Interface (AzimaDataInterface)
8. Logger (AzimaLogger)
9. Azimas Database (AzimaStorageDatabase)


1. AzimaMessaging

Synopsis: The entry/exit point for agents in the Azimas system.

--Receives mobile agents from the apache web server and passes it to the Azimalnterface
Module
--Receives mobile agents from the Azimalnterface Module and sends it to the agent's
destination. The agent's destination must be another azima integrated apache web server.

Allows: Azimalnterface
Uses: Azimalnterface

2. Azimalnterface

Synopsis: Verifies the agent's credentials, Verifies the agent's code. If the agent passes
verification, then

--determines privileges that can be allowed for the agent
--allocates data space for the agent,
--registers the agent and its privileges in the Name Registry
--facilitates web access of the agent and its data space by providing appropriate interfaces (calls
AzimaWeb to achieve this)
-- transfers agent code and state to AzimaAgentSpace

Allows: AzimaMessaging, AzimaServices
Uses: AzimaServices, AzimaAgentSpace, AzimaLogger











3. AzimaRegistry

Synopsis: Provides a NameRegistry and ServiceRegistry.

--provides convenient storage tables called lists, which can be used by other modules.
--NameRegistry keeps track of various agents along with their privileges.
--ServiceRegistry keeps track of the services offered by the agents in the system.

Allows:*AgentServer*1
Uses:*AgentServer* (datainterface to backup copies)

4. AzimaServices

Synopsis: The Azima API (Application Programming Interface).

--API is a list of methods provided by the Azima Agent Environment available for agents to
use. In addition to many useful methods, Azima API provides special methods to support agent
collaboration (like clone, merge, synchronize). Call to any API method is controlled by an Access
Control layer, which determines whether an agent has sufficient privilege to use the API.

Allows:AzimaAgentSpace,*AgentServer*
Uses:AzimaWeb,AzimaLogger,*AgentServer*

5. AzimaWeb

Synopsis: AzimaWeb facilitates web access of the agent and the agent's data space.

--Only the owner of the agent can access the agent. Provides suitable web authentication for this
purpose. The web interface allows the owner of the agent to control the agent's behavior.

Allows: *AgentServer*
Uses: None

6. AzimaAgentSpace

Synopsis: Responsible for loading the code of an agent in memory along with its state and
starting the agent's execution.

--The agent code and state is obtained by a call to the AzimaDataInterface. Each agent is
allocated a thread before its state and code is loaded into the memory. An agent can start
executing when AzimaAgentSpace starts the thread allocated to the agent. All agent threads run
under the control of a main thread called azimaThread owned by the AzimasAgentSpace module.
More than one azimaThread can exist in the Agent Space. Performs load balancing tasks within
the agent space through operations on agent threads like suspend, resume etc.,



1 References to *AgentServer* should be read as referring to the following modules that are
present in the Azimas Agent Sever, i.e. Azimalnterface, AzimaServices, AzimaDataInterface










Allows: *AgentServer*
Uses:AzimaServices


7. AzimaDatalnterface

Synopsis: Handles all storage needs of agents.

--provides methods to create, modify, and delete storage spaces. Handles serialization and
deserialization of agent states. Provides methods to perform variety of data processing on files.
Provides a logical view of stored data. Actual storage handled by the lower level
AzimaStorageDatabase.

Allows: All except AzimaAgentSpace
Uses: AzimasStorageDatabase

8. AzimaStorageDatabase

Synopsis: Stores files in a suitable physical format.

--supports only a flat-file system.

Allows: AzimaDatalnterface
Uses: None

9. AzimaLogger

Synopsis: Maintains system and agent logs.

--All agent requests are logged in the agent logs. All Agent Server operations are logged in the
system log. A special migration log maintains agent entry and exit records.

Allows: All modules except AzimaAgentSpace
Uses: AzimaDataInterface















APPENDIX B
SERVLET-BASED APPROACH

In aZIMAS, the Agent Environment (AE) is glued to the web server through means of a
server module. The functionality of the module can also be implemented using servlets. In this
appendix we provide a brief overview of servlets, and explain how the AE can be deployed using
servlets.

Servlets:

Servlets (Sun 2002) provide a component-based, platform-independent method for building web-
based applications, without the performance limitations of CGI programs. Servlets provide web
developers with a simple, consistent mechanism for extending the functionality of a Web server
and for accessing existing business systems. Containers, some times called servlet engines, are
web server extensions that provide servlet functionality. Servlets can interact with web clients via
a request/response paradigm implemented by the servlet container. A servlet container can be
built into a host web server or installed as an add-on component on the Web Server via that
server's native extension API. All servlet containers provide support for the HTTP protocol.
Additional protocols like HTTPS (HTTP over SSL) may be supported.

In functionality, servlets lie somewhere between the Common Gateway Interface (CGI) programs
and proprietary server extensions such as Apache Modules, Netscape Server API (NSAPI), or
Microsoft's IIS ISAPI extensions. Compared to other server extension mechanisms, servlets have
the following advantages:

1. They are generally much faster than CGI scripts because a different process model is
used

2. They use a standard API that is supported by many web servers

3. They have all the advantages of the Java programming language, including ease of
deployment and platform independence

4. They can access a large set of APIs available for the Java platform

Implementing the server module as a servlet:

The minimal-server module employed in aZIMAS can be easily realized as a servlet. A servlet
(e.g. AzimasInterfaceServlet) can be developed that routes requests from the web server to the
agent environment. Below, we summarize the sequence of operations that would be needed to
route a request between a web client and the agent environment in a servlet-based approach:

1. A client (e.g. a web browser) accesses a web server and makes an agent-related HTTP request

2. The request is received by the web server and handed off to the servlet container (servlet
engine)







36


3. The servlet engine invokes the AzimasInterfaceServlet and passes the request and
response objects to it. The request object contains such information like the remote user who
issued the request, HTTP POST parameters sent as part of the request and other relevant data

4. The AzimasInterfaceServlet passes the request object to the AE's messaging module and
waits for a response

5. The AE processes the request object and sends a suitable reply to the
AzimasInterfaceServlet

6. The AzimasInterfaceServlet then sends this data back to the client via the response object

The benefit of adopting a servlet-based approach would be that the AE could be deployed
uniformly on any web server that supports servlet technology. In the current approach, the server
module is web-server specific.












LIST OF REFERENCES


Bemers-Lee T, Hendler J, Lassila O. The Semantic Web, Scientific American, May 2001

Bouchenak S. Pickling threads state in the Java system. Third European Research Seminar on
Advances in Distributed Systems (ERSADS), Madeira Island, Portugal, 1999

Funfrocken, S. How to integrate mobile agents into Web Servers, Proceedings of the 6th
Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises, pages 100-
106, IEEE Computer Press, Cambridge MA, 1997

Gritzalis S, Spinellis D. Addressing threats and security issues in World Wide Web
technology, Proceedings of 3rd IFIP TC6/TC11 International joint working Conference on
Communications and Multimedia Security, pages 33-46, Chapman and Hall, Athens Greece,
1997

Goddard T, Sunderam V.S. WebVector: Agents With URLs, Proceedings of the 6th
Workshop on Enabling Technologies Infrastructure for Collaborative Enterprises, pages 100-
106, IEEE Computer Press, Cambridge MA, 1997

Horvat D, Cvetkovic D, Milutinovic V. Mobile Agents and Java Mobile Agents Toolkits,
Proceedings of the 33rd Hawaii International Conference on System Sciences Volume
8,pages 29-39, IEEE Computer Press, Hawaii, 1998

Jansen W, Karygiannis T. Mobile Agent Security, National Institute of Standards and
Technology--Special Publication 800-19, August 1999

Lingnau A, Drobnik O, Peter. An HTTP-based Infrastructure for Mobile Agents, Proceedings
of the 4th International WWW Conference, pages 461-471, O'Reilly and Associates, Boston
MA, 1995

Marques P, Fonseca R, Sim6es P, Silva L, Silva J. Integrating Mobile Agents into Off-the-
Shelf Web Servers: The M&M Approach, Proceedings of the International Workshop on
Intemet Bots: Systems and Applications, IEEE Computer Press, Munich, Germany, 2001

Nalla A, Helal A, Renganarayanan V. aZIMAs: Almost Zero Infrastructure Mobile Agents
System, Proceedings of the IEEE Wireless Communications and Networking Conference,
IEEE Computer Press, Orlando FL, 2002

Stroud F. Intemet Agents, CWSApps, URL: http://cws.intemet.com/agents.html Accessed on
12th December 2002

Sun Microsystems, Servlet Specification 2.4, URL: http://java.sun.com/servlets/ Accessed on
12th December 2002
















BIOGRAPHICAL SKETCH

Subramanian Arumugam was born in Madras (Chennai), India. He finished his high

school from M.Ct.M, Madras. He joined SVCE for his undergraduate work and received his

bachelor's degree in information technology from the University of Madras in May 2000. Since

then he has been a graduate student in the Computer Science Department at the University of

Florida.