Coordination in Mobile Agent Applications

Coordination in Mobile Agent Applications Giacomo Cabri, Letizia Leonardi, Franco Zambonelli Via Campi 213/b – 41100 Modena – ITALY Day Phone: +39-59-376735 Fax: +39-59-376799 E-mail: {giacomo.cabri, letizia.leonardi, franco.zambonelli}@unimo.it

Dipartimento di Scienze dell’Ingegneria – Università di Modena Technical Report No. DSI-97-24, October 1997

1

Coordination in Mobile Agent Applications Giacomo Cabri, Letizia Leonardi, Franco Zambonelli Dipartimento di Scienze dell’Ingegneria Università di Modena Via Campi 213/b – 41100 Modena – ITALY Day Phone: +39-59-376735 Fax: +39-59-376799 E-mail: {giacomo.cabri, letizia.leonardi, franco.zambonelli}@unimo.it Abstract The paper addresses the issue of coordination in distributed applications based on mobile agents. The presence of mobile active computational entities makes traditional coordination models based on message-passing, such as the client-server one, not effective, from both the performance and the usability points of view. Indirect coordination models suit better the mobile scenario: interactions occur via blackboards where information is accessed in an associative way, thus uncoupling the involved entities. The paper surveys these different approaches and evaluates their impact in the design of a widely distributed application in the area of information retrieval. This permits to outline the advantages of uncoupled coordination models and to point out the urge for a coordination model based on reactive and programmable blackboards, that may increase the safety and the security of the environment while simplifying the task of programming distributed mobile agent applications. Keywords: Distributed Systems, Mobile Agents, Coordination, Application Design, WWW Information Retrieval

1

Introduction

The wide spread diffusion of network systems and of Internet, together with the new corresponding application needs, points out the limits of traditional approaches to distributed programming: new technologies and programming paradigms are required to suit the new scenario. One of the most promising technologies is agent mobility [MA97]. While the advantages of mobility of passive entities, i.e., data and files, have been identified in the past, modern programming environments, such as Java [Sun94], have integrated the capability of moving code. Today's challenges require added flexibility and, in particular, the possibility of moving whole execution closures, usually called mobile agents to stress their role of active entities, roaming over Internet to execute specified task while preserving their execution state. There are several application areas that can take advantage of a programming style based on mobile agents: among the others, mobile computing systems, widely distributed information retrieval, and adaptive remote network management [Wal97]. Currently, several systems and programming environments integrate mechanisms and language constructs to achieve agent mobility [MOS97]. Nevertheless, there are still several open research issues to be solved to make the mobile agent technology a widely accepted and usable one, such as security, definition of appropriate programming languages, efficiency and standardization [Cug97]. This paper focuses on models for mobile agent coordination. In mobile agent applications, one of the fundamental activities is letting an agent coordinate with the entities it encounters during its execution, let these entities be other agents or resources on the hosting execution environments. However, the presence of mobility and the openness of the scenario imply different problems than traditional distributed systems. 2

Traditional distributed systems let application components directly coordinate, by explicitly initiating a communication relying on message-passing mechanisms. Though this permits full programmer control over a distributed application and achieves fast and of low overhead interactions, it presents several drawbacks. On the one hand, any interaction must rely on an explicit knowledge of the whole application environment: this does not suit the intrinsic dynamicity of Internet where a complete knowledge is difficult to be obtained. On the other hand, communications between mobile agents introduce the need of complex routing schemes and require the availability of network connections. A more suitable approach for interaction in mobile agent applications is indirect coordination: agent interactions occur via a third entity, i.e., a blackboard residing on each hosting execution environment, that can be used by agents to put and get messages. The most significant advantage of indirect coordination is to permit both spatial and temporal uncoupling: an agent needs to know neither where the corresponding receiver is nor when it will read the message. This suits well a scenario where the position and the schedule of interactive agents cannot be easily granted. Furthermore, associative accesses to the blackboard permit to easily deal with incomplete knowledge of the execution environments [GelC92]. A further degree of flexibility and safety can come from the introduction of coordination models based on reactive blackboards, programmed to react with specific actions to the accesses made to them from mobile agents. A reactive blackboard can achieve active control over interactions to defend the integrity of each hosting environment from attacks and can adapt the semantics of agent interactions to the specific characteristics of the hosting environment. The paper describes several design alternatives of a distributed application based on mobile agents, depending on the adopted coordination model, with the aim of showing the advantages and the drawbacks of different models for mobile agent coordination. The application relates to distributed information retrieval: in a traditional design scheme, a local process bids remote hosts asking for the needed information; in the mobile agent approach, the design can be based on several agents that move locally to the interesting hosts and come back with the needed information. Coordination is needed to access to local resources and to avoid different agents to visit the same places and retrieve the same information. The paper is organized as follows: section 2 introduces the mobile agent paradigm; section 3 presents a taxonomy of mobile agent coordination models and discusses related works; section 4 describes the distributed information retrieval application used as a case study; section 5 presents and discusses several design alternatives depending on the adopted coordination model.

2

The Mobile Agent Paradigm

Traditional distributed applications are designed as a set of processes statically assigned to a given execution environment (therefore acting as managers of local resources) that cooperate in a (mostly) network-unaware fashion [Adl95]. Instead, the mobile agent paradigm defines applications composed by network-aware entities (agents) capable of actively changing their execution environment by transferring their execution to a different site (mobility). Note that we exclude the study of those systems that do not consider the migration of whole execution entities (i.e., including code, state and execution flow) but only some forms of code mobility – relying on architecture independent intermediate code – such as Java [Sun94] and Inferno [Luc96]. Those systems, though very well suited to specific application areas (as the Applet mechanism of Java for active document presentation), define a too weak notion of mobility to permit their adoption as general paradigms for the design of widely distributed applications.

3

2.1 Applications The shift to the mobile agent paradigm is widely justified by the advantages it provides w.r.t. traditional approaches in widely-distributed applications: • mobile agents can permit to dramatically save bandwidth, because they can move locally to the resources they need, accessing to them and elaborating them, instead of requiring the transfer of possibly large amounts of data [CheHK97]; • when a resource cannot be locally transferred or that operation would be too expensive, the only way to access to it in traditional approaches it is to provide a local server for its management. However, it may be too expensive or even impossible for a server to implement all the needed management services. A more flexible approach can allow to dynamically moving the management services along with the agent as soon as a new one is needed [StaG90]; • the mobile agent paradigm intrinsically suits mobile computing systems. For example, in case of a mobile computing system, the mostly suitable paradigm for the execution of networked software on it is the one of mobile agents that execute by interacting with different execution environments depending on the current position of the mobile system [BhaC95]; • because of the intrinsic unreliability of Internet network connections, applications based on non-mobile communicating executing entities may often fail or time-out. Instead, if the application is based on mobile agents, interacting entities can be moved to the same site when the connection is available, and let them interact without requiring further network connection [Wal97]. The above advantages can be effectively exploited in a wide range of distributed applications. New designs based on mobile agents of traditional distributed intra-net applications, such as CSCW ones [CaiGN96] and network management systems [BalGP97, Bie98] have been already proposed and tested in world-wide environments. Furthermore, brand new world-wide-oriented applications, such as advanced multimedia communication services [Lim96] and Web-search engines [CarPV97], have been conceived and designed by exploiting the mobile agent technology.

2.2 Systems and Languages In the last few years, several systems and programming environments have appeared or have been proposed to facilitate and support the development of widely-distributed applications based on mobile agents [MOS97, MA97]. On the one hand, extensions to existing languages and supporting environments have integrated the capability of moving either script processes (as in Agent Tcl [Gray96], an extension of the Tcl toolkit) or active objects (as in Sumatra, an extension of the Java Virtual Machine [AchRS97]). On the other hand, new systems and languages have been implemented to meet the peculiar needs of the new application scenarios, as the Ara multi-language platform for mobile agents [PeiS97] and the Obliq language for mobile objects [Car95]. In addition, formal models for the mobile agent paradigm, as Ambit [CarG97], have been recently proposed. A fundamental issue that distinguishes the above systems from traditional distributed systems and programming environments is “network awareness”: instead of enforcing the principle of transparency that would make the network appear as a single computer system, they explicitly model the network as a connection of separated execution environments. Migration across computing environments is explicitly activated by the agents themselves, via a command invoked in their code. This contrasts with the traditional approach to migration in distributed computing systems, where movements across nodes of executing entities were transparently activated (apart from a few exceptions [Jul88, CorLZ97]) by the run-time support, to meet a general system goal, i.e., load balancing [ShiKS92]. As a further distinction, past proposals on mobility focused on intra-net environment, thus disregarding issues that are peculiar to the movement of executing entities in a wide, heterogeneous, dynamic and unreliable network, as Internet. 4

To our personal opinion, the major issues that a given proposal in the area has to address are: • code and data portability: the executing code of the agent and its data closure must be represented in a standard and architecture-independent format; • secure execution models: the openness of Internet requires a secure agent execution model that preserves the privacy and the safety of both hosting execution environments and agents; • efficient execution: mobile agents must not require too much resources to the hosting execution environments and must avoid their thrashing; • suitable coordination models: coordination between mobile entities, especially in a wide network, requires appropriate, efficient and secure models. Currently, being Internet mobility a quite new area of research, the above issues have been only partially faced by the existing prototypes and, among a variety of proposals, the way to a standard seems not so near: there is still a lot of work to be done before our PCs and workstations will host a server for mobile agent execution and the Internet will be populated by mobile agents. The contribute of this paper is to provide a detailed analysis of the coordination issues in mobile agent applications, by analyzing and comparing the possible approaches. For a detailed analyses of the other issues we forward the interested reader to [Cug97].

3

Coordination in Mobile Agent Applications

In mobile agent applications, one of the fundamental activity is letting an agent interact with the entities it encounters during its activity, let these entities be the hosting execution environments or other agents. More in particular: • a mobile agent is usually in need to roam across a network to access to remote resources and services allocated on some node of the network; • multi-agent applications can be composed by several mobile agents that cooperatively perform a task and, then, are in need of coordinating their activities. While the above coordination issues have been extensively studied in the past, mobility and the openness of the environment imply new problems and needs. In this section, we introduce a simple taxonomy of the possible coordination models for mobile agent applications, together with the proposals of several mobile agent systems (see figure 1). The fundamental point for the acceptance of a mobile agent proposal is the definition of efficient, adaptive, easy to implement and secure coordination models. Indirect

Direct

Client-Server

Odyssey

(blackboard)

Rendez-vous

Agent TCL Sumatra

Reactive

Passive

Jada ARA

ffMAIN

None?

Ambit

Figure 1. Coordination Models for Mobile Agents Interaction

We emphasize that mobile agent applications can exploit different coordination models in their execution. In fact, they can adopt one model to coordinate an agent with the other agents and a 5

different model to interact with the hosting execution environments. To our opinion, however, the best choice is to adopt a single model for both agent-to-agent and agent-to-local execution environment interactions, to reduce the complexity of mobile agent applications and simplify the programming task. The following sub-sections detail the two main classes of coordination models we identified: direct and indirect ones.

3.1 Direct Coordination In direct coordination models, agents interact both with each other and with the resources they need by explicitly initiating a communication. In other words, when an agent needs to interact, it must explicitly name the partner of communication. In the case of agent-to-agent coordination, two agents must agree on a communication protocol, typically a client-server one. In the case of the access to the local resources of the hosting environment by means of a mobile agent, coordination typically occur in a client-server way: the hosting environment provides local servers for the management of its resources; the agent requires a given service supplying the needed parameters (among which, if needed, the code of the service itself [StaG90]) and waits for an eventual reply. The first significant advantage of a direct coordination model is to permit full control of the programmer over a distributed application: communications are directly issued and are not influenced in their semantics by external entities (i.e. the hosting execution environments). In addition, the intrinsic efficiency of the paradigm achieves fast (compatibly with the actual network bandwidth) and of low overhead interactions. Finally, the capability of an agent to dynamically link services to a server local to one execution environment provides the needed degree of flexibility and adaptivity required in a heterogeneous and dynamic environment as Internet. In presence of widely mobile agents, direct coordination models present several drawbacks with regard to agent-to-agent interaction. Making two mobile agents communicate, in fact, introduces the need of localizing them, by means of complex routing schemes and eventual residual information left onto the nodes the agents cross during their execution. Furthermore, repeated interactions require a stable network connection, making communication highly dependent on network reliability, nullifying one of the advantages of the introduced agent mobility. A possible solution is to adopt a coordination model for agent-to-agent interaction that constrains the rendez-vous model to represent not only a temporal synchronization but also a spatial one: two agents can communicate only when they co-reside on the same execution environment. This constrained rendez-vous model solves the problems related to agent location but can limit the autonomy of the agents and can make the risk of missing meetings very high, especially in presence of a highly unreliable network. In both solutions – client-server style and rendez-vous style – letting agents directly communicate with each other is not secure, because of the lack of control of the hosting execution environments over the hosted executions. A direct coordination model, then, is suited only to manage the access to the local resources of the execution environment, by supposing the capability of the server to accept dynamically provided services. Note also that, in this case, interactions can be intrinsically controlled by the hosting systems to enforce security. However, the adoption of a direct coordination model for agent-toresources interactions and the almost forced adoption of a different model for agent-to-agent interaction leads to a heterogeneous coordination scenario that, if possible, should be avoided to limit complexity. Extensions of the Java system toward agent-mobility – like Sumatra [AchRS97] and Odyssey [Gen97] – adopt the message passing typical of object systems. At a higher level, the client-server coordination model typical of the object-oriented model can be exploited for all kinds of interactions, even between remote objects via RMI [Sun97]. At a lower level, they can directly exploit the TCP/IP 6

protocol that, though very flexible, is complex to program and requires the precise definition of a coordination protocol. Agent Tcl [Gray96] provides direct communication between two agents. This can be achieved either by an asynchronous message-passing mechanism – an agent sends a message to a given partner agent, using the agent_send command; the receiver retrieves this message when it executes an agent_recv command – or by establishing a synchronous (not locally constrained) meeting – via the agent_meet command. The interaction of an agent with the resources of the hosting environment simply relies on UNIX primitives. Ara [PeiS97] encourages – though it does not strictly enforce – a constrained rendez-vous model for agent-to-agent coordination. Agents can interact when they are co-residing: an agent assumes the role of server and announces a meeting point (i.e., a location in the hosting environment), called Service Point, where client agents can ask for services. Local servers that define permanent meeting points can be used for the management of the local resources.

3.2 Indirect Coordination In indirect coordination models, agent interactions occur via blackboards, residing on each hosting environment, which are used as information spaces where to locally store and retrieve messages. The most significant advantage of indirect coordination models is to achieve both spatial and temporal uncoupling in agent-to-agent interactions: when two agents need to exchange data, a sender can simply leave a message in the local blackboard, without needing to know neither where the corresponding receiver currently is, nor when it will read the message; the receiver, by its side, can go on with its execution and read the message at a proper time, when moving on the corresponding execution environment. This clearly suits a scenario where the position and the scheduling of the agents cannot be easily granted. In addition, being any agent-to-agent interaction forced to be performed via the blackboard, the hosting environment can easily monitor and control all interactions, thus leading to a more secure execution model. Furthermore, the accesses to the blackboard can be based on associative mechanisms, in a Linda-like fashion [CarG89]: data can be retrieved on the basis of a pattern-matching scheme, without the need of explicitly naming the stored data (for example by associating unique keys to them) but, instead, by accessing to it by its content. The well-known advantages of associative coordination models [GelC92] particularly suit mobile agent applications. In fact, because of the dynamicity and the wideness of the Internet environment, having a complete and updated knowledge of hosting execution environments may be difficult or even impossible, also because of the lack of a centralized control. Then, because pattern-matching mechanisms would be somehow necessary to an agent to deal with the above heterogeneous and dynamic scenario, it may be convenient to integrate these mechanisms directly in the coordination model itself. This simplifies the task of agent programming and reduces the complexity of mobile agent applications. A reactive blackboard model can provide the capability of issuing programmable reactions in response to the accesses made to a blackboard by agents. In particular, the administrator of the local site should decide which type of events should be handled and the corresponding handlers (i.e., the reactions). This can provide several advantages. First of all, it can be used to implement specific local policies for the interactions between the agents and the hosting execution environment, to achieve better control and defend the integrity of the environment from malicious (or badly programmed) agents. In addition, it can adapt the semantics of the interactions to the specific characteristics of the hosting environment, thus simplifying the task of agent programming much more than the fixed pattern-matching mechanism of Linda. Finally, a reactive blackboard can be used to implement specific resource management policies to achieve better efficiency in agent execution. A possible drawback of indirect coordination models, and of the reactive one in particular, is that they may require a large amount of execution resources on the hosting environment. However, 7

we feel that these execution resources will be somehow saved from the execution of mobile agents, whose code can be simplified due to the associative (reactive) blackboard. Another drawback of these models is that they can sometimes let the programmer lose control over the execution of his/her applications. Nevertheless, this problem should be less evident in case of reactive programmable blackboard, if one can provide the capability for the programmer to dynamically link his/her own coordination rules onto the hosting execution environments. The above discussion also shows that, differently from direct coordination models, indirect coordination permits the adoption of a single model for both agent-to-agent and agent-to-local resources interactions. Several systems propose and implement indirect coordination models for mobile agent applications. Ambit [CarG97], a recently proposed formal model for mobile computations, introduces the concept of indirect agent-to-agent coordination: a mobile entity, while roaming through the network, can "attach" a named message to a given system, like a post-it; another entity can retrieve and read this message. No associative access to a data space is modeled. The ffMAIN agent system [DomLD97] defines mobile agents that interact – both with other agents and with the local resources of the hosting execution environment – via an information space accessed through the HTTP protocol, where data can be stored, read and extracted. However, the access to the data is not based on any associative mechanism but, instead, each data item must be identified by a unique key. The concept of associative blackboard has been implemented, atop of Java, in the Jada system [CiaR97]: the so called ObjectSpace abstraction can be used by mobile agents to store and retrieve objects references in an associative way, i.e., by class name; furthermore, agents can create private ObjectSpaces on the hosting execution environments to be used by the agents within an application to interact without affecting the hosting execution environment. Note that, being Jada an extension of Java, interactions may also occur directly in an object-oriented fashion, as shown in subsection 3.11. To the best of our knowledge, models and implementations of reactive blackboards have been proposed only in the artificial intelligence area (an interesting example is the ACLT programmable coordination media [Den96]), but never in the one of mobile agents systems, though the capability of the Jada system of dynamically creating private interaction spaces is an interesting step in that direction. Also researches in the area of active networks [Ten97], that aim to enhance the capabilities of network components by dynamically pushing software modules on them, adopt a similar, though special-purpose, approach.

4

Application example: an Agent-based Information Retrieval System

The application we assume as testbed to evaluate the different mobile agent coordination models relates to World Wide Web information retrieval. The application scenario is as follows. Let information be stored in HTML documents spread over Internet and the user be interested in all HTML documents that includes one specific keyword. The user knows one site (to be used as starting point for the search) where to find interesting (i.e., matching the keyword) documents. From there, other sites containing further interesting information can be found. Typically, a larger number of related sites can be reached by following the links contained in HTML documents.

4.1 Traditional (Non Mobile) Design The traditional approach to retrieve information in HTML documents is based on a client-server mechanism: the user asks for a page to the server, retrieves the document, analyses it and then

1

This possibility is not shown in figure 1 for sake of simplicity.

8

“manually” follows the links found in the document (i.e., she/he clicks on it) that are supposed to be of interest (i.e., pointing to pages containing the keywords) and so on, in a recursive way2. The intrinsic inefficiency of the above approach is evident: • the user is forced to analyze a large amount of data, with a great waste of time, among which only a little portion could be of interest to her/him; • the need of transferring data locally causes a great waste of bandwidth and slows down the analyses of the documents; • the unreliability of network connections (or the total lack of connectivity) is likely to make a large number of accesses to given sites fail, thus requiring several attempts before completing the analysis of the documents on those sites. Though it is clear that the above search has not to be necessarily “manual” (a local process can be simply programmed to follow all the link starting from a page in a recursive way), its execution causes waste resource and requires a high completion time (if it ever completes).

4.2 The Mobile Agent Design The design based on mobile agents can make the application more efficient and reliable. The basic idea is to move a searching agent locally to a site, let it locally analyzes the stored documents and follows the interesting links by cloning itself.

User site Root agent

HTML

Link

HTML

Link HTML

Figure 2. The user sends the root agent to a specific site

The application starts by making the user create a first agent (root agent) and send it to a specific site (see figure 2), with the goal of analyzing the HTML pages there allocated and yielding back the URL of the pages of interest, i.e., the ones containing the keyword. When the root agent finds an interesting document containing links to other sites, the agent, before returning back to the user site, creates a new agent (with the same code) for any link to follow (see figure 3). The new agent is sent to the assigned remote site and can recursively create further agents. In this way, agents are organized in a tree. To avoid endless agent generation (and, then, a possibly never-ending application that would cause an increasing number of agents to be thrown over Internet), we can take into account the depth of the agents’ tree via a non-negative integer value, called level, that represents the distance of an agent from the root agent in the tree. The user can fix a maximum level Lmax, to avoid agents at level Lmax to create further agents. 2

Obviously, we do not consider the existence of search engines (such as Altavista and Yahoo) that would make the application goal trivial. However, we emphasize that today’s search engines retrieve information in the clientserver way we have described.

9

User site Cloned agent HTML

Root agent Link

Cloned agent

HTML

Link HTML

Figure 3. An agent creates new agents, sends them to visit sites pointed by links and comes back to the user site

// state variables String keyword; // keyword to search for int level, Lmax; // current and max level of search URL starting_site; // next location to visit URL user_site; // location to come back to when finished URL found_info[]; // information found on current host URL found_links[]; // related links found on current host

// code agent.go(starting_site);

// root agent is sent

found_info = agent.ask_for_info(keyword); if (found_info.size == 0) agent.go(user_site);

// search for information

// if no information is found

// the agent comes back

else found_links = agent.ask_for_links(keyword); // search for related links if ((level < Lmax) and (found_links.size > 0))

// there are links

for (i = 0; i < found_links.size; i++) // a new agent for each link {

starting_site = found_links[i]; new_agent=agent.clone(keyword, starting_site, level+1, Lmax, user_site);

} else agent.go(user_site);

// the agent comes back

Figure 4: Pseudo-code of the searching agent

10

We can describe more in detail the application and the agent activities as a simple five-step algorithm (see figure 4). In the first step, the user creates a root agent and initializes it with some parameters: the keyword it has to search for, the starting site to visit, the agent level, the maximum search level (Lmax), and the user site. The keyword is chosen by the user, on the basis of her/his own search criteria. The starting site can be decided by the user or by a network directory service. For the root agent, the level parameter is automatically set to zero. The maximum level is chosen by the user, depending on how much information she/he wants to retrieve; this parameter could take into account several factors, such as statistic knowledge of network traffic and tolerated waiting time. Finally, the user site is necessary to any agent to yield back the results of its search. The second step starts when the agent reaches the starting location. Here, it exploits some local mechanisms to retrieve information. If no interesting HTML pages are found, the agent comes back to user site. The mechanisms by which to access to the local resources, that are dependent on the adopted coordination model, will be analyzed and discussed in the following section. The third step is executed only if interesting pages are found and it is the core of the search algorithm. In HTML pages, an agent can find links to other sites that are supposed to contain related or similar information. Then, if the agent has not yet reached the maximum depth of the search, i.e., its level is lesser than Lmax, it creates a new agent for each link it finds and delegates it the search in the site pointed by the link. The new agent shares the same code and is initialized with the same keyword, the same maximum depth of search and the same user site, while the starting location is set by the link. In addition, the value representing the level in the tree is incremented by one respect to the creator agent. In the fourth step, each newly created agent reaches the assigned location and starts a local search there (as in the second step). The creator agent, by its side, yields back to the user site the URLs of the documents found so far. Finally, in the fifth step, the information carried on by each agent that comes back to the user site are collected (possibly by a graphical interface) and presented to the user as soon as it arrives. A possible design alternative can let an agent, when M links are found, create only M-1, instead of M, new agents and follow itself one of the interesting links. This reduces the number of agents within an application but delays the arrival of useful information to the user, because an agent visits several sites before coming back to the user. Another design alternative to decrease the number of agents is to limit the maximum number of links to be followed, i.e., the branching factor of the tree. None of the above alternatives, however, changes the basic search algorithm. Instead, it is of interest the study of the design alternatives that can be adopted depending on the chosen coordination model.

5

Design Alternatives for Coordination in the Application Example

The above application analysis disregards coordination issues. A first one relates to agent-toagent interaction and aims to avoid multiple visits on the same site. In fact, it is common to find cross references in HTML pages: if sites A and B contain similar information, it is highly probable that pages in A contains links to pages in B and viceversa; in some cases, more complex circular chains (i.e., composed of several intermediate links) can be found. These would make application agents visit several times the same sites, thus duplicating searches and wasting time and resources. A second coordination issue relates to agent-to-site interaction and aims to define a precise way an agent can require and retrieve information on a site. The trivial solution of letting an agent directly accesses the local system resources without any control is not advisable, because of its evident lack of security. The above problems can be addressed in different ways. We explore four design solutions, each one using a different coordination model. They are:

11

• client-server: agents coordinate with each other by in client-server way; also the local resources on a site are accessed via a local server in a client-server fashion; • rendez-vous: agents coordinate with each other by meeting each other on a site; local resources are again accessed in a client-server way; • passive blackboard: agents coordinate with each other by leaving messages on blackboards local to each site; local resources are retrieved on the basis of information provided by the local site in the blackboard; • active blackboard: as in the passive blackboard model, except that a local execution environment can define its own coordination rules, as described in the following.

5.1 Client-Server The adoption of a direct coordination model based on the client-server model does not suggest an immediate design solution to deal with agent-to-agent interactions. As explained in section 3.1, agents cannot know where other agents are and, then, they cannot communicate directly each other without the support of complex routing mechanisms. Furthermore, in the application example, obstacles to the use of direct coordination come also from the fact that the application agents cannot know how many other agents are in the application, because agents are dynamically created depending on the found links. Starting from the above considerations, if we still want to adopt a client-server style of coordination we must introduce some “ad hoc” application entities to deal with agent-to-agent communication3. For example, we could chose a site, that could be the user site, where a fixed entity assumes the role of communication management server (see figure 5). Whenever an agent finds a site containing interesting information, it asks this server if the site has already been visited; in positive case, the agent comes back to the user site without further investigation in that site, otherwise its duty is to inform the communication server to mark the site as visited. Adopting this solution, since agents communicate only with a fixed (non-mobile) entity, there is no need of special routing scheme.

HTML

A

B

D Communication server HTML

Visited B C

C

User site

Figure 5. Client-server solution: each agent refers to the master site

3

In fact, no one has rights to impose above Internet a special-purpose (oriented to mobile agents) routing protocol.

12

The proposed design solution does not need sophisticate mechanism to be implemented. The client-server model is a well-known and wide-exploited one, so that this solution results quite familiar to distributed application programmers. As mentioned in section 3.1, the implementation of client-server model gives full control to the programmer over the application, and it does not produce a relevant intrusion in the visited hosts. However, in the above solution, a large number of messages are exchanged between the application agents and the communication server: this produces high traffic on the network and makes the communication server a centralization and an evident bottleneck point. Furthermore, the solution also requires reliable network links to work correctly. On the one hand, if we decide to block agent execution until the connection to the server is available, the server itself is made a critical failure point, because when the master site is down, the entire application is blocked. On the other hand, if an agent cannot communicate with the master site, due to network unavailability, one could think to ignore the problem and let the agent execution proceed even without knowing whether the current site has already been visited on. If this may seem an elegant solution for the problem, we have to consider that a significant subtree of pages can depart from a site; then, duplicating a visit on one site may mean to duplicate the search in the whole subtree, wasting bandwidth, execution resources and time. As a final note, we emphasize that the proposed design solution exhibits two aspects of evident contradiction: • it exploits the mobile agent technology to face the problem with a client-server-like design paradigm; • it exploits the direct coordination model to realize a communication server where agents exchange information in an indirect way. With regard to agent-to-local execution environment, this solution does not require particular mechanisms to let the agent interact with the hosting environment: traditional mechanisms, such as local HTTP servers, may simply provide to supply HTML pages and analyze their content.

5.2 Constrained Rendez-vous The constrained rendez-vous coordination model makes possible for two agents to interact only when they are co-residing. To exploit this coordination model, we can introduce an additional “marker” agent for each visited site. When an agent has explored a site, instead of leaving the site unattended, it creates an additional clone before coming back to the user site. The created marker agent will be forced to reside on the creation site to keep track of the visit. If any other agent arrives to this site, it can check the presence of the marker agent and, then, being noticed that the site has been already visited. This design solution dramatically decreases network traffic compared to the client-server one, because all communications take place between co-residing agents. In addition, the solution is fully distributed and avoids the presence of any centralized control, that could be a bottleneck and a weak point for the entire application. Finally, the rendez-vous solution could also easily lead to more sophisticated policies for agent coordination. For example, the marker agent could also keep track of the last visit time to give the capability to further incoming agent of incrementally retrieve data, i.e., to retrieve only those HTML pages that have been modified or added since the last visit. Nevertheless, the rendez-vous solution forces an agent to remain on each visited site. This leads to several drawbacks. First of all, an agent is an intrusive entity on the host system that tends to consume resources even when idle. In addition, in the proposed application, there is no possibility for the marker agent of knowing when it can leave the site (or simply die) because the other agents do not need its presence anymore (at least, this could be known by the user site at application completion). A second important drawback relates to security: it is not advisable to let an agent remain on one execution environment for a long time: a malicious agent could exploit this time to capture and transmit private information to the external or to discover security holes in the system. 13

Agent-to-local execution environment coordination can occur as in 5.1.

5.3 Passive blackboard In the adoption of an indirect coordination model, we assume the presence of a local blackboard on every site of the system, which can be used by agents to store, retrieve and extract data. Let us describe how the application example can exploit the blackboard model for both agentto-agent and agent-to-execution environment coordination. When an agent arrives on a site, to avoid multiple visits, it firstly checks in the blackboard for a “marker” message, coming from another agent of the same application. For example, a message could be a tuple in the following format: (User “[email protected]”, keyword “word_to_search”, visit_time 09/27/1997:23.51)

where the first field uniquely identifies either an application or a user, the second field is the keyword string upon which the search has been based, the third field specifies the date and time of the last visit. If the agent obtains the message, it knows that this site has been already visited. If the message is not found, the agent itself is in charge of putting in the blackboard a marker message. Note that, in this example, peculiar associative mechanisms may not be necessary because agents know exactly which message to retrieve from the blackboard. For instance, the field that uniquely identifies one application can be used as unique key for the message. However, let us suppose that our application is composed of several classes of agents, with each class devoted to a search for a peculiar keyword. In this case, an associative mechanism is necessary: when an agent arrives onto a site, it has to check in the blackboard for the presence of marker messages with keyword field that matches the agent’s own keyword, while ignoring those messages that (though belonging to the same application) have been left by agents searching for different information, i.e., having a different keyword. With regard to the interaction of mobile agents with the local environment, an associative blackboard can be effectively exploited to let the agent retrieves the needed information without requiring the presence of a specialized resource manager and to let the local environment provide in the blackboard all the data it wants to publish while protecting private area. In the stated application, we can suppose, for example, that the blackboard makes available to incoming mobile agents the pathnames of all publicly readable files, in tuples having the following structure: (string “pathname”, type “file_extension”, int dimension, date last_modified)

Then, agents can simply look for all tuples in which the type field matches the “HTML” string. As a first concrete advantage applying of this coordination model in the application example, it obviously produces less network traffic than the client-server one. Besides, it relies neither on agent schedules nor on their movements, as stated in section 3.2, and then it suits well a wide distributed system. The blackboard solution is also more secure and efficient than the rendez-vous one. In fact, no agent has to remain active on the visited sites: only passive messages have to be left. We state that this is a fundamental difference, because it avoids the security risks pointed out for the rendezvous approach and limits the amount of wasted resources. In addition, forcing agent-to-agent interaction via the blackboard permits the execution environment to achieve full monitoring capability over them: no interaction can occur without giving the blackboard of detecting it. The possible drawbacks of the blackboard approach, especially if the blackboard integrates a native associative mechanism, are to require resources and to give agents less control in their interactions, as stated in section 3.2. To our opinion, the former problem can be compensated by the lighter agent code that the associative blackboard would allow, while the latter can be easily solved with the availability of a reactive blackboard, as shown in the next section.

14

5.4 Reactive blackboard The reactive blackboard coordination model does not force significant changes in the application design w.r.t. the previous, passive blackboard, one. However, the introduction of reactivity in the blackboard management (to mean that a blackboard is no longer a mere message repository but it has its own state and can react to the accesses with specific actions depending on its state and on the stored content), can provide further flexibility. As a first example, let us suppose one hosting execution environment be a local WWW server whose HTML pages are replicated in one or several mirror sites. In this case, when an agent visit the site, not only other agents of the same application must avoid further visit on the same site, but they should also avoid visits to the mirror sites. In this case, the local blackboard can be programmed to react to the local events in order to coordinate with mirror sites and there replicate the agents’ marker messages. The administrator of one site could also decide to exploit blackboard reactivity to delete the marker messages locally left by agent, on the basis of a maximum lifetime. In our application, this could be very useful, because of the intrinsic difficulty, for the application agents, to know whether a marker message on a visited site is further needed to other application agents. Then, a reactive blackboard could assume this “garbage collection” duty on the basis of a local policy, which aims to enforce the integrity of the local environment. One of the general drawbacks of the reactive blackboard model pointed out in section 3.2, i.e., the weaker control of one application over its own interactions, is evident in this example: the blackboard can decide to delete marker messages, thus disturbing the application and possibly making agents visit multiple times the same site. Nevertheless, we feel the wide acceptance of mobile agent applications and environments is much more dependent on the capability of protecting the hosting execution environments from the agents rather than protecting agents from being disturbed by the environment (though both aspects are important). By increasing the complexity of the example further, let us suppose the hosting execution environment has the capability of recognizing the agents’ identities and, in particular, of detecting whether two agents belongs to the same application or not4. In this case, to avoid waste of local resources, the local administrator of a reactive blackboard can decide to deny the access to the HTML tuples (pretending no such tuples are present) to those agents that arrive to the site when other agents of the same application have already visited it. Note that, in this case, the agent code can be simplified, because agents are no longer in need of actively putting marker messages in the blackboard or to check for their presence: this activity is charged to the blackboard. This makes evident one of the advantages pointed out in section 3.2, i.e., the capability of reactive blackboards to lighten the code of the agents. A further degree of flexibility could derive from giving the agents of an application the capability of deciding their own coordination rules, by defining reactions to be distributed onto the blackboards of the hosting execution environments. These coordination rules could assume the form of simple high-level directives specified in the application definition [CorLZ97]. Anytime an agent arrives to a hosting execution environment, the effect of one directive is to install an application specific reaction in the local blackboard. Further accesses to the blackboard by means of agents of the same application will raise the reaction. In the application example, a incremental_visit directive associated to the agent could provide to install into the visited blackboard a reaction that denies to further incoming agents the access to those HTML tuples whose corresponding pages have not been modified since the last visit. Note that the above directives can be clearly separated from the agent code and, instead, become a general specification for the application: this enforces separation of concerns between algorithmic issues and coordination ones [GelC92].

4

We emphasize the presence of authentication mechanisms in an open distributed system does not represents a heavy assumption but it is rather a matter of fact.

15

Agent 1

Agent 1 Agent 2

Reaction a

b

c

Figure 6. When an agent arrives to a site (a), it installs to the local blackboard the application specific reaction (b). Further incoming accesses (c) will raise the reaction

Summarizing, a reactive blackboard model exhibits all of the advantages of the passive blackboard one: low network traffic, uniform model for agent-to-agent and agent-to-resources interactions, control of the execution environment over all interactions. Furthermore, it adds the very important features of permitting local execution environments to locally influence the coordination rules and application agents to spread over remote execution environments their own coordination rules. The former feature increases the safety and the security of the execution environments. The latter leads to more flexible and lighter mobile agent applications. The above advantages are likely to overcome the drawback of a higher implementation cost.

6

Conclusions and Future Work

The paper addresses the problem of mobile agent coordination in widely distributed applications: it surveys the possible coordination models and evaluates their impact in the design of an application in the area of distributed information retrieval. The analyses outlines the peculiar advantages of coordination models based on indirect communication and shows the limits of traditional coordination approaches in distributed systems. Moreover, the paper points out the urge for coordination models based on the definition of reactive and programmable blackboards. We feel the issue of coordination in the context of mobile agent technology worth further study. On the one hand, the effectiveness and the applicability of indirect coordination models need a stronger validation by evaluating their impact on further applications in different areas. On the other hand, validation must also pass through efficient and easy to program implementations of reactive blackboard models. These researches must have the final goal of defining a well-accepted standard for mobile agent execution and coordination. To our side, we are currently implementing a first prototype of an active blackboard atop of a Java-based mobile agent system [MOON97] and we are trying to define a simple high-level language for associating programmable reactions to local blackboard events [Den98].

7

References

[AchRS97] A. Acharya, M. Ranganathan, J. Saltz, “Sumatra: a Language for Resource Aware Mobile Programs, Mobile Object Systems, Lecture Notes in Computer Science, No. 1222, Springer Verlag (D), pp. 111-130, February 1997. [Adl95] R. M. Adler, ‘Distributed Coordination Models for Client-Server Computing’, IEEE Computer, Vol. 29, No. 4, April 1995, pp. 14-22. [BalGP97] M. Baldi, S. Gai, G. P. Picco, “Exploiting Code Mobility in Decentralized and Flexible Network Management”, Proceedings of the 1st International Workshop on Mobile 16

Agents, Berlin (D), Lecture Notes in Computer Science, No. 1219, Springer-Verlag (D), pp. 13-26, April 1997. [BhaC95] K. Bharat, L. Cardelli, "Migratory Applications", Proceedings of the ACM Symposium on User-Interface Software and Technology '95, pp.133-142, 1995. [Bie98] A. Bieszczad, “Network Management Applications-Oriented Taxonomy of Mobile Code”, To Apper in the Proceedings of the 1998 IEEE/IFIP Network Operations and Management Symposium, IEEE CS Press, February 1998. [CaiGN96] T. Cai, P. Gloor, S. Nog, “DataFlow: A Workflow Management System on the Web Using Transportable Agents”, Technical Report No. TR-96-283, Department of Computer Science, Dartmouth College, Hanover (NH), 1996. [Car95] L. Cardelli, “A Language with a Distributed Scope”, Computing Systems, Vol. 8, No. 1, MIT Press, 1995, pp. 27-59. [CarG89] N. Carriero, D. Gelernter, “Linda in Context”, Communication of the ACM, Vol. 32, No. 4, pp. 444-458, 1989. [CarG97] L. Cardelli, A. D. Gordon, “Mobile Ambient”, (available at http://www.research.digital.com/SRC/personal/Luca_Cardelli/Ambit/Ambit.html), 1997. [CarPV97] A. Carzaniga, G. P. Picco, G. Vigna, “Designing Distributed Application with Mobile Code Paradigms”, Proceedings of the 19th Conference on Software Engineering, ACM Press, pp. 22-32, 1997. [CheHK97]D. Chess, C. Harrison, A. Kershenbaum, “Mobile Agents: are They a Good Idea?”, Mobile Object Systems, Lecture Notes in Computer Science, No. 1222, Springer-Verlag (D), pp. 25-45, February 1997. [CiaR97] P. Ciancarini, D. Rossi, “Jada - Coordination and Communication for Java Agents”, Lecture Notes in Computer Science, Springer-Verlag (D), No. 1222, 1997, pp. 213-226. [CorLZ97] A. Corradi, L. Leonardi, F. Zambonelli, “High-Level Management of Allocation in a Parallel Object Environment”, to appear in The Journal of Systems Architecture, 1997. [Cug97] G. Cugola, C. Ghezzi, G. Picco, G. Vigna, “Analyzing Mobile Code Languages”, Mobile Object Systems, Lecture Notes in Computer Science, No. 1222, Springer-Verlag (D), pp. 94-109, February 1997. [Den96] E. Denti, A. Natali, A. Omicini, “An Extensible Framework for the Development of Coordinated Applications”, Proceedings of Coordination ’96, Lecture Notes in Computer Science, Vol. 1061, Springer Verlag (D), 1996, pp. 305-320. [Den98] E. Denti, A. Natali, A. Omicini, “On the Expressive Power of a Language for Programmable Coordination Media”, Proceedings of 1998 ACM Symposium on Applied Computing, Atlanta (G), Feb. 1998. [DomLD97]P. Domel, A. Lingnau, O. Drobnik, “Mobile Agent Interaction in Heterogeneous Environment”, Proceedings of the International Workshop on Mobile Agents, Lecture Notes in Computer Science, Springer-Verlag (D), No. 1219, April 1997, pp. 136-148. [GelC92] D. Gelernter, N. Carriero, "Coordination Languages and Their Significance", Communications of the ACM, Vol. 35, No. 2, Feb. 1992, pp. 96-107. [Gen97] General Magic Odissey Page, http://www.genmagic.com/agents/odyssey.html [Gray96] R. Gray, “Agent Tcl: A flexible and secure mobile-agent system”, in Mark Diekhans Mark Roseman editor, Proceedings of the fourth Annual Tcl/Tk Workshop (TCL ’96), Monterey, California, July 1996. [Jul88] E. Jul et al., “Fine Grained Mobility in the Emerald System”, ACM Transactions on Computer Systems, Vol. 6, No. 1, pp. 109-133, Feb. 1988. [Lim96] A. Limongiello et al., “Orchestra: an Experimental Agent-based Service Control Architecture for Broadband Multimedia Networks, Proceedings of GLOBAL Internet ’96, November 1996.

17

[Luc96]

Lucent Technologies, “The Inferno Home Page”, http://inferno.belllabs.com/inferno/index.html [MA97] “Proceedings of the 1st International Workshop on Mobile Agents”, Berlin (D), Lecture Notes in Computer Science, No. 1219, Springer-Verlag (D), April 1997. [MOON97] The MOON Home Page, University of Modena, http://sirio.dsi.unimo.it/MOON [MOS97] “Mobile Object Systems”, Lecture Notes in Computer Science, No. 1222, Springer Verlag (D), February 1997. [PeiS97] H. Peine, T. Stolpmann, “The Architecture of the Ara Platform for Mobile Agents”, Proceedings of the 1st International Workshop on Mobile Agents”, Berlin (D), Lecture Notes in Computer Science, No. 1219, Springer-Verlag (D), pp. 50-61, April 1997. [ShiKS92] N. G. Shivaratri, P. Krueger, M. Singhal, “Load Distributing for Locally Distributed System”, IEEE Computer, Vol. 25, No. 12, pp. 33-44, Dec. 1992. [StaG90] J. W. Stamos, D. K. Gifford, “Implementing Remote Evaluation”, IEEE Transactions on Software Engineering, Vol. 16, No. 7, pp. 710-722, July 1990. [Sun94] “The Java Language: A White Paper”, Sun Microsystems White Paper, Sun Microsystems, 1994. [Sun97] “Remote Method Invocation”, Sun Microsystems White Paper, Sun Microsystems, 1997. [Ten97] D. Tennenhouse et al., “A Survey of Active Network Research”, IEEE Communications, Vol. 35, No. 1, pp. 80-86, Jan. 1997. [Wal97] J. Waldo et al., “A Note on Distributed Computing”, Mobile Object Systems, Lecture Notes in Computer Science, No. 1222, Springer Verlag (D), pp. 49-64, February 1997.

18