3. MOTIVATING EXAMPLE

Transcription

1 Using ECA Rules to Implement Mobile Query Agents for Fast-Evolving Pure P2P Database Systems Verena Kantere, Aris Tsois Knowledge and Database Systems Laboratory, School of Electrical and Computer Engineering, National Technical University of Athens Iroon Polytexneiou 9,15780 Zografou, Greece Tel {verena, ABSTRACT A challenging issue in fast-evolving pure P2P networks is the design of an appropriate mechanism for processing queries. Since both the data content of the peers as well as their acquaintances, change rapidly the typical P2P querying techniques become inappropriate. We are interested in P2P networks where peers are mobile and own a database. In this dynamic context the usage of a Mobile Agent framework appears very promising. The paper investigates the issues related to the above problem and proposes a P2P and Mobile Agent architecture based on Active Database technology. We argue that, the employment of ECA rules both for answering queries and deploying agents leads to an efficient as well as simple query processing technique. Furthermore, the proposed mobile agent system architecture offers a number of advantages due to the performance and scalability that can be achieved using Active Databases. Categories and Subject Descriptors H.3.3 [Information Search and Retrieval]: Query formulation, Retrieval Models General Terms Design. Keywords P2P Systems, Mobile Databases, Mobile Agents, ECA model 1. INTRODUCTION One of the recent trends in information exchange is the P2P paradigm. P2P systems are popular because they allow information exchange in an ad-hoc manner and without centralized supervision. Such characteristics appear beneficial to communities of mobile users that would like to share information MDM Ayia Napa Cyprus (c) 2005 ACM /05/05...$5.00 Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. of common interest. A pure P2P system that serves mobile users would naturally be based on wireless communication among peers (users) that are physically close to each other. In such a case the motion of the peers would constantly modify the topology of the P2P network and possibly their data content. In this paper we deal with such mobile-peer-to-mobile-peer systems or any other P2P system that is fast-evolving in both its network topology and the content of the peers. A challenging issue for such P2P systems is to design an appropriate mechanism for processing queries. In this dynamic context the usage of a Mobile Agent framework appears very promising [1], [2]. Querying fastevolving P2P systems comprises principally searching in the P2P network for the appropriate peers that have access to the required information. Mobile agents can encapsulate both the query as well as the algorithm used to obtain the answers, i.e. the searching strategy. Using a predefined search strategy for all types of queries would be restrictive and probably inefficient. Furthermore, mobile agents can deal with the heterogeneity of the involved peers, and provide a more robust and flexible solution. For example, answering continuous queries, and not just simple queries, can be implemented using mobile agents without modifying the P2P system. The particular characteristics of the query can be encapsulated within the agent and the P2P system need not have special mechanisms for each query type. When mobile agents are used in a fast-evolving P2P system there are several performance and scalability issues that come into play. The peers of the system are expected to host, execute and exchange a large number of mobile agents. However, each of these agents performs simple data oriented actions. Due to these characteristics we argue that the Active Database technology can be efficiently employed. This leads to the designation of a P2P system architecture that uses an active database component and a mobile agent structure that is based on Event-Condition-Action (ECA) rules. According to this architecture the mobile agents are executed within the active database of each peer. ECA rules are the dominant mechanism used in active databases to define and implement application logic but, to the best of our knowledge, this is the first effort to use them for the implementation of mobile agents. We argue that the proposed approach leads to an efficient handling of mobile agents and a viable solution for querying fastevolving P2P systems: a problem still to be solved. Although we are discussing only mobile query agents, i.e. agents that are responsible for information retrieval, our approach can easily be extended to any other type of mobile agent. The fact that we are

2 using ECA rules to define mobile agents does not restrict the functionality of the agent: i.e. the action part of the ECA rules can be allowed to contain arbitrary functions. Thus, the usage of ECA rules is just a framework through which the agent s logic, or at least some part of it, is defined in a declarative data-oriented way. The events that can trigger the activation of some agent s function are clearly stated in the event part of the corresponding rule while the condition part defines additional requirements for the function to be activated. This declarative way influences positively a number of aspects of the system like optimization opportunities, efficiency, scalability, portability and security. The remainder of this paper is organized as follows. In section 2 we review related work. In section 3 we give a motivating example of a fast-evolving P2P system. In section 4 we present the characteristics of the problem and discuss various solutions. Then, in section 5 we present the proposed P2P system architecture and elaborate on the internal structure of the mobile agents. Finally, section 6 discuses how the proposed solution can be used for the motivating example of section 3 and section 7 conclude the paper. 2. RELATED WORK Since the P2P paradigm became popular at the end of the 90 s, researchers have addressed the problem of efficient query processing in this context and have invested mainly in constructing techniques for routing queries and disseminating data [3], [4], [5], [6] etc. Additionally, some projects [7], [8] have dealt with management issues of structured data, like heterogeneity and coordination of data sharing. Nevertheless, the processing of continuous queries has not been extensively considered in the P2P model of computing. Three of the few projects that have tackled this issue are PeerCQ [9], Scribe [10], P2P-Diet [11]. All of them and especially the last two are inspired from the publish/subscribe paradigm and develop profile and subscription matching techniques in a P2P system. However, none of them considers the possible need for constant propagation of continuous queries in a pure P2P network. Mobile agents seem to be an appropriate encapsulation for continuous queries or even simple queries in a P2P environment. The suitability of mobile agents for query performance and organization of nodes in the P2P context has been supported by various works including [1]. In [2] the authors argue that mobileagents represent a general framework that can improve not only the efficiency but also make the distributed information retrieval more robust and easy to implement. The well-known project BestPeer [12] uses mobile agents in order to achieve personalization of replies to information requests. The Swan project [13] based on the Diet platform [14] benefits from inherent characteristics of mobile agents such as autonomy and self-deployment in order to form peer communities. Furthermore, Anthill [15] is another effort to build a P2P framework that utilizes the mobile agent paradigm. In an Anthill implementation specific middleware nodes produce agents-ants that are sent to accumulate requested information. In [16] the authors use mobile agents to get the relevant data from various sources, in order to evaluate complex queries. The authors demonstrate how mobile agents can be used to reduce the network traffic through local processing and argue that mobile agents allow the involved nodes to preserve their autonomy. Finally [17] demonstrates, once more, that the mobile agent approach is applicable and is, at least, not worse than other centralized approaches. The inherent similarity of agents and active rules was observed in the middle-90s and discussion was raised [18] in order to explore the profits of using agents versus active databases (adbms) [19]. In the past decade the research in the field of adbmss proposed many mechanisms [20] based on active rules that aimed to the specification and monitoring of database constraints, compute derived data, support materialized views, restrict data access, accumulate statistics, etc. The most common form of active rules used is the widely known ECA form. However, except some works that exploit the ECA definition for the design of agent languages [21], [22], we are not aware of any effort for combining agents with adbmss technology. We employ the ECA functionality in order to implement mobile query agents. For that we rely on a centralized adbms that stores the pertinent data. The applicability of mobile agents on small devices, like PDAs, is shortly addressed in [23]. Our ECA-rules approach offers an alternative architecture for using mobile agents on small devices. This is because very lightweight rule engines on tiny database systems can support ECA-based agents with simple action languages. The authors in [24], [25] address the problem of answering continuous location queries and they propose a rough solution based on mobile agents that monitor the reference and target objects of the queries. However, the context of this work assumes a wireless environment where information of moving objects is accumulated and processed in base stations. In contrast, we consider the mobile objects to constitute the active nodes of the wireless network; there are no base stations and the processing of queries is performed by the mobile objects themselves. Finally, a work that deals with a problem very similar to the one we are examining is presented in [26]. The environment in [26] is a fastevolving pure P2P network and the main issue is the efficient information retrieval. The authors present a mobile agent solution and deal with the various issues concerning the particular application, like the distribution of the mobile agents in the network. Our work is orthogonal in that we do not deal with the properties of a particular query routing and distribution strategy but propose the language in which mobile agents should be expressed (ECA rules) and a general P2P system architecture that can provide scalability, efficiency and security. 3. MOTIVATING EXAMPLE Imagine that Dr. Davis goes everyday to the hospital where he works. The hospital is pretty far away from his house and therefore he can choose among several alternative routes to follow in order to reach it. Usually, Dr. Davis avoids the routes that involve major intersections that are likely to have traffic jams. However, even the routes he uses are occasionally packed with cars or even completely blocked due to random incidents. Moreover, often Dr. Davis has several things to do during his trip to the hospital like shopping, going to the gas station or going to the post office. Due to these tasks he may have to alter his usual route. It would be useful to him, if he could find out the traffic conditions along the alternative routes he plans to follow. Using this information he could choose the best route to the hospital and even decide if he has time to fulfill his extra duties or leave them for later. Suppose that almost each car in the city has a small driving aid device which hosts some car positioning system (e.g. a GPS), a navigation module and sensors. The car positioning system

3 detects the geographical location of the car, which is then transformed by the navigation module into a road segment number using a digital map. Thus, the position of the car is always identified by some road segment number. Suppose also that the driving aid device contains a database (probably small), which stores car-positioning information (segment numbers), traffic information gathered by the car s sensors and possibly other types of information. Finally, assume that the device contains an application through which it participates in a wireless P2P system. This P2P system is based on mobile agents. Dr. Davis s car is a member in this system. The reason he is a member of such a system is to gain traffic information about places he wants to reach at the time he wants to reach them. In return, he provides traffic information to other peers of the system. Thus, the peers or the P2P system are mainly cars, which both require and provide traffic information. The peers of the system communicate using wireless communication links established among peers-cars that are close to each other. In order to get some help for his route choice, as soon as Dr. Davis turns the car engine on, he poses queries in the P2P system about the traffic at several points along the alternative routes that he plans to follow or the routes that the driving aid device proposes. Figure 1 shows an example of alternative routes from Dr. Davis s house to the hospital. Suppose that he is interested in traffic conditions at road segments 33, 20, 42 and 36 in order to decide if he has to drive directly to the hospital or he can make it on time by passing first by the post office. However, he does not want these questions of his to be answered only once. This would be rather insufficient, since the traffic conditions could change during his trip. On the contrary, he would like to be notified for changes of the traffic at the points he identified, so that he will have valid information upon to decide when the time comes to choose one of the routes. This would save Dr. Davis from asking and receiving the same information multiple times and, moreover, would lighten the network traffic. After Dr. Davis s requests for traffic information, the application in the driving aid device forms and propagates into the P2P system mobile query agents that reach peers present in the requested areas; i.e. road segments 33, 20, 42 and 36. Thus, mobile agents are propagated to cars (peers) that are currently driving through these road segments. The mobile agents monitor the traffic at the requested areas and inform Dr. Davis s peer system only when important changes are detected. Note that the agents can vary depending on the information they seek and the routing algorithm they follow. In general agents have to hop from peer (car) to peer (car) until they reach their target road segment and they may also have to hop from peer to peer in order to remain at a particular segment. When a deployed query agent discovers useful information that needs to be returned to Dr. Davis s peer system it forms and deploys an answering agent. The target of this agent is to find Dr. Davis s peer system and provide the discovered information. In order to achieve this task, the answering agent is provided with the expected route of Dr. Davis s car. This information is encoded in the querying agent at the time of its creation. The peers (cars) form a wireless ad hoc network. Each peer can communicate with other peers within the communication radius. Peers are not responsible for routing the agents in the system. Instead, each agent is responsible for its own routing. The peers simply poll the network for peers in the acquaintance area and store this information in their database. The peer database also contains GIS information about the roads, the segments and their geographic location. The agents can use this information in order to implement their routing algorithm according to their specialized routing demands. Hence, there is no global routing policy in the P2P network, but each mobile agent carries the prescription of the routing algorithm that matches its needs Figure 1: Alternative routes to the hospital 4. PROBLEM ANALYSIS The previous example is an illustration of the problem of answering queries in a fast-evolving P2P system. The two main characteristics that distinguish these systems from typical P2P systems are: a) the topology of the P2P network is constantly changing and b) the information contained in the peers change much more frequently than it is queried. The complexity of querying a P2P system depends not only on the characteristics of the system but also on the complexity of the query. The simplest form of query is when there is one peer that holds the required information. Answering such a query means to find the appropriate peer, communicate with this peer in order to request the information and finally get the answer from this peer. Each of these three steps can be a simple or complex problem depending on the structure of the P2P system. Locating the appropriate peer can be extremely difficult if there is no indexing information that can guide the search process, i.e. a blind search. On the contrary, when each peer contains a global index about the content of each peer, or when there is a known super-peer that contains this global index information, the problem becomes trivial. In fact, searching for the peer s address is just a (meta) query. Note that the task of finding the appropriate peer does not necessarily mean to come in contact with this peer. When the peer s address is found the next step is to communicate with the peer and request the information. If the communication network can route a message from the requesting peer to the destination peer, this task is trivial. On the contrary, when the communication has to be done by routing messages through the P2P network, the problem becomes more complicated. In this case, the P2P system must be able to solve the routing problem, i.e. find a path in the P2P network that links the requesting peer with the destination peer. Note that, in some cases the process of locating the appropriate peer is done by searching the P2P network until the peer is reached. In this case, there is no need for a separated task in order to request the information. The final stage of sending the answer back to the requesting peer is similar to the previous step. It requires the two peers to communicate. This task can be achieved either using the capabilities of the communication network or the routing capabilities of the P2P system. For fast-evolving P2P systems the above problems become more difficult. It is much harder or even impossible to maintain indexing information when the content of the peers is constantly 42 36

4 evolving. Also, it is much harder to perform routing when the topology of the network is not stable. Note that in fast-evolving P2P networks like the one of our example, there is no subset of the P2P network that remains constant. When the queries become more complex and the requested information cannot be found into only one peer, the entire scenario becomes more problematical. There are queries that have to combine the information from various peers. Treating such queries as a set of simple queries is hardly the optimal choice. In our motivating example, computing the average traffic for a chain of segments could be converted into finding the traffic situation at each segment and then computing the average. This would mean sending information from each segment to the requesting peer. However, if the average computation is done at a peer in one of the involved segments and only the average is transmitted back, the communication cost would be reduced. An additional factor to the complexity is the continuous property of a query. A continuous query requires from the peers that provide information to keep constantly the requesting peer up-to-date about the answer. Thus, if the content of the information providers (peers) changes, the requesting peer must be informed. There are two main alternatives in answering continuous queries. The first is the pull approach where the requesting peer is constantly querying the information source in order to obtain the current state of the data. The obvious disadvantage of this approach is the processing and communication cost of answering the same query and transmitting the answer more than once. The second alternative is the push approach where the requesting peer sends the query once to the data provider peer. Then, the data provider is sending the answer back to the requesting peer based on some event logic. One of the disadvantages of this approach is the added complexity at the data provider side. The peer has to remember the queries sent by various requesting peers. Furthermore, the requesting peer looses control over the querying process and this control is assigned to the data provider peer. A hybrid approach involves the existence of data brokers that constitute an intermediate layer of information dissemination. They collect information from the sources and they redistribute it to the consumers. This combination of the push and pull approaches might be proven more efficient, but it assumes a complicated infrastructure that implements sophisticated routing, data caching and subscription management techniques. This alternative solution has become very popular in the publish/subscribe paradigm and has been considered in the P2P environment. However, in the P2P environment, any peer can be the source of information, which makes the problem more demanding in terms of scalability. Implementing a publish/subscribe technique in a P2P system is complicated due to the evolution of the network topology and the constant evolution of the peer s data content. A paradigm that seems very appropriate for the handling of the described problems is that of Mobile Agents. We call mobile query agents the agents that are used to answer queries in the P2P system. Using mobile agents one can handle routing problems by encoding routing strategies within the agent. This allows the definition of flexible and even ad-hoc routing strategies that need not be predefined by the P2P system. For complex or continuous queries the agents can be of even greater value since they can perform local operations and they can encapsulate the continuous query. In this case, the resulting architecture is similar to a push approach only that the control of the push process in maintained by the querying peer through its agent. Overall, mobile agents are a very attractive, robust and efficient approach for distributed information retrieval, thus, for P2P systems. When we use mobile agent to perform queries in a P2P system the actions of the agents are data centric and quite simple. The agent either collects information or moves through the network based on some routing or indexing information. The crucial point for this architecture to work is the scalability and performance. In the P2P system a large number of agents, proportional to the number of queries, will have to move around and execute at various peers. Therefore, the peers must be able to host and execute a large number of agents. Furthermore, the cost of moving an agent must be minimal. This is because in fastevolving P2P systems routing is quite difficult to achieve, and therefore, the agents will have to hop from peer to peer a large number of times until they reach their destination. However, many of these agents will be quite similar as they perform similar tasks. Thus, there is a high opportunity for optimization. The main contribution of this paper is the proposal of ECA rules for the implementation of mobile query agents for fastevolving P2P database systems. Using ECA rules and active databases seems very appropriate for mobile agents that perform simple data-centric operation and require scalability and efficiency. The main advantages we have identified in the usage of ECA rules and active databases are the following: The logic of the mobile agent is defined in a declarative way. This is a key issue that can affect scalability, portability, security and processing optimization. An adbms can efficiently execute the tasks of the mobile agents since most of them are database operations like queries and event monitoring. This enhances scalability since mobile agents can be supported using the same resources. The security issues are delegated to the adbms. The security of the ECA rules can be implemented using existing security mechanisms of the adbms thus allowing explicit privileges to be assigned to each mobile agent. Transmitting rules instead of application code can be very efficient especially when the most of the rules are instances of rule patterns. In this case only the pattern name and instantiating parameters need to be transmitted. 5. P2P SYSTEM & AGENT ARCHITECTURE In this section we describe the general architecture of a P2P system that supports mobile agents based on Active Database technology. As already explained, this architecture is expected to influence positively the scalability and efficiency of the P2P systems for answering queries, especially when these queries are complex or continuous. 5.1 Peer Architecture A P2P system is composed out of two main components: a) the participating peers and b) the communication network infrastructure.

5 The communication network In this paper we do not deal with the issues regarding the communication network that allows the involved system nodes to propagate agents and exchange information. In its general case, the routing of communication messages in a fast-evolving P2P network is a complicated issue. However, our architecture obviously needs the communication network. In order to use it we make the following two assumptions: Given a location selection predicate there is a routing algorithm that can propagate a message from a source node to one or more node that satisfy the location selection predicate. Given a destination node ID there is a routing algorithm that can propagate a message from a source node to the corresponding destination node. Our contribution is focused on the functional architecture of the participating peers. The proposed architecture of a peer is summarized in Figure 2. Each peer consists of: The Peer adbms, where data are stored and active rules are evaluated. The P2P Layer that comprises: - The Acquaintance Manager (AM), which is responsible for managing acquaintances - The Mobile Agent Manager (MAM), which is responsible for handling of the mobile agents. One or more Client modules, which provide and consume information to/from the adbms. A P2P Interface through which the user communicates with the P2P Layer and the adbms. query Client 1 Client n.. answer global local P2P Interface API Insert data Mobile Agent Manager Rule Engine P2P Layer Peer adbms Acquaintance Manager Local DB Figure 2: The structure of a peer In the following we describe the above modules and the properties that are required by our architecture. Acquaintance Manager. AM is the mean through which the peer gets knowledge of the P2P world (i.e. the rest of the P2P system) and vice versa. This is accomplished by using the communication network infrastructure through which the peer communicates directly with some other peers. The latter are called acquaintees of the peer and constitute the logical neighborhood of it. The module encapsulates the algorithm of discovering and establishing new acquaintees and abolishing existing ones. However, this process can be triggered not only by inside the AM module but also by Acquaintances request from external peers, the MAM or even the adbms. In any case, the information about acquaintees is stored in the adbms. The second major task of the AM module is to send and receive mobile agents to/from the acquaintees. This process is done in collaboration with the Mobile Agent Manager module described next. Mobile Agent Manager. MAM works as a reception and departure manager for the mobile agents. More specifically, MAM is responsible for the storage and activation of the mobile agents received through AM as well as the departure of mobile agents to other peers. The activation of an agent mainly concerns the deployment of the incorporated ECA rules in the adbms. The departure of an agent has to do with the construction of the appropriate packet that contains the agent code and state data and the coordination of its transportation through the AM module. Furthermore, MAM manages meta-information about the agents, which is also stored in the adbms. For example MAM could check the credential of an incoming agent and set the appropriate privileges to the agent s ECA rules. Peer adbms. The adbms is the core module of the peer, as it manages the information of the node and implements the functionality of the various agents through the activation of their ECA rules. The adbms contains two sub-modules: The DBMS and the Rule Engine. The DBMS stores all the information that is accumulated and handled by the node. This includes the data generated by the AM, the MAM, the Clients and the P2P interface module. The ECA rules are also stored within the DBMS. The Rule Engine monitors various events generated by the DBMS and external sources and fires and evaluates the appropriate ECA rules according to the supported privilege and priority protocol. Finally, note that storing the ECA rules in the adbms allows us to use the security mechanisms of the adbms in order to define the privileges of the hosted agents. This can protect the database from spurious agents that are willing to harm it. Clients. The client components are mostly data providers to the database but might retrieve information, too. They interact with the adbms by reading, inserting or updating data through an application interface (API). P2P Interface. The P2P Interface enables the user to exploit the P2P system but also to manage his/her own local data. For each query posed by the user on the P2P system the P2P Interface forms the appropriate mobile agent(s), which is (are) passed on to MAM for activation. When an answer is received the appropriate rules are activated in the Rule Engine and the results get pushed to the P2P Interface. 5.2 The Definition Language: ECA Rules The knowledge model of the adbms supports ECA rules of the following general form: When <event expression> (If <condition expression>) Then <action expression> (Else <action expression>) The rules can be parametrical; thus, they may contain parameters that acquire values when the rule is triggered. Event Expression. A wide range of events may be supported and the features of the execution model, i.e. consumption mode, transition granularity, cycle policy, scheduling of rules etc [19], may vary depending on the implementation of the adbms. The only restrictions imposed by the architecture refer to the rule priorities and the event/condition coupling mode: the adbms

6 should support relative priorities among the rules of a mobile agent and an immediate or deferred coupling mode between the event and the condition part of rules. Condition Expression. The condition part of the ECA rule is a Boolean expression or function defined on the set of values returned by a database query (in SQL for example). Action Expression. The action part is a list of actions that have to be executed with a specific order in the same transaction. This is because all the actions have to be executed successfully. In case that at least one of them fails, the ones that have been executed have to roll back and the ones that are pending have to be canceled. The actions can be database operations, ECA rule handling operations (activation/deactivation) or calls to functions of MAM (functions for management of local agents and transfer to acquaintees), AM (functions for the on-demand discovery of new acquaintees based on a provided list of desired characteristics) or even other arbitrary functions. 5.3 Mobile Query Agents The purpose of a mobile query agent in a P2P system is to achieve the following two tasks: T1) find and migrate to the system nodes that provide the requested information T2) gather and transmit the information from such nodes back to the originating (querying) peer. As already stated, we propose the mobile agents to be implemented through ECA rules. Therefore, each mobile query agent is defined using a number of ECA rules and a number of datasets. The ECA rules represent the logic of the agent while the datasets can contain initial parameters, agent state information as well as results that have been collected and computed by the agent. For organization purposes we group the rules that comprise a mobile agent based on the task they attempt to accomplish. As a result we propose the mobile query agents to be divided into two rule groups: R0 and R1. The purpose of each of these groups is explained next: R0: Migration/Deployment/Agent Management Rules. The main purpose of this group of rules is to achieve task T1. The rules in this group are responsible, first of all, for routing the mobile query agent to a peer where it can collect useful (to the query it represents) data. The routing task is in fact a search problem and the agent can implement various strategies and use as heuristics routing information that may be provided by the peer s database as well as historical data acquired during the lifetime of the agent. In order to achieve a routing task the rules or R0 may need to call functions of the AM module in order to discover new acquaintees and then to call function of the MAM module in order to transfer an agent s copy to the selected peer. In our motivating example, a mobile query agent that looks for traffic information for segment 33 and it is currently running on a peer on segment 20, it can use the map of road segments (which is assumed to be stored on the peer s database) in order to decide that the next step is to migrate to a peer on segment 42. However, if the agent had just migrated from segment 42 to segment 20 then it may choose a different route. When the mobile agent arrives at a peer with useful (to the query the agent represents) data, then the R0 rules are responsible for deploying the rule group R1, which means the insertion and activation of the appropriate rules in the local adbms. This is achieved with function calls to MAM, which has access to the agent s rules even when the rules have not been deployed. According to this organization the MAM module needs to deploy only the R0 rules of each incoming agent and not the entire set of rules. In this manner we improve the efficiency and scalability of the system. After all, many of the agents are only using the peers for their routing needs and not to collect query data. Finally, the rules of R0 are responsible for the general (self)management of the agent. This includes the lifecycle management (cloning and self termination) and may also include adaptation, error handling and other issues depending on the complexity of the agent. R1: Information Retrieval Rules. This group of rules is responsible for implementing the task T2 of the agent. This means that the rules gather information from the peer s adbms on which the agent is running, according to the query definition, and transmit the results back to the query-originating peer. The task of transmitting the results back to the query-originating peer is not always simple. Therefore, we propose to use an answering agent to carry the response back. The rules of R1 will therefore generate a new answering agent whenever an answer has to be sent to the query-originating peer. The answering agent will have to perform its own search for the target peer to which it should deliver the answer. The main benefits from using answering agents are the encapsulation within the agent of the routing algorithm and the way in which the answer is to be delivered. In our motivating example, returning traffic information to the car of Dr. Davis is not trivial. The communication network is a short-range wireless network and so the answering agent has to search for Dr. Davis s car. In order to make this task possible the mobile query agents deployed by Dr. Davis could carry with them the expected route (or alternative routes) of Dr. Davis so that the answering agents would perform an informed search. In case of a continuous query, or of a query that involves distributed information, the R1 rules may become quite complicated and execute for a long time. When the R1 rules have to run on a peer for some time there is always the possibility that the data content of the peer becomes useless to the agent. This holds particularly for continuous queries in fast-evolving P2P systems. In our motivation example, an agent that watches for traffic jams on segment 33, can not assume that the car it is sitting on will remain on this segment for long. On the contrary, it is expected that the car will soon change segment. It is, therefore, required that some of the rules in R1 monitor the data content of the peer and when this data stops being relevant to the agent it stops the operation of the other rules in R1 and notifies the appropriate rules in R0 that the agent needs to migrate to a different peer. Datasets. Apart from the above groups of rules we propose the existence of two datasets that accompany each agent. The first one is the control dataset that is necessary for the migration rules to function properly. The migration rules can use and update this dataset. The second dataset is the information retrieving dataset, which is used by the information retrieval rules. These two datasets travel along with the agent s code, the ECA rules, and represent the memory of the agent. For instance, in our motivating example the control dataset of an agent will contain the group of target segments and possible constraints on it (sequence of visiting the segments or alternative routes on them). The information retrieval dataset will contain the parameters for queries. Since we base our architecture on Active Databases it is natural to assume that the datasets represent objects that are stored

7 in the adbms. Thus, in their simplest form the datasets are relational tables. 5.4 The Life Cycle of the Agent As discussed, an agent is created when the user of a peer poses a query to the P2P system or when an agent decides that it has to create a new query agent. An agent is firstly managed locally, by the MAM of the peer on which it is created. The local MAM treats it as any other agent it receives from AM. The R0 rules of the agent are deployed into the adbms and they decide if the agent should hop to another peer according to the routing algorithm in order to reach a target peer. Thus, the user can transparently query the local adbms and the P2P system. On each node the agent hops it is activated by the MAM. When the agent finds a target peer, it deploys the R1 rules and these rules start working on the query and data collection task. When an answer needs to be sent back to the query-originating peer (or to any other target peer), an answering agent is constructed and activated by the appropriate R1 rules. This agent gets the responsibility of finding the target peer and of delivering the response. An agent s death can be signaled by a time-to-live period or any other logic encoded within the R0 rules. Also, it can be provoked by an extermination procedure. Killing an agent is performed by expunging from the adbms all the rules and datasets of the agent. 5.5 Efficient Management of Mobile Agents Expressing the mobile query agent with ECA rules and using the proposed system architecture facilitates the management of the group of agents residing in a system unit without the demand of a specialized module. Management tasks such as replacing an agent with its newly arrived version, merging agents that seek totally or partially the same information and treating them as a group, maintaining priorities among agents according to some criteria can be performed solely by the adbms with the guaranteed efficiency it provides. Moreover, it is viable to incorporate in the adbms rule patterns that come with the specific P2P API. And give mobile agents the option to carry only ids of rule patterns together with values of their parameters. Therefore, the agents code is shrunk even more and the responsibility for the realization of the rules (priorities, coupling and consumption modes etc [19]) is transferred totally to the adbms. Scalability is further enhanced since all implementation optimizations are hardcoded apriori in the adbms and the deployment of agents is limited to passing a number of parameters to the adbms. 6. APPLICATION EXAMPLE OF MOBILE QUERY AGENTS Following the motivating example of section 3, lets assume that most of the cars in the city possess a driving aid system that consists of a GPS, a navigator, some car sensors, a small adbms and a P2P module. The GPS detects the geographical location of the car, which is then used by the navigator module to identify the road segment number on which the car is moving. The navigator module contains road maps that divide the roads into segments and assign a unique id to each segment. Thus, the position of the car is identified by the segment id. This information is stored in the adbms along with a timestamp. The car sensors would gather the new information about speed, traffic density as well as all the other monitored parameters. Information is accumulated periodically according to a polling period. We assume that traffic information consists of 5 parameters: time, location, speed, distance, and whether the car s engine is working or not. The distance is the sum of the empty space in front and in the back of the car as measured by the sensors. The speed and distance are computed as average values over a 1 minute and 5 minutes intervals. Overall, the system monitors 7 values, which are stored in the following Traffic relation. Traffic(timestamp, segment_id, speed1, speed5, dist1, dist5, engine_on) As we can observe, Traffic stores time-stamped tuples that contain all the accumulated relevant information. That is, average speed and distance values, the road segment in which the car is and a flag that shows whether the car engine is working or has stopped. A tuple is inserted in the Traffic relation every N seconds, where N is the polling period. The admbs can detect the following set of simple events on which it is interested in: SEGMENT_CHNG(new_seg, new_tuple): occurs when the car passes to another road segment. The parameter new_seg is the new value of the segment attribute of Traffic. The new_tuple parameter contains the last inserted tuple in Traffic that is used to signal the event. SPEED1_CHNG(granularity, speed_diff, new_tuple): occurs when there is a change in the average speed stored in speed1 of Traffic by more than granularity. This change is stored in speed_diff. DIST5_CHNG(granularity, dist_diff, tuple): occurs when there is a change in the average distance stored in the attribute dist5 of Traffic by more than granularity. This change is stored in dist_diff. Beyond the Traffic relation, the database of each peer holds a relation that stores the rules that are installed in the DBMS. The relation has the following form: MARules (MA_id, rule_id, rule_body) where MA_id is the id of the mobile agent to which the rule belongs, rule_id is the rule s name as defined by the agent and rule_body is the body of the rule. The rule engine of the adbms monitors the insertions, updates and deletions in this relation and triggers the rules for which there is a respective tuple in the relation. Moreover, the MAM module supplies the following functions: NOTIFY_FOR_LEAVE(dest): notifies MAM that the respective mobile agent should be propagated to another peer that satisfies the value of the parameter dest. NOTIFY_FOR_SEND(p1,.., pn, node_id): this action notifies MAM that it should send back to the system node (node_id) that initiated the respective mobile agent the information contained in the parameters p1,..., pn. DEPLOY(MA_id, rule_id): this is a special action that takes as parameters the id of the mobile agent MA_id and the name of the rule rule_id that is to be deployed. Additionally, actions that activate and deactivate rules or even general functions that process data can be offered b MAM. Dr. Davis is interested in the traffic conditions at several points. One of them is the road segment numbered 33. When Dr.

8 Davis poses a traffic query for segment 33 the system generates a mobile agent with the following characteristics: notify Dr. Davis for the current traffic conditions when the (average per minute) speed changes more than 20Km or when the (average per 5 minutes) distance is lower than 4m. These are the default values used by the driving aid system but the user could specify other values. The above distance condition is used to track traffic jams. The following rules define this agent: R0_a: When TRUE If 0 <> (select count(*) from Traffic where timestamp = LAST_TS and segment = 33) Then Else delete from MARules where MA_id=MY_ID and rule_id=r0_a; DEPLOY(my_id, R0_b); DEPLOY(my_id, R1_a); DEPLOY(my_id,R1_b); DEPLOY(my_id, R0_c) delete from MARules where MA_id =MY_ID and rule_id=r0_a; DEPLOY(my_id, R0_c); LEAVE(MY_ID) R0_b: When SEGMENT_CHNG(newsegment, t) Then delete from MARules where MA_id =MY_ID; LEAVE(MY_ID) R0_c: When LEAVE(my_id) If my_id=my_id and DETECT(appr_p) Then delete from MARules where MA_id =MY_ID; NOTIFY_FOR_LEAVE(appr_p) Else If my_id=my_id Then SLEEP 60; LEAVE(MY_ID) R1_a: When SPEED1_CHNG(20Km/h, speedchange, t) Then NOTIFY_FOR_SEND(t.speed1, t.dist5, 10399) R1_b: When DIST5_CHNG(1, distchange, t) If t.dist5 < 4m Then NOTIFY_FOR_SEND(t.speed1, t.dist5, 10399) In the above rules we use the following variables: - LAST_TS: is a variable that stores the value of the time stamp of the last-inserted tuple in Traffic - MY_ID: is the id of the agent that owns the rule. - LEAVE: is an external event that is signaled by the agent in order to trigger its own migration rule(s). Such an external event has to be supported by the P2P layer. - DETECT(appr_p): is an SQL query in the database that seeks for a current acquaintee that satisfies the value of the parameter appr_p. The above rules realize the mobile agent functionality, which is summarized in: a) finding the initial peers that provide the requested information b) gathering and transmit the information from such peers c) migrating to other more appropriate peers to accumulate this specific information when the ones on which it is hosted are not able to provide it any more. When a mobile agent gets to a peer, the respective R0_a is inserted in the MARules. The rule is shortly triggered and if the condition is true, the rule R0_a is deleted and 4 rules are inserted in MARules: R1_a, R1_b, R0_b and R0_c. The information retrieval rules (R1_a, R1_b) monitor the traffic condition based on the information obtained by the current peer through its sensors. As we explained, this information is stored in the Traffic relation. Whenever needed, these rules transmit to the peer of Dr.Davis, who has node id = 10399, new traffic information. Furthermore there is rule R0_b responsible for the management of the agent and rule R0_c responsible for the migration of the agent. The manager rule R0_b makes sure that the peer is still on the required road segment (33). If not, a proper event is signaled so that the migration rule R0_c is triggered and initiates the resettlement of the agent on another appropriate peer. Note that in case of triggering of all three R0_b and R1_a, R1_b because of the same inserted tuple in Traffic, R0_b must have priority over the other two rules. 7. CONCLUSIONS AND FUTURE WORK In this paper we have presented a solution for answering queries in pure fast-evolving P2P systems based on mobile agents implemented with ECA rules and employing existing active database technology. We have argued that using a mobile agent framework in this context would lighten the peer infrastructure needed for instant and continuous query processing, would alleviate the necessity for a sophisticated policy of disseminating information-events and queries and would allow an adaptable query management according to personalized specifications of peers. The proposed system node architecture employs active database technology in order to cope with the scalability and performance issues that are very critical for the feasibility of a fast evolving P2P system. The main advantages of implementing the agents using ECA rules is that they assure a secure way of extracting information from an autonomous database and that they do not demand a specialized platform to run on. Rather than that, an adbms with basic functionalities is adequate. The proposed architecture respects the self-manageable and diverse nature of mobile agents while it guarantees their easy migration from peer to peer and the controllable but fast deployment on them. Furthermore, an agent can be adaptable to an assortment of heterogeneous peers, provided user-defined procedures and management policies, by carrying alternative We have argued that the proposed architecture is efficient and scalable and thus ideal for very dynamic systems that lack any kind of centralized or distributed control such as fast-evolving pure P2P networks. Nevertheless, the effectiveness of the proposed ECA-based architecture depends on two major factors. The first is the performance of the active database used to host the ECA rules of the agents. The described solution will be viable, if the active mechanism of the database is powerful enough to host and process a sufficient number of triggers. The second factor is the expressiveness of the ECA rules, i.e. at what extent is the latter adequate for the description of the location queries that the mobile objects would like to pose and for the description of the routing algorithms that they would like to use. We expect that the proposed declarative architecture will be more efficient than code-based architectures in cases of not extremely complex queries and routing algorithms.

9 In the near future we are going to elaborate on planning and optimizing the deployment of a group of mobile agents that seek similar information. Motivated by the presented example from the P2P field, we will develop techniques for optimizing the manageability of agents that seek traffic information for a set of road segments and also, we are going to deal with additional issues, such as distributed caching and fault tolerance. Finally, we plan to simulate the P2P system and perform series of experiments that would show the performance in realistic situations. 8. ACKNOWLEDGEMENTS This work has been funded by the project PENED The project is cofinanced 75% of public expenditure through EC - European Social Fund, 25% of public expenditure through Ministry of Development - General Secretariat of Research and Technology and through private sector, under measure 8.3 of OPERATIONAL PROGRAMME "COMPETITIVENESS" in the 3rd Community Support Programme. 9. REFERENCES [1] M. Koubarakis. Multi-Agent Systems and Peer-to-Peer Computing: Methods, Systems, and Challenges. Invited Talk in 7 th Int. Workshop on Cooperative Information Agents, Finland [2] Brian Brewington, Robert Gray, Katsuhiro Moizumi, David Kotz, George Cybenko, Daniela Rus. Mobile agents in distributed information retrieval. In Intelligent Information Agents edited by Mathias Klusch, Springer Verlag., Chapter 15, pages , [3] I. Stoica, R. Morris, D. Karger, M.F. Kaashoek, H. Balakrishnan. Chord: A scalable peer-to-peer lookup service for internet applications. In Proc. Of the ACM SIGCOMM Conf. San Diego, [4] P. Druschel, A. Rowstron. Pastry: Scalable, distributed object location and routing for large-scale peer-to-peer systems. In Proc. Of the 18 th IFIP/ACM Intern. Conf. on Distributed Systems Platforms (Middleware 2001), [5] B.Y. Zhao, L. Huang, J. Stribling, S.C. Rhea, A.D. Joseph, J. Kubiatowicz. Tapestry: A Resilient Global-scale Overlay for Service Deployment. IEEE Journal on Selected Areas in Communication, November [6] S. Ratnasamy, P. Francis, M. Handley, R. Karp, S. Shenkers. A scalable content-addressable network. In Proc. ACM SIGCOMM. San Diego, [7] A. Y. Halevy, G. I. Zachary, D. Suciu, I. Tatarinov. Schema Mediation in Peer Data Management Systems. 19 th Intern. Conf. on Data Engineering, India [8] [9] B. Gedik, L. Liu. PeerCQ: A Decentralized and Self- Configuring Peer-to-Peer Information Monitoring System. In Proc. of the 23 rd Int. Conf. on Distributed Computing Systems, Rhode Island, USA, 2003 [10] A. Rowstron, A. Kermarrec, M. Castro and P. Druschel. Scribe: The design of a large-scale event notification infrastructure. In Int. Workshop on Networked Group Communication, p , London, UK, [11] S. Idreos and M. Koubarakis. P2P-DIET: A Query and Notification Service Based on Mobile Agents for Rapid Implementation of P2P Applications. Technical Report, Intelligent Systems Laboratory, Dept. of Electronic and Computer Engin., Tech. University of Crete, June [12] W. Siong Ng, B. Chin Ooi, K. Lee Tan. BestPeer: A Self- Configurable Peer-to-Peer System. In Proc. of the 18 th Int. Conf. on Data Engineering, California, [13] E. Bonsma, C. Hoile. A distributed implementation of the SWAN peer-to-peer look-up system using mobile agents. In Proc. of the AAMAS 02 Workshop on Agents and Peer-to- Peer Computing, Italy, [14] C. Hoile, F. Wang, E. Bonsma, P. Marrow. Core specification and experiments I DIET: a decentralized ecosystem-inspired mobile agent system. In Proc. of the 1 st Int. Joint Conf. on Autonomous Agents & Multiagent Systems, p , Italy [15] O. Babaoglu, H. Meling, A. Montresor. Anthill: A framework for the development of agent-based peer-topeer systems. In Proc. of the 22 nd Int. Conf. on Distributed Computer Systems, p , Austria [16] Subrata Das, Kurt Shuster, Curt Wu. ACQUIRE: Agent based Complex Query and Information Retrieval Engine. In Proc. of the 1 st Intern. Joint Conf. on Autonomous Agents and Multiagent Systems, p , Italy, [17] A. Gallardo-Antolin, A. Navia-Vasquez, H. Y. Molina-Bulla, A.B. Rodriguez-Gonzalez, F. Valverde-Albacete, J. Cid- Sueiero, A.R. Figuieras-Vidal, T. Koutris, C. Xiruhaki, and M. Koubarakis. I-Gaia: an Information Processing Layer for the DIET Platform. In: Proc. of the 1 st Intern. Conf. on Autonomous Agents and Multi-Agent Systems, Italy, [18] J. Bailey, M. Georgeff, D. Kemp, D. Kinny, K. Ramamohanarao. Active Databases and Agent Systems A Comparison. In Proc. of the 2 nd Int. Workshop on Rules in Database Systems, p , Athens, Greece, [19] N. W. Paton, O. Díaz: Active Database Systems. ACM Computing Surveys 31(1):63-103, [20] J. Widom, S. Ceri. Active Database Systems. Triggers and Rules for Advanced Database Processing. Morgan Kaufmann Publishers, Inc [21] R. S. Gray. Agent Tcl: A flexible and Secure mobile-agent system. In Proc. Of the 4 th Annual Usenix Tcl/Tk Workshop p. 9-23, [22] I. Hagen. Challenges for ECA Rule Designers when Implementing Coordination Protocols. Tech. Report HS- IDA-TR , University of Skövde, [23] Sasu Tarkoma, Mikko Laukkanen. Supporting Software Agents on Small Devices, In Proc. of the 1 st Int. Joint Conf. on Autonomous Agents and Multiagent Systems, Italy, [24] S. Ilarri, E. Mena, A. Illarramendi: A Mobile Agents Based Architecture for the Distributed Processing of Continuous Location Queries in a Wireless Environment: Performance Evaluation. In Workshop of Intern. Conference on Extending Database Technology, Heraclion, Crete, [25] S. Ilarri, E. Mena, A. Illarramendi: Monitoring Continuous Location Queries Using Mobile Agents. Advances in

10 Databases and Information Systems, 6th East European Conference, Bratislava, Slovakia, [26] Khaled Nagi, Iman Elghandour, Birgitta König-Ries: Mobile Agents for Locating Documents in Ad-hoc Networks. 2 nd Int. Workshop on Agents and Peer-to-Peer Computing, Melbourne, Australia, 2003.