Cooperation Strategies for Agent-Based P2P Systems

Loris Penserini1*, Lin Liu2, John Mylopoulos2, Maurizio Panti1, Luca Spalazzi1 1 Computer Science Institute – University of Ancona

1 Via Brecce Bianche, 60131 – Ancona, Italy 1 { pense,panti,spalazzi} @inform.unian.it

2 Computer Science Department – University of Toronto

2 40 St. George Street, M5S 2E4 – Toronto, Ontario, Canada 2 { liu,jm} @cs.toronto.edu

Abstract.

We are interested in peer-to-peer (P2P) computing, where a P2P application consists of a (wireless) network of nodes (peers), and assumes full peer autonomy, no global control, and intermittent connectivity. P2P computing has many advantages over classical client-server and web-based distributed architectures. However, the P2P computing model also has a number of limitations in the mechanisms it supports for data management and interchange. To overcome some of these, we propose an agent-based P2P model whose nodes are software agents (peer agents). This paper uses the i* modeling framework to analyze and evaluate peer agent cooperation strategies using three possible evaluation criteria. Keywords. Multi-Agent Systems, Peer-to-Peer Computing, Requirements Engineering, Information Coordination

* Contact author information: (phone) +39 071 220.4897, (fax) +39 071 220.4474.

1. Introduction

Recent developments in communication technology and devices such as PDA, mobile phones, local area wireless network communications, etc., has made it possible for a message to reach anybody, anywhere, at anytime. To turn this possibility into a reality, we need new collaborative and distributed computing models. Consequently, there is great demand for research on information coordination and integration mechanisms among heterogeneous, distributed, and dynamic information sources. In addition, more research is focusing on peer-to-peer (P2P) networks, which consist of an open, evolving network of peers. P2P networks support mechanisms that allow end users to participate in distributed information networks without much technical support and heavy-handed computing platforms [3] [8] [14]. For example, [3] proposes an extended relational model for P2P databases that supports distributed query processing and constraint enforcement. A list of typical application domains for P2P computing includes:

Distr ibuted health care involving physicians, small family clinics, pharmacies, patients, etc. (small operative units). Often, such units are not connected to hospital centers and are characterized by weak technological infrastructures and know-how. These small operative units form a collection of highly decoupled and autonomous partners that regularly need to collaborate and exchange patient information.

Small and medium enterpr ises (SMEs) participating a virtual enterprise in order to offsetting lack of resources and know-how. Through networking and collaboration, SMEs can cover in a synergistic way all phases of product/service lifecycle. This means that they can meet customer requirements in a global market, and still focus on their own core business.

Crisis management involving situations such as hospital emergencies, natural disasters, hazardous environments, etc. Such situations are characterized by open-ended sets of players, working together to achieve a shared goal.

Such generic applications, and many others, can be characterized in terms of a set of peers working autonomously and exploiting coordination with each other

in order to achieve common goals. In such settings, a central authority constitutes a bottleneck and may break down the system completely, e.g., when control commands are sent out in a sequential manner introducing arbitrary delay and the possibility of a system failure at the command post.

The P2P paradigm was popularized by systems such as Napster and Gnutella. P2P computing generally assumes that each peer is acquainted with a small number of other peers with whom it can exchange information and services. Acquaintances change constantly, there is no central control/registry, and peers remain autonomous throughout their participation in a P2P network/coalition.

Despite its promise, the P2P framework suffers from a lack of mechanisms for managing data exchanged among peers (e.g., [8]). In particular, existing systems limit themselves to very special types of data (e.g., MP3 files) and simple mechanisms for identifying and exchanging them (see also §2.1 for more details).

To overcome these limitations and to enhance information coordination in P2P coalitions, we have proposed an agent-based P2P system model [13] [14], where the capabilities of each peer (peer agent) are distributed among several abstract roles, e.g., wrapper, mediator, facilitator, and planner. However, because of intermittent connections and the lack of global visibility, peer behavior may be unpredictable, requiring different cooperation strategies on the part of a given peer.

In this paper, we adopt the i* modeling framework to help with the modeling and evaluation of peer agent cooperation strategies. The i* framework is designed to model intentional relationships among agents [18] [20] [21]. In i* , actors have full freedom of action, but operate within the constraints of a network of social relationships. Specifically, they depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. This paper models alternative cooperation strategies as tasks. In addition, the failures to be avoided are modeled as softgoals. Softgoals are used to model quality attributes for which there are no a priori, clear-cut criteria for satisfaction, but are judged by actors as being suff iciently met (‘satisf iced’) on a case-by-case basis [20] [21]. Moreover, in order to allow a peer agent (the planner) to choose an optimal strategy related to a specific failure symptom, evaluation criteria are required. Although, the highly dynamic nature of P2P coalition complicates such an evaluation procedure, we propose three possible evaluation approaches in order to characterize the best strategy related to a particular failure symptom. Note that this paper does not address architectural issues for a peer agent. Instead, it focuses on the modeling and analysis of the system in terms of actors, their relationships, goals to be achieved, and tasks to be performed.

The paper is organized as follows. The next section introduces the two main background areas of this work – P2P computing and the i* modeling framework. Section 3 discusses the reference model for the peer agent architecture and its characteristics. Section 4 illustrates how to use Strategic Rationale model to evaluate different cooperation strategies. Section 5 introduces the qualitative, scenario-based, and quantitative approaches to evaluate cooperation strategies. Section 6 shows an example of adopting all three evaluation methods and presents some results. Finally, Section 7 draws conclusions and discusses future research directions.

2. Background

2.1 Peer-to-Peer computing

Both [5] and [11] predict that P2P computing is the next technological breakthrough, after the Web and the e-mail, that will also improve the use of Internet technology. Other forms of P2P networking have been in use within and among enterprises for several years (e.g., telephone network communication). However, P2P computing is becoming very popular now for several principal reasons: inexpensive computing power, widely available network bandwidth, and huge storage capacity. Assuming such resources, P2P computing empowers individuals and teams to create and administer real-time and off-line collaborations in a variety of ways.

P2P collaboration means that teams have access to fresh data, because each peer connects directly to relevant information sources. In addition, each peer is free to use the peer network/coalition in any way they choose. This style of computing is very suitable for collaborative actor groups that work under conditions of autonomy and coordination.

Unlike the client-server interoperability model, P2P computing does not distinguish between server and client peers. It also enables eff icient service exchanges by bringing services closer to the point where they are actually consumed, thereby acting as a service caching mechanism. For example if a big company has several sites placed in different countries offering e-commerce services, it is more eff icient to store data in local clients (that act as local database servers), instead of utilizing a single (or a few) server databases located in the main site. This way, connection sessions are faster because they work locally.

Several models and technologies have been proposed for sharing information within distributed, dynamic environments. Such proposals (e.g., [5] [11]) offer an open and dynamic version of distributed computing, compared to classical distributed computing paradigms (e.g., client-server and Web-based models).

There are several definitions of P2P computing (e.g., [9] and [11]). For example, in [11] the authors define P2P as the following:

P2P is the computing paradigm that supports the exchange of information and services directly between producers and the consumers in order to achieve purposeful results.

In this work, we adopt the definition provided by [7]. According to this definition, P2P computing allows PCs and other non-server computational entities, connected in a network, to communicate or share computational tasks and resources without the explicit need for a server (as in Web-based models). As detailed in [7], each peer can be characterized by the following important properties: (a) it has an addressing system that is independent of DNS; (b) it is able to cope with variable connectivity; and (c) it uses an instant-messaging communication model. These characteristics make the P2P model quite unlike traditional Web-based models. For example, the classical DNS (Domain Name System) paradigm recognizes peers as recipients only of information, not publishers. Moreover, if a temporarily disconnected peer re-connects, a DNS namespace does not support notif ication of its presence to other peers. On the contrary, within a P2P network specific namespaces are used (e.g., Groove, Napster, NetMeeting, etc.), and each node is equal (peer) to all others, and may operate as router, client, or server according to the task to be performed. In addition, some P2P protocols (e.g., Napster, Gnutella) use message routing mechanisms based on broadcasting and ‘ time to live’ marker techniques. These functionalities do not constrain peers to know which partner to collaborate with and make them free to interact even with peer never known in the past.

Many tools have been built in order to support P2P computing. However, such tools have fundamental limitations (the reader can refer to [8] for more details):

• Message expressive power . Current tools exchange information by an instant-messaging communication model based on expressively impoverished languages for describing data and services. In fact, such languages can only talk about objects/data that are well defined and uniquely identified by their names (i.e., MP3 files, image files, etc.) instead of information with complex semantics.

• Data models. The information that is exchanged is based on a very simple data model consisting of file directories.

• Data transformation/coordination. Current P2P systems work on a uniform environment that does not allow for heterogeneity, inconsistency, and all

the other phenomena one expects when dealing with distributed data.

Multi-Agent Systems (MASs) have addressed issues of coordination among autonomous, distributed agents for many years [23] [24]. In particular, an agent encapsulates both client and server capabilities in order to exhibit autonomous and collaborative behaviors. MASs have been used to support the exchange of services between agents and/or platforms. This is often accomplished through the use of a yellow-page service, where each agent can advertise its services and/or look for services (e.g., the Directory-Facilitator agent described in [6]).

For instance, [10] describes a cooperative MAS with a flexible and dynamic task/agent assignment. In particular, each agent has a competence model of other agents, and each agent is able to dynamically decide which agent to cooperate with in order to solve a given task. This work explicitly defines the role of a Peer Agent that uses P2P communication to solve tasks in a collaborative way. Moreover, each agent is able to execute tasks in several ways: by itself, invoking a remote method inside another agent, transporting itself (i.e., the running code) to another place, and delegating a task to another agent.

The InfoSleuth project [2] supports technologies to operate on heterogeneous information sources in an open, dynamic environment, i.e., the Web. It relies on a mediator architecture [22]. This architecture overcomes the limitations due by federated databases [17] that do not scale up and do not cope well with ever-changing environments. The system is a MAS with several agent roles that collaborate each other to achieve common goals. For example, agents advertise their services and process requests either by making inferences based on local knowledge, by routing the request to a more appropriate agent, or by decomposing the request into a collection of sub-requests and then routing these requests to the appropriate agents and integrating the results.

[12], [13], and [14] describe a MAS based on the P2P computing model. In this work, the mediator agent exploits a distributed case-based reasoning mechanism [15] in order to generate simple data management operations according to its local knowledge and (when such knowledge is not sufficient) the knowledge of other agents. This capability is possible thanks to suitable cooperation strategies intended to interconnect information consumers and sources that evolve dynamically. Thus, this system is able to provide an answering service to agents and/or users. Figure 3-1 shows the reference architecture of peer agents in this work. As stated above, the architecture is intended to support data management in loosely connected and constantly evolving environments. We assume that each peer node includes a peer (human or social entity) and a (software) peer agent that helps/assists the peer.

2.2 Strategic agent modeling framework - i*

The i* framework is designed to model intentional relationships among agents [18]. In i* , actors have full freedom of action, but operate within the constraints of a network of social relationships. Specifically, they depend on each other for goals to be achieved, tasks to be performed, and resources to be furnished. The i* framework [18] offers two kinds of model: the Strategic Dependency (SD) model and the Strategic Rationale (SR) model, intended to support modeling and reasoning at different abstraction levels about social settings.

The SD model models relationships among social actors in a strategic way. Actors depend on each other intentionally in order to achieve goals, perform tasks or gain access to resources. By examining a network of such strategic dependencies, we can reason about opportunities and vulnerabilities of each actor and the entire social setting.

Actors in i* can be abstract roles defining responsibilities, or concrete agents representing individuals or classes with specific capabilities and functionalities, or organizational positions packaging a number of roles to be assigned to a single concrete agent.

In the SD model in Figure 3-2, Physicians, Patients and Ambulance are modeled as agents (circles with a line on the top) since they can be mapped to human individuals or groups with physical existence. Peer Agent is also modeled as an agent since it corresponds to a software agent that is responsible for all the tasks delegated by the corresponding Peer. Peer, Wrapper, Planner, Mediator, and Facilitator are modeled as roles (circles with a line at the bottom), since they are just abstractions of certain capabilities or functions that are to be assigned to agents. The model shows that physicians, patients, and ambulances can all play the role of Peer, which means that they can be members of a P2P network.

The dependency relationships in Figure 3-2 show that Peers delegate their peer communication tasks to their corresponding Peer Agents. The different types of dependency relationships indicate that Peer Agents have different levels of freedom as they fulfill these dependencies. They have full freedom in deciding how to fulf ill a goal (rounded rectangle) or a softgoal (irregular curvilinear shape) dependency. While performing a task (hexagon), the Peer Agent has to stick to the particular course of action as already determined by the Peer. For resource (rectangle) dependency, the Peer Agent only has to make the entity referred to by the resource available to the Peer. The dependency relationships between the Peer Agent and its four roles will be explained in the following section to stress on the specif ic knowledge about the application domain.

The Strategic Rationale (SR) model is used to describe the rationale behind actor dependencies. Generally, in a SR model, a goal is related to tasks through means-ends links. The tasks indicate the different ways in which the goal can be accomplished. A goal is satisfied if any of its tasks is satisfied. A task can be decomposed into subgoals, subtasks, resources and softgoals. All subcomponents of a task must be satisfied in order to satisfy a task. SR models can describe alternative ways for achieving a goal, as well as the necessary steps for finishing a task. They can also be used to evaluate the positive/negative contributions from tasks to softgoals. Section 4 includes several example SR models and offers a more detailed introduction of the concepts on which SR models are based.

The modeling constructs in i* are intentional because they are based on underlying concepts such as goal, ability, commitment, and belief. Actors in i* are strategic because they evaluate their social relationships in terms of opportunities that they offer, and vulnerabilities that they bring. Strategic actors seek to protect or further their interests. Compared to conventional modeling techniques such as data flow diagramming and object-oriented analysis (e.g. UML), i* provides a higher level of modeling such that one can reason about opportunities and vulnerabilities. The framework has been elaborated in the context of requirements engineering [18], business process reengineering [20], and software processes [19]. The framework is extended to form the basis of an agent-oriented system development paradigm.

3. Peer agent architecture overview

The SD model in Figure 3-2 relates peer agent roles to the goals delegated by its peer. For instance, a peer depends on its peer agent to ‘Deal with Problem Requests’ , and to give ‘Solutions’. Also, the peer expects the peer agent to be ‘Failure Tolerant’ , and to have good performance in terms of ‘Good Bandwidth Optimization’ . Moreover, each peer agent plays one or more of the following roles to support the needs of its peer:

• Wrapper (source inter facing). A peer agent can interface with other agents with its local sources and services that, in general, are not agent-based, e.g., Web, DBMS, etc. (Figure 3-1). To do so, a peer agent translates sentences expressed in the peer agent common language into specif ic application/device languages. Thus, this role is responsible for the interfacing with the peer’s local environments. In fact, Figure 3-2 shows that the peer agent benefits from its wrapper role for information needs and actions. Namely, the wrapper serves the peer agent’s ‘ Information Needs’ (resource dependency) by ‘Perform (certain) Actions’ (task dependency). The actions performed

can be data management operations, coordination actions, and complex task sequences (workflows) among several sources.

• Facilitator (searching and registration). In a decentralized P2P environment, each peer does not know a priori which partners to communicate with. The facilitator role provides a peer agent with searching and registration capabilities, which allow the peer agent to get to know other peer agents with useful skills (to establish new acquaintances). In particular, as depicted in Figure 3-1 and 3-2, this ability is based on a yellow page directory service, where agents can advertise themselves and their functionalities (‘Registry Service’ resource dependency). The logical grouping of peer agents (e.g., peers with the same services/skills), sustained by the yellow pages, forms a peer domain. The grouping into domains improves a peer agent’s ability to propagate collaborative actions and conduct search activities. This kind of collaboration is driven by the locality principle [1], which means that each peer’s global behavior emerges from local interactions. Yellow pages also provide information about the state (e.g., active, disconnected, etc.) of other peer agents.

• Mediator (reformulation and integration). This role provides a peer agent with reformulation and integration capabilities [13]. Using these, a peer agent can reformulate the original problem (i.e., the initial request) in terms of a set of tasks/actions (i.e., the correct workflow), in agreement with some soft inter-database constraints (i.e., coordination rules [3]), each targeted at selected sources (see Figure 3-1). When the local knowledge does not help (i.e., a failure occurs), it must be updated. Indeed, as shown

by Figure 3-2, the peer agent depends from its mediator agent in order to maintain update (‘Good Maintenance’ softgoal dependency) and consistent (‘Consistent’ softgoal dependency) the knowledge base. To this end, a peer agent cooperates with other peers and adopts a lazy learning approach that is suitable for a P2P network, where peers are loosely and dynamically connected. The proposed approach adopts case-based reasoning techniques [15], where agent knowledge is stored in its case memory. A case memory contains the elementary actions necessary to properly satisfy different types of requests (information needs), as shown in Figure 3-1 and 3-2 (see §3.1 for more details).

• Planner (strategy generation). This role provides the peer agent with the skill of distributed problem reformulation. Thus, when a failure results from the peer agent inability to satisfy a request locally, the planner can help to build up a cooperation strategy in order to overcome the underling failure. More details on this agent role are given in §4.

In order to make peer collaboration as much autonomous as possible, the four agents (i.e., Wrapper, Facilitator, Mediator, and Planner) above introduced provide the system the most important skills.

3.1 Peer knowledge base character ization

Each PA’s knowledge base (���

(PA)) is composed of a collection of cases. Moreover, it is strictly influenced by the PA’s peer acquaintances (��� (PA)). Indeed, each knowledge base element (Case) contains peer address information that every action (problem) is directed to. Namely, every time PA is unable to give a local solution to an given problem, it turns to its peer acquaintances in

Figure 3-1: Peer agent capabilities.

req: request (problem). ������������ : is the set of agents that identifies the P2P coalition. a1,…,ak: reformulation (i.e., data-management operations and coordination rules among peers’ databases) p1...pk: peer agents’ addresses. si: services advertised by a peer agent pi ∈ ������������

Wrapping

Searching/ Registration

Reformulation/ Coordination

req R I

r a1, …, ak <a1,p1>…

name service address

pi s1,…,sj pi@dom.it

DB Web html, xml

Peer Agent

Peer2

Strategy Generation

Wrapping

Searching/ Registration

Reformulation/ Coordination

req R I

r a1, …, ak <a1,p1>…

name service address

pi s1,…,sj pi@dom.it

DB Web html, xml

Peer Agent

Peer1

Strategy Generation

order to cope with the problem. Figure 3-2 shows that Peer Agent depends on the Facilitator for peer search activities, e.g., the ‘Global Peer Visibility’ softgoal dependency means that a peer agent desires to own the largest facilitator peer-scope. On the other hand, the knowledge base contains information about ‘how’ and ‘who’ has to fulfill actions, data management operations, and simple queries. This capability is deployed from mediator agent by its reformulation ability [13]. In order to better understand each agent role in the P2P context, here we propose a definition of Case that is adapted from [13].

Definition 3-1 (Case). Each case is a three element structure <req, R, I> where:

• req is the initial request (or problem) to be satisf ied. req can represent several kinds of peer agent’s problems/requests (� ), e.g., a workflow in terms of set of actions, queries towards a DBMS or a Web site, updating DB operations, etc. Therefore, the initial problem is an element of the problem space (� ): �∈req .

• R is the internal PA’s problem (req) representation (hereafter reformulation) necessary in order to perform some kinds of intelligent operations, i.e., data management operations and/or coordination rules. These latter determine the reformulation space (��� � ). In general, R is a subset of ��� � ( ��� �⊆R ) and it is expressed in some expressive

and computable languages. For example, in [13] the authors adopt a description logic named C-Classic [4].

• I is an interpretation of the problem reformulation (R). Namely, after a problem reformulation is given, an interpretation is needed in order to deal with both actions and results related to the initial request. Indeed, as we said above, R can be a coordination action to be performed over other peers, and/or R can be a set of queries towards several sources. For example, the current peer agent system capabilities (Figure 3-1) consider I as a set of pairs where each element is composed of an action (ak) of R and the peer agent (its network address, pk) able to perform it (<ak, pk>). Therefore, an interpretation deals with two sets of elements: the problem reformulation space ( ��� �∈ka ) and the peer acquaintance space

( (PA)pk ���∈ ).

Figure 3-3 presents the main (internal) peer agent collaboration and transformation activities, along with the corresponding agent roles. Each problem (req) represents a peer request (expressed in a high level language) sent to PA. The information requested is often not known a priori and may be distributed over the P2P network. Hence the PA needs to know where is the required information located. To this end, the system performs a transformation (f), from the problem space (� ) to the power set of ��� � x ��� , defined as follows:

)( ,

,., : 2reqfIs.t.Ireq

e. if

=×⊆∃∈∀→ ×

������ ��� ���

� � (3-1)

Moreover, as shown by (3-1), we assume that for each request (req) there always exists a peer, in the whole P2P coalition (��� ), able to satisfy it. Notice that, while in

Figure 3-2: P2P Agent System Architecture Reference Model

Agent and Role (Actor)

Softgoal dependency

Task dependency

Resource dependency

Figure 3-3 the element sets (��� ��� � � ��� � ��� ) are referred to a single peer-agent (PA) knowledge, in formulas from (3-1) to (3-5) such sets are referred to the whole peer coalition knowledge (e.g.,

�k

kPA )(������ = ). As

depicted by Figure 3-3, after that a problem interpretation is given (I), the peer agent is ready to execute such an interpretation in order to satisfy the initial request (req). If a local failure occurs a cooperation strategy is required to overcome such a failure by collaborating with other peers. In the peer agent system, a failure could happen either during the effort to produce an interpretation (internal symptoms) or during the execution process (external symptoms). As described more in depth in the next sections, the planner role must build the most convenient plan (cooperation strategy) taking advantage of the received failure symptoms. In the current peer agent reference model, the transformation (3-1) is performed by the synergic collaboration of the system principal agent roles shown in the reference model of Figure 3-2, i.e., mediator, facilitator, planner, and wrapper. Specifically, as also shown in Figure 3-3, the system performs the transformation expressed in (3-1) in two steps as follows:

22: � �� �� �� ×→→=ir

rif � (3-2)

where ��� � contains the PA’s problem reformulations (e.g., database operations). Besides, ��� � is a fundamental part of the PA’s knowledge base. Indeed, each ��� � ’s element can be expressed into any computable high-level language (e.g., C-Classic) in order to make the system decision-making processes as autonomous as possible (see Figure

3-3). The transformation between � and 2� �

is

performed by the reformulation function (r) as follows:

r(req)RRreq

i.e.r

s.t. ,

,,: 2=⊆∃∈∀

→��� ��

� ��� � (3-3)

while the transition from 2� �

to 2 ���� � × is computed

by the interpretation function (i) as follows:

)( ))(( )(

, , ,: 22reqfreqriRiIs.t.I

Ri.e.i

===×⊆∃⊆∀→ ×

������ ���� ��

��� ���� �

(3-4)

where, R and I are set of elements. As already said, the mediator role is involved in the reformulation function (r). Indeed, in the current system, both � ’s and ��� � ’s elements are expressed in description logic and managed by a case-based reasoner engine. The ‘ i‘ function relates each

element (R) of 2� �

with the set of peers able to satisfy R

itself (e.g., acquaintance in terms of information sources). Therefore, ‘ i’ is computed principally by the mediator role. While, the execution of each I element is mainly done by PA’s wrapper role that performs wrapping activities on several types of information sources (e.g., Web, RDBMS, etc.). In order to perform ‘ i‘ also when a failure occurs, the planner role is also required to PA. Moreover, in order to search new peers (e.g., new sources’ addresses) the Facilitator role is important as well as the mediator, the planner, and wrapper roles.

Since PA’s knowledge base (���

(PA)) is composed by cases (C), now we are able to give a possible formalization for it:

������� ���� �

�����

(PA)(PA)RiI

(PA)reqrR

(PA)req

s.t.IRreqCC(PA)

kPA

kPAk

k

kkkkk

×⊆=⊆=

∈

>=<=

)(

,)(

,

,,,

k

(3-5)

Figure 3-3: Peer Agent system internal decision-making activities

rPA

iPA

Coop. Strategy

Failure? req results

no

yes

external symptoms

��(PA) updating

Peer Agent

�� �� �� �� (PA)

�(PA)

� �(PA)

� � (PA)

Failure? Exec.

internal symptoms

plan

R I

yes

no

4. A Strategic Rationale model for the planner

The peer agent’s principal capability to cope with local failures is supported by its planner role. In fact, when a failure occurs, the planner has to build up a cooperation strategy in order to overcome the failure. This behavior allows the peer to dynamically update its knowledge, i.e., in terms of peers’ past problems (say cases), and therefore to take into account changes in information sources and peer’s complex information needs. This means that each peer agent’s knowledge base about sources (e.g., their schema) is strongly influenced by the requests submitted by peers. This forms the agent’s experience. In order to characterize the planner’s capability we exploit Strategic Rationale model (SR) features. Indeed, the SR model provides a more detailed level of modeling by looking ‘ inside’ actors to model internal intentional relationships.

When a peer agent fails, it resorts to cooperation strategy planning. A local failure arises because of one of the following reasons:

(a) a peer agent is unable to rewrite a given problem; (b) one or more partners in the reformulation; (c) one or more partners involved in the

reformulation is unconnected; (d) a proposed solution is rejected by the peer agent.

Failure (a) arises when a peer agent's knowledge (its case memory) does not contain similar past cases that can be used to reformulate the problem. Usually, this means, it is the first time that a partner formulates such a request. In

other words, the peer has to satisfy a new information need.

Failure (b) means that one or more of the relevant actions in the reformulation failed. This kind of failure can occur when the peer agent’s knowledge is not up-to-date (e.g., an information source has changed its schema, coordination rules among peers’ databases are changed, etc.).

In (c), a peer is temporarily or permanently disconnected. When failure (c) occurs, a peer agent can either wait for its partner to become active (on-line) or to collaborate with another partner that offers the same requested service (see below). As already said, each peer agent can search for new peers.

In failure (d), the partner is able to respond to a request, but the response is not accepted by the receiver (e.g., because of low quality). This means that the peer agent’s knowledge is no longer consistent with the peer’s needs. In this case, the reformulation of the underlying problem has to be modified in order to reflect changes in the partners’ needs (e.g., cooperating with another peer agent that is able to correctly solve such a problem).

As a consequence, we have modeled these main local failures as Planner’s internal softgoals to be achieved, respectively, ‘Satisfy New Information Need’ , ‘Cope with Unpredictable Connection’, ‘Cope with Negative Feedback’ , and ‘Cope with Source Dynamism’. Moreover, Figure 4-1 indicates that a peer agent depends on its planner through the ‘Provide Effective Strategy’ task dependency. To deliver on this responsibility, the planner needs to understand the failure that occurred (i.e., ‘Decide Failure Type’ task dependency) and then it has to select a suitable strategy (i.e., ‘Build Recovery Strategy’ task dependency).

As indicated earlier, a local failure is caused by deficiencies in a peer agent's capabilities. Namely, each agent is able to recognize a specif ic set of inabilities during its interactions. To ‘Decide Failure Type’, the planner relies on the peer agent to provide ‘Failure Symptoms’ information. In particular, the ‘Decide Failure Type’ resulting process consists in a failure type description (see Figure 4-1). The ‘Failure Symptoms’ resource dependency contains both internal and external symptoms (see also Figure 3-3). Internal failures are recognized by the peer agent system architectural and implementation design (e.g., in Java language programming by ‘Try’ and ‘Catch’ routines). While, external symptoms are recognized by the semantic adopted in the instant-messaging communication model, i.e., our system’s messages are based on the FIPA Agent-Communication Language [6] [12]. This ability allows the planner to understand the principal failure reasons, and hence to build up the most convenient cooperation strategy to offset such a lack of success. As shown in

Figure 4-1: Strategic Rationale Model for the Planner

Figure 4-1, the alternative ways to fulf il the collaboration are represented as task nodes in i* model, which are:

Choose Partner. When a peer agent (say PA) fails, it can cooperate with other peer agents asking them to rewrite the problem according to their own knowledge base. If they succeed, PA can store the result as a new element (say case) in its knowledge base. The ‘Choose Partner’ task dependency represents one of the coordinates that planner can use in order to build up the suitable strategy. As shown in Figure 4-2, we have focused on the following principal groupings of collaborative partners:

• Interact with All Peers. They represent the whole set of PA’s peer acquaintances (��� (PA)).

• Interact with New Peers (new). In such a case, PA tries to interact with peers it was never acquainted with in the past. Namely, new is the set of peers that do not belong to the PA’s acquaintances ( φ=(PA)new ���

�). In particular, this task is

strictly correlated with the facilitator’s searching ability.

• Interact with Peers Temporarily Disconnected. This peer set (disconnected) is part of the PA’s acquaintances set (disconnected⊆ ��� (PA)), but these peers are currently disconnected from the

network (not active). The PA usually contacts such peers after some time is passed.

• Interact with Active Peers (active). This peer set (active) is the complement of the disconnected peer set. In particular, active � disconnected = ��� (PA)

and φ=eddisconnectactive�

.

• Interact with Peers that Succeed (succeed). This peer set (succeed) is a part of the PA’s acquaintances (succeed⊆ ��� (PA)), and these peers are those that PA successfully collaborated with in the past. That is, such peers are included in the mediator case-memory.

• Interact with Peers that Failed (failed). This peer set (failed) is the complement of the successful peer set. In particular, succeed � failed = ��� (PA) and

φ=failedsucceed�

.

Submit Request. PA can send the original request (req) or its reformulation (if any). In particular, each time a local failure occurs, PA can exchange three request types towards another peer in order to fulfill collaboration. In Figure 4-3 each request type is described by a task dependency as follows:

• Send the Original (req). It is the initial request/problem that PA received and it was not able to solve locally.

Figure 4-2: : ‘Choose Partner’ choices contribution relationships in order to achieve the ‘Satisfy New Information Need’ softgoal

Figure 4-3: ‘Submit Request’ choices contribution relationships in order to achieve the ‘Cope with Source Dynamism’ softgoal

• Send Reformulation (R). This allows the peer to revise an element of its local knowledge (

���(PA))

that failed (i.e., R).

• Send Failed Components. Since, R is a sets of tasks (e.g., coordination activities, data management operations, etc.), PA can send only the components that failed in evaluation.

Chosen Modality. When PA has to collaborate with a partner temporarily disconnected, a reaction modality in order to overcome such a failure is required. This modality principally depends on the involved collaboration type, e.g., a physician (a peer) has to interact with a specif ic partner (another peer), a physician has to ask some information about the patients’ results under specific treatments, a physician is interested to increase the number of his collaborators, etc. Modality capability establishes the interaction mechanism between two peers in order to support the principal cooperation ways, i.e., centralized and decentralized P2P computing. For example, let us assume that PA is looking for a service:

• Search for Peers. This is useful when the service owner is not connected, but the same service can be found elsewhere (e.g., new peers);

• Wait for Peers. This is useful when the service owner is temporarily disconnected and the service can hardly be found elsewhere;

• Send Email. In this case, the initiator (PA) knows that only this owner owns the required service, therefore PA uses a centralized model (email) to be sure that the service owner receive the message (e.g., a collaboration request).

In particular, for the Search for Peers choice, PA acts in a decentralized way, while in Send Email PA relies on a centralized system (e.g., using SMTP and POP services). The Wait for Peers modality is neither centralized nor decentralized, because after the waiting phase, if nothing happens, PA has to decide which modality to use, i.e., ‘Search for Peers’ or ‘Send an Email’ . As depicted in Figure 4-4, in order to evaluate the contribution relationships of each modality component, we have modeled such components as task dependencies.

Ask for Answer. Finally, cooperation strategies can be classified according to the answer as shown in Figure 4-5 by task dependencies. PA can ask for rewriting the request in order to update its knowledge base with a reformulation obtained from its collaborators. PA can also ask for data that answer the request. Therefore, each time a peer agent collaborates with another one, it does so in the following ways:

• Ask for Data, e.g., looking for services, processing data management operations;

Figure 4-5: ‘Ask for Answer’ choices contribution relationships in order to achieve the ‘Cope with Unpredictable Connections’ softgoal. Figure 4-4: ‘Choose Modality’ choices

contribution relationships in order to achieve the ‘Cope with Unpredictable Connections’ softgoal

• Ask for Reformulation of a given problem, e.g., knowledge updating, knowledge consistence maintenance;

• Ask for Data & Reform. Ask for data and reformulation at the same interaction time.

As a consequence, each time the planner receives a failure symptom it has to be able to answer as automatically and better as possible to the question ‘what is the best strategy to adopt in order to overcome the failure occurred?’ . Figure 4-1 indicates that one of the planner’s main objectives is the achievement of the four softgoals that compose the ‘Strategy Be Effective’ softgoal. Indeed, as already indicated, each of the planner’s internal softgoal is related to the principal failure symptoms. Nevertheless, the planner could use several task combinations in order to deal with such softgoals. As a consequence, we need to understand what is each softgoal’s contribution from each task in order to classify the best strategy related to a specific failure. Indeed, each strategy is a four-element structure (plan) <par t ner , answer , modal i t y, r equest >, where each element can assume one of several alternatives labeled as follows:

par t ner ∈ { ‘ New’ , ’ Di sconnect ed’ , ’ Act i ve’ ,

‘ Succeed’ , ‘ Fai l ed’ , ’ Al l ’ }

r equest ∈ { ‘ Or i gi nal ’ , ’ Ref or mul at i on’ ,

‘ Fai l ed Component s’ }

modal i t y ∈ { ‘ Sear ch’ , ‘ Wai t ’ , ’ Emai l ’ }

answer ∈ { ‘ Dat a’ , ’ Ref or mul at i on’ ,

‘ Dat a&Ref or mul at i on’ }

5. Evaluation mechanisms for strategies

This section aims to describe three possible approaches (i.e., qualitative, scenario-based, and quantitative) in order to analyze and evaluate the contribution relationship between the planner’s solutions (tasks) and expectations (softgoals). We first introduce each mechanism through simple examples, and then another section gives an example that explains how to combine the mechanisms for evaluating a given strategy. The proposed evaluation approaches are intended to support the design of internal peer agent behavior in terms of decision-making processes to overcome failures as autonomously as possible. Currently, no clear-cut criteria exist, for P2P coalitions, to f igure out the principal aspects to take into account in such an analysis. To this end, we are interested

in identifying and characterizing the best strategies for coping with a peer agent’s local failures. Namely, here we will describe ‘why’ and ‘how much’ each choice is better than another one in order to achieve each softgoal shown in Figure 4-1. As depicted in such a figure, some external softgoals, e.g., ‘Good Maintenance’ , ‘Global Peer Visibility’ , and ‘Failure Tolerant’ , are influenced by the planner’s internal softgoals. This means that each peer agent is influenced by the roles (mediator, facilitator, wrapper, planner) they are playing. Each contribution link is characterized by a label that specifies the contribution type and strength. The positive contribution types for softgoals are HELP (positive but not by itself sufficient to meet the higher goal), MAKE (positive & sufficient), SOME+ (partial positive contribution), and ‘?’ (unknown). The dual negative types are HURT, BREAK, and SOME-, respectively [20] [21]. Moreover, for evaluation simplicity, let us assume that for each problem (initial request) always exists a solution that is distributed over the P2P coalition.

5.1 Qualitative evaluation approach

In such a kind of analysis, the tasks’ contribution estimation is established principally on general considerations about the system components in terms of knowledge base, peer acquaintances, and peer grouping relationships. Namely, contributions to softgoal are considered using a qualitative reasoning approach.

Evaluation Example 5-1. Let us analyze the contribution relationships furnished by some of the ‘Choose Partner’ sub-tasks to the ‘Satisfy New Information Need’ softgoal, as shown in Figure 4-2. In such a case, a peer agent (PA) has to satisfy a new information need (� ). That is, it has to solve a new problem never considered in the past, for which it is not able to give a solution locally, i.e.,

φ=���� �)(PA . Alternatively, PA can only partially

solve � , i.e., ������� ⊂′′= with �

)(PA . The peers,

which successfully collaborated with PA in the past, have already contributed to the knowledge base of PA. Indeed, each peer updates its knowledge base on the basis of the information need (interests) that it has to satisfy. Therefore, peers with same interests (e.g., groupings of family doctors, cardiologists, physiologists, etc.) are also characterized by similar knowledge base. Thus, we can assume, without loosing in generality, that PA often interacts with these succeed peers. As a consequence, we can state that:

����������

)( )( succeedPA ≅=′�� �� ,

this formula means that if PA decides to collaborate with the peers that succeed in the past in order to satisfy � , it probably will receive no more information, i.e., we consider this as an HURT contribution. On the contrary, peers that failed in the past are characterized by different information needs in respect to the PA’s one. Namely, we can assume that the following:

φ≅)()( failedPA������ �

.

Therefore, it is a good choice to collaborate with peers that failed in order to overcome a failure due to a new information need, i.e., this is considered as an HELP contribution.

5.2 Scenar io-based evaluation approach

This approach is used to describe the behavioral features and architectures of the Peer Agent system in a specif ic context in order to achieve some implicit purposes. Therefore, by the scenario-based evaluation some implicit system goals are made explicit. This analysis focuses more on Peer Agent interactions in terms of how many interactions are involved in a collaboration, what kind of information are exchanged, and how the information exchanged influences the PA’s knowledge base.

Evaluation Example 5-2. As depicted in Figure 4-5, let us analyze the contribution relationships produced by ‘Ask for Answer’ sub-tasks in order to ‘Cope with

Unpredictable Connection’ softgoal achievement. In particular, let us assume that a peer agent PA1 interacts with another one PA2 to solve a problem ‘req’ . Moreover, without loosing in generality, let us assume that often our system has to satisfy request types (problems) that involve some DBMS operations, hence we consider, as request results, a data set ({data} in Figure 5-1) related to each interpretation (I). Figure 5-1 depicts three possible interaction scenarios. The scenario (A) describes the interactions that occur when PA1 asks to PA2 only for data. Namely, PA1 does not care how PA2 satisfy the request. In particular, if PA1 uses the (A) scenario it has to rely on PA2 each time a request similar to req arrives. As a consequence, each time PA2 is temporarily disconnected, PA1 is not able to obtain the solution. Therefore, we consider this as a HURT contribution. In contrast, in (B) and (C) scenarios, PA1 after the first interaction is able to interact directly with the problem’s solution/reformulation owners, i.e., this is considered as a HELP contribution. In fact, in (B) scenario, PA1 asks to PA2 only for a reformulation in order to update its knowledge base with the information required to directly connect PA3 and PA4 (those able to satisfy the request req). On the contrary, if PA1 is interested to store the data too, the (C) cooperation model seems to be better than the other ones. For example, in such a case, PA1 could also needs PA3’s and PA4’s addresses for data freshness checking (dotted lines).

Figure 5-1: Typical cooperation scenarios with different ‘Answer Asked’ choices in order to achieve the ‘Cope with Unpredictable Connection’ softgoal. Where: A: ‘Ask for Data’ , B: ‘Ask for Reformulation’ , and C: ‘Ask for Data & Reformulation’ .

PA1 PA2

<req, _, I?>

{data}

PA4 PA3

{datai}

���(PA2) fragment:

Ci = <reqi, Ri, <Ri, PA3>> Cj = <reqj, Rj, <Rj, PA4>>

PA1

PA4

{datai}

PA3

{dataj}

PA1 PA2

PA4

{datai}

PA3

{dataj}

req = reqi � reqj ?

req? req?

A): HURT

<Rj, _, Ij?> <Ri, _, Ii?>

{dataj}

<req, R?, _>

<Rj, _, I j?>

< Ri, _, I i?>

<req, R?, I?>

<req, R, I> <req, R, I> & {data} PA2

B): HELP C): HELP

5.3 Quantitative evaluation approach

Often, in order to judge if a strategy is better than another one it is useful to pre-emptive know the effects of such a strategy over the principal system’s components. Nevertheless, the high dynamism, the no global peers’ visibility, and the unpredictable peers’ connections of a P2P coalition make complex the application of any simple evaluation criteria. In particular, it is important to know ‘how’ and ‘how much’ the knowledge base varies during and after a long collaboration (collection of interactions). Moreover, in sharing information among several peer agents, it is also interesting to consider and evaluate knowledge redundancy aspects. Another feature, worth of notice in a P2P environment, is the amount of bandwidth generated by each collaboration strategy. Therefore, we just introduce some parameters and their definition adjusted into the new peer agent system in order to support a quantitative evaluation approach.

Definition 5-1 (Recall and Precision). Let p1,…,pm be m peers. Let � be a view (set of cases) of p1,…,pm. Let PA be a peer agent such that PA interacts with p1,…,pm when PA fails. Let

���n(PA) be the knowledge base of PA after

n interactions with p1,…,pm. Then:

[0,1] )(

)( : n ∈

�����

card

(PA)cardRecall

�

(5-1)

[0,1] )(

)(

n

n ∈(PA)card

(PA)cardPrecision: ���

���� �

(5-2)

In the previous definition, � denotes PA’s information need, distributed among peers, in order to satisfy a particular request/problem. Therefore, Recall gives us an indication about ‘how much’

���(PA) is closer to the

information need (� ). That is, it measures the ���

(PA)’s capability to provide a correct answer for satisfying � . While, Precision gives us an indication about ‘how good’ is the

���(PA) (in term of its content) in order to do not

provide wrong answers for � . Nevertheless, whether and how fast the Recall and the Precision are going to tend to ‘1’ depends on the cooperation strategy chosen by PA.

Definition 5-2 (Redundancy). Let PA1 and PA2 be two peer agents such that PA1 interacts with PA2 when PA1 fails. Let

���n(PA1) be the knowledge base of PA1 after n

interactions with PA2. Let ���

(PA2) be the knowledge base of PA2 such that it does not change while PA2 interacts with PA1. Then:

[0,1] )(

)(

:

2

21n ∈)(PAcard

)(PA)(PAcard

Redundancy

��������� �

(5-3)

When two (or more) peers cooperate with each other, some knowledge is exchanged among them. The strength of this exchange is captured (measured) by the Redundancy (5-3), e.g., Redundancy=0 means that two peers have no knowledge element (case) in common, Redundancy=1 means that two peers have the same knowledge base.

In P2P networks or coalition of peers, there is no of persistent connection between any two arbitrary hosts. Indeed, the two peers are on the network but not directly connected to each other in any predictable or stable fashion. Instead of facing the determinism provided by circuit-based routing networks, messages are relayed by an instant-messaging communication model. Each time an initial request arrives, PA tries to give an answer for it. In such a scenario, in which the network topology is not known a priori, in order to estimate the bandwidth generated to reach a requested information, at least we must know how many messages are exchanged among peers and their sizes. Thus, if each transmitted message size is averagely s bytes, then the generated bandwidth

b can be computed as follows:

msmsb ⋅= ˆ),ˆ(ˆ (5-4)

where m is the number of transmitted messages.

When a failure occurs, the number of messages depends on the cooperation strategy that is adopted by the peer agent. For the sake of simplicity, let us consider the scenario (A) of Figure 5-1. Let us only consider the bandwidth generated for outbound messages (i.e., the bandwidth needed during the propagation of a request over the P2P coalition). In such a situation, we have that the number of messages strongly depends on the 'Choose Partner' strategy that is selected. When a peer agent PA decides to cooperate with its acquaintances (i.e., with the peers in ��� (PA)), then we have a single request message for each peer, i.e.,

(PA))card(pm ��� ≤= (5-5)

where p is the number of peers that receive the request. Therefore,

pspsb ⋅= ˆ),ˆ(ˆ (5-6)

For instance, if PA selects the strategy ‘Interact with

Active Peers’ , we have: e)card(activspsb ˆ),ˆ(ˆ ⋅= .

On the other hand, strategies that involve new peers, e.g., ‘ Interact with New Peers’, constrain the peer agent system to eat up large and unbounded amounts of bandwidth. That is, in such cases search activities require the broadcasting to a set of neighboring peer nodes, which in turn forward the request to the other nodes, and so on.

In similar scenarios, an estimation of bandwidth generated is not easy, that is, at least we must know the network topology, the number of concurrent open connections allowed to each peer, and we must to establish how many peers a message can cross (time to live).

For instance, let us assume that the P2P coalition is fully balanced, and everyone has the same number of connections held open to other peers (n) and the same time to live (t) on packets. This is a situation similar to the situation depicted by [16] for Gnutella and, thus, we can apply the same metrics used by Ritter. Therefore we have that

n)(n p(n,t) t

i

i ×−= ∑=

−

1

11

(5-7)

gives the maximum number of reachable peers. Considering that each peer is involved in inbound and outbound transmissions, hence the bandwidth incurred is (see [16] for more details):

p(n,t)sstnb ⋅⋅= 2),,( (5-8)

In (5-8), the coefficient ‘2’ depends on the network topology being considered. In particular, it means that each message, broadcasted from a sender to a receiver, is also routed from the same receiver to the same sender once again. Namely, in (5-8), as described in (5-4), the number of messages exchanged is given by:

),(2 tnpm ⋅= .

For example, in such a scenario, let us assume that each peer at most can interact with five partners (n=5) and the message sent (e.g., a request of 100 Bytes) expires after having crossed seven hops/peer nodes (t=7). In this case, applying (5-8), the bandwidth incurred to broadcast this message is about 5.46 MBytes!

Nevertheless, our peer agent system understands, through the content of each received message, who is the message sender and consequently it can decide to do not route this message back to the message sender. For example, the message content could contain a list of peers crossed till this time, i.e., a message routing table. This would allow us to have in (5-8) a coeff icient less than 2, even if we have not investigated this issue yet.

6. The application of the three evaluation approaches

6.1 An evaluation example

Let us analyze the contribution relationships produced by the different alternatives for the task node ‘Ask for Answer’ (i.e., Ask for Data, Ask for Reformulation, and Ask for Data and Reformulation) in order to satisfy the softgoal ‘Cope with Negative Feedback’. Thanks to this example, we show the synergic applicability of all the three evaluation methods in order to establish the contribution relationships for each softgoal to be achieved.

Qualitative analysis. According to system design and behavioral aspects, we claim that ‘Cope with Negative Feedback’ principal arises when the receiver does not consider the answer valid. This affects the PA knowledge base (

���(PA)). As described in §3.1, the

���(PA) is

composed of cases (basic elements of the form: <req,R,I>) in which each one maintains the relation between the initial request (past problem) and the internal reformulation (R) that was able to satisfy such a request in the past. Nevertheless in this scenario, the PA is able to give a reformulation to the request, but such a reformulation is not considered valid anymore, that is, it must be changed. These considerations mean that the peer agent has to update its local knowledge, therefore, to concretely deliver on this goal, the PA delegates its Planner agent to built up the most convenient cooperation strategy (plan).

Scenar io-based approach. Let us take into account the scenario depicted in Figure 5-1 with the only difference due to the ‘Cope with Negative Feedback’ softgoal to be satisf ied. According to the qualitative evaluation results, we proceed to evaluate the three scenarios in order to choose the interaction scenario that better enhance knowledge updating, e.g., a reformulation that must be changed. When PA1 asks only for data to PA2, e.g., sending the initial request (original),

���(PA1) does not

update in terms of problem reformulation, but, after the interaction (say the k+1 interaction) proposed by Figure 5-1 (A),

���(PA1) increases of such cases:

{ }jikk CCPAPA ˆ,ˆ)()( 111 ∪=+ ��

��

where

iC = <Pi,Pi,<Pi,PA2>> and

jC = <Pj,Pj,<Pj,PA2>>

(6-1)

Therefore, (6-1) shows that each peer agent (e.g., PA2) can allow another peer agent (e.g., PA1) to use its knowledge base (

���(PA2)) for answering a request. As

already detailed in Evaluation Example 5-2, such an effect is not desirable into an environment characterized by unpredictable connection and no global visibility over information sources.

On the contrary, both in scenario (B) and (C), depicted in Figure 5-1,

���(PA1) is updated in terms of problem

reformulation. That is, ���

(PA1) increases with the same cases Ci and Cj belonging to

���(PA2):

{ }jikk CCPAPA ,)()( 111 ∪=+ ��

��

(6-2)

Namely, after such a kind of interactions, PA1 is able to directly connect the information sources (i.e., PA3 and PA4) in order to satisfy the initial request (e.g., some query operations).

Quantitative approach. According to the previous results depicted in (6-1) and (6-2), the recall and precision parameters do not change in all the scenarios described. Indeed, in the three scenarios,

���(PA1) is

augmented with two cases that are part of the desired information need.

Moreover, an interesting consideration arises from the redundancy parameter. With respect to the redundancy definition (5-3) and the scenario-based considerations (Figure 5-1), it is easy to prove that ask for data increases redundancy less than the other two alternatives:

Redundancy(<ask for data>) ≤

Redundancy(<ask for reformulation>)

(6-3)

Often, high information redundancy is synonym of bad behavior in many applications. Nevertheless, in P2P coalitions characterized by information sources and partners uncertainty, high redundancy reduces the information unavailability. Indeed, let us consider the scenario (B) in Figure 5-1 where PA1 already knows how to satisfy the initial request (I=r(req)). Moreover, the request results are equally distributed over

���(PA3) and ���

(PA4). Namely, each peer agent has a different part of the whole information inquired by req. In such a scenario, without loosing in generality, we can claim that the main failure reasons for PA1 are due to the PA3 and PA4 unavailability. In order to characterize this scenario, let us assume that each peer agent is available for the 70% of the time, hence:

successPA = 0.7 x 0.7 = 0.49 à 49%

This means that PA1’s percentage to have success is about 49%. On the contrary, let us consider the same scenario (B) of Figure 5-1, but PA1 does not know I yet. So, PA1 needs to connect three peer agents (instead of two), i.e., PA2, PA3, and PA4 to correctly satisfy the same req:

successPA = 0.7 x 0.7 x 0.7 = 0.343 à 34.3%

This means that PA1’s percentage to have success decreases when the number of partners increases.

Nevertheless, redundancy reverses such a downward trend. To this end, let us assume that PA1 knows the two peer agents (PA3 and PA4) and each one is able to give an answer for req, i.e., they have redundant information. In such a case, a failure occurs only when both the peer agents fail. For simplicity, we consider the likelihood to have both the systems failed:

Figure 6-1: Answer asked choices contribution relationships in order to achieve the ‘Cope with Negative Feedback’ softgoals

failurePA = 0.3 x 0.3 = 0.09 à 9%

This means that PA1’s percentage to have success is about 91%. A highly reliable solution must maintain redundant information. Moreover, a high redundancy increases the system failure-tolerant skill.

This section points out the power in combining together all the evaluation approaches in order to establish contribution relationships of strategy alternatives towards softgoals. So, by a qualitative approach, we have characterized the main reasons that cause a failure type by using consideration on system components (e.g.,

���(PA),

reformulation elements, etc.) and behavior (e.g., knowledge updating, building up a plan, etc.). Scenario-based approach delivers on qualitative results to correctly drive our analysis. Indeed, by the use of interaction diagrams (see Figure 5-1), we can detail more the

���(PA)

element changing (updating), e.g., by the use of (6-1) and (6-2). Finally, where it is possible and needed, quantitative approach gives us some useful parameters to enforce precedent evaluation results. For example, in order to better update the

���(PA), redundancy parameter

shows that to increase the ���

(PA) is more convenient to ask for reformulation than only ask for data. Therefore, as shown in Figure 6-1, for the all above considerations, we assign to the choice ‘Ask for Data’ a ‘HURT’ contribution. While, ‘Ask for Reformulation’ and ‘Ask for Reformulation and Data’ give a ‘HELP’ contribution to the ‘Cope with Negative Feedback’ softgoal achievement.

6.2 Evaluation results

The evaluation approaches described above have been applied to all the contribution relationships among planner tasks and softgoals. Obviously, each agent in the peer agent system establishes its behavior principally acting to satisfy its internal softgoals. Nevertheless, the peer agent system can partially influence and control its agents’ behavior by external softgoals to be achieved. To this end, in the planner Strategic Rationale model, we modeled peer-agent interdependencies among its agents as positive/negative contribution links from the planner internal softgoals towards external softgoals (e.g., ‘Consistent’ and ‘Fault Tolerant’ in Figure 6-1). Thus, also these interactions, pointed out by contribution links, are important because they have an impact on the planner decision process for building the most convenient plan.

Table 1 gathers all contributions and their numerical evaluation for the internal planner softgoals, while Table 2 relates contribution links between internal and external softgoals. In particular, Figure 3-2 depicts three softgoals (i.e., ‘Good Feedback’ , ‘Strategy Be Effective’ , and ‘ Information Need Availability’) that have not been considered in Table 2. In fact, the peer agent system cannot directly deal with softgoals such as ‘Good Feedback’ and ‘ Information Need Availability’, because

of, they strictly depend on external environment conditions. Namely, the peer agent system activities do not affect such softgoals. While, as shown in Figure 4-1, the softgoal ‘Strategy Be Effective’ is already considered by its internal planner softgoal decomposition. Moreover, this evaluation consists of values, in the [-1,1] interval, corresponding to each i* contribution symbol, i.e., MAKE = +1, HELP = +0.5, ? = 0, HURT = -0.5, and BREAK = -1. Moreover, we have established for the unknown positive (negative) contribution a value between MAKE and HELP (BREAK and HURT), i.e., SOME+ = +0.75 (SOME- = -0.75).

Using these tables, the planner can decide (reading from the tables) the most convenient strategy to adopt for a given failure symptom. A possible way how to use the table values is the following.

Let us assume that the planner has to build a strategy to cope with a failure caused by new information need. To this end, the planner can use its Table 1 in order to establish the most convenient strategy (plan). In this case, from row (A) of Table 1, some of the plans with maximum value are:

pl an1( A) = ( ‘ Fai l ed’ , ‘ Or i gi nal ’ ,

‘ Dat a’ , ‘ Sear ch’ ) ,

val ue( pl an1( A) ) = 3

pl an2( A) = ( ‘ Al l ’ , ‘ Or i gi nal ’ ,

‘ Dat a’ , ‘ Sear ch’ ) ,

val ue( pl an2( A) ) = 3

pl an1( A) = ( ‘ New’ , ‘ Or i gi nal ’ ,

‘ Dat a’ , ‘ Sear ch’ ) ,

val ue( pl an3( A) ) = 3

et c.

(6-4)

where val ue simply indicates the algebraic sum of each plan component values. Obviously, this is needed to establish a priority classif ication list of the plans. As shown in Figure (6-4), there exist several strategy alternatives (plans) with the same value. For example, the planner could use each plan until one succeeds.

Let us complicate more the above scenario considering a planner that has to cope with two failure types contemporarily, e.g., due to new information need (row (A)) and source dynamism (row (D)). In this case, the planner has to choose the more convenient plan from two lists: (6-4) and (6-5).

pl an1( D) = ( ‘ Succeed’ , ‘ Or i gi nal ’ ,

‘ Ref or . ’ , ‘ Wai t ’ ) ,

(6-5)

val ue( pl an1( D) ) = 3. 5

pl an2( D) = ( ‘ Succeed’ , ‘ Or i gi nal ’ ,

‘ Dat a&Ref or . ’ , ‘ Sear ch’ ) ,

val ue( pl an2( D) ) = 3. 5

pl an1( D) = ( ‘ Succeed’ , ‘ Or i gi nal ’ ,

‘ r ef or . ’ , ‘ Sear ch’ ) ,

val ue( pl an3( D) ) = 3. 5

et c.

In such a case, the planner could try to f ind (if any) the same plan from (6-4) and (6-5) lists that have the maximum val ue. Obviously, in this example and in more other situations such a technique cannot be applied. To this end, the planner could establish the most convenient plan by the help of Table 2. Indeed, in each decision-making processes, the planner has also to take into account the peer agent system softgoals. Moreover, the planner decision-making system could have several polices in order to make its choices, e.g., it could consider internal softgoals more important than external softgoals, or weight with a fractional coeff icient external softgoal contribution values, etc. In order to give an example of

how operatively using Table 2, let assume that the peer agent system must increase its peer agent acquaintances (hit by Table 2 row(G)), e.g., because it is a new peer in the coalition. Consequently, from Table 2, we read that the ‘Satisfy New Information Need’ softgoal (column 1) gives the higher contribution (value ‘1’ ) to such a softgoal. This result could help the planner to consider plans in (6-4) rather than in (6-5).

Obviously, the contribution tables are only intended to support the most complex decision making activities.

7. Conclusions

This work focuses on modeling and evaluating cooperation strategies in a P2P agent system. In particular, we have adopted, as reference model, the system described in [13] [14] and we have detailed its Planner actor capabilities. Inside the Peer Agent, the Planner’s role is to build and manage cooperation strategies. Moreover, in both modeling and evaluation phases the i* framework is used to model intentional relationships among actors and the rationale for each relationship within each actor. The softgoals and contribution concepts in i* f it very well for the modeling and evaluating of alternative strategies of peer agent’s planner. Although, the highly dynamic nature of P2P coalitions makes the evaluation procedure even more

Table 2. The contribution relationships among planner internal softgoals and the principal external softgoals related to the peer agent system. The following abbreviations are used in the table:

E: Good Bandwidth Optimization, F: Failure Tolerant, G: Global Peer Visibility, H: Good Maintenance, and I: Consistent

New Information Need

Cope with Unpredictable Connection

Cope with Negative Feedback

Cope with Source Dynamism

E -1 -.5 -1 -.5 F .5 1 .5 .5 G 1 .5 .5 .5 H .5 0 .5 1 I 1 0 1 .5

Table 1. The contribution relationships among task dependencies and the principal softgoals related to the planner. The following abbreviations are used in the table:

A: Satisfy New Information Need, B: Cope with Unpredictable Connection, C: Cope with Negative Feedback, and D: Cope with Source Dynamism.

Partners (peers) Request Answer Modality

New

Dis

conn

.

Act

ive

Succ

eed

Faile

d

All

Ori

gina

l

Ref

orm

.

Faile

d C

.

Dat

a

Ref

orm

Dat

a&R

.

Sear

ch

Wai

t

Em

ail

A .5 0 0 -.5 .5 .5 1 -1 .5 .5 .5 .5 1 -.5 -.5 B .5 .5 .5 0 0 .75 .75 .75 .75 -.5 .5 .5 1 .5 .5 C 1 -.75 -.5 -.5 -.75 -.75 1 .5 .5 -.5 .5 .5 1 .5 .5 D .5 .5 -.75 1 -.5 0 1 .5 1 .5 1 1 .5 .5 .5

complex, we propose three possible evaluation approaches in order to identify and characterize the best strategy related to a particular failure symptom. The three evaluation approaches, proposed in this paper, evince that the Planner’s decision-making knowledge of multiple forms can be unified into symbolic or numerical forms for comparison. As a consequence, two contribution tables have been produced from the analyses (Table 1 and Table 2). The methodology discussed in this paper can be adopted by any P2P agent system involved in similar decision-making activities.

References

[1] K. Aberer, P-Grid: A Self Organizing Access Structure for P2P Information Systems, in: Proc. of the 9th Int. Conference on Cooperative Information Systems (CoopIS 2001), Trento, Italy, 179-194, September 2001.

[2] R. J. Bayardo, W. Bohrer, R. Brice, A. Cichocki, J. Fowler, A. Helal, V. Kashyap, T. Ksiezyk, G. Martin , M. Nodine , M. Rashid, M. Rusinkiewicz, R. Shea, C. Unnikrishnan, A. Unruh, D. Woelk, InfoSleuth: Agent-based semantic integration of information in open and dynamic environments, in: Proceedings of the ACM SIGMOD international conference on Management of data, Vol. 26, No. 2, June 1997.

[3] P. Bernstein, F. Giunchiglia, A. Kementsietsidis, J. Mylopoulos, L. Serafini, I. Zaihrayeu, Data Management for Peer-to-Peer Computing: A Visions, in: Proceedings of the Fifth International Workshop on the Web and Databases (WebDB), 2002.

[4] A. Borgida and P. F. Patel-Schneider, A Semantics and Complete Algorithm for Subsumption in the CLASSIC Description Logic, Journal of Artificial Intelligence Research, 1:277-308, 1994.

[5] I. Clarke, O. Sandberg, B. Wiley, and T. W. Hong, Freenet: A Distributed Anonymous Information Storage and Retrieval System, in: Designing Privacy Enhancing Technologies: International Workshop on Design Issues in Anonymity and Unobservability, ed. by H. Federrath, Springer: Berlin (2001).

[6] Foundation for Intelligent Physical Agents, FIPA Specifications 2000, available at: http://www.fipa.org/

[7] R.L. Graham, Peer-to-Peer: Toward a Definition, Lecture notes in 2001 International Conference on Peer-to-Peer Computing (P2P2001), in: Proceedings of the IEEE, Linköpings unversitet, Sweden, 27-29 August 2001.

[8] S. Gribble, A. Halevy, Z. Ives, M. Rodrig, D. Suciu, What Can Peer-to-Peer Do for Databases, and Vice

Versa?, in: Proceedings of the Fourth International Workshop on the Web and Databases (WebDB), 2001.

[9] T. Hong, Performance in Decentralized Filesharing Networks, in: Proc. of the O’Reilly Peer-to-Peer Conference, San Francisco, California, February 14-16, 2001.

[10] F. J. Martín, E. Plaza, and J. L. Arcos, Knowledge and Experience Reuse through Communication among Competent (Peer) Agents, in: International Journal of Software Engineering and Knowledge Engineering, Vol. 9, No. 3, 319-341, 1999.

[11] D. Moore, and J. Hebeler, Peer-to-Peer: Building Secure, Scalable, and Manageable Networks, McGraw Hill Osborne, 2002.

[12] M. Panti, L. Penserini, L. Spalazzi, S. Valenti, A FIPA Compliant Agent Platform for Federated Information Systems, International Journal of Computer & Information Science, Volume 1, No 3, ACIS, 2000.

[13] M. Panti, L. Spalazzi, L. Penserini, Cooperation Strategies for Information Integration, in: Proceedings of the 9th. Int. Conference on Cooperative Information Systems (CoopIS), Springer Verlag, Trento, Italy, Sep 5-7, 2001.

[14] L. Penserini, M. Panti, L. Spalazzi, Agent-Based Transactions into Decentralised P2P, in: Proc. of The First International Joint Conference on Autonomous Agents & Multi-Agent Systems (AAMAS 2002), ACM Press, Bologna, Italy, 2002.

[15] E. Plaza, J. L. Arcos and F. Martìn, Cooperative Case-Base Reasoning, In G. Weiss, editor, Distribuited Artif icial Intelligence meets Machine Learning, Lecture Notes in Artif icial Intelligence. Springer Verlag. Berlin, 1997

[16] J. Ritter, Why Gnutella Can’t Scale. No, Really, February 2001. Available at: http://www.monkey.org/~dugsong/mirror/gnutella.html.

[17] A. Sheth, and J. Larson, Federated Database Systems for Managing Distributed, Heterogeneous and Autonomous Databases, ACM Transaction on Database Systems, 22 (3), 1990.

[18] E. Yu, Towards Modelling and Reasoning Support for Early-Phase Requirements Engineering, in: Proceeding of the 3rd IEEE Symposium on Requirements Engineering (RE’97), pp249-262, Annapolis, Maryland, USA, January 1997.

[19] E. Yu, J. Mylopoulos, Understanding “Why” in Software Process Modelling, Analysis, and Design,

Proceedings of 16th International Conference On Software Engineering, pp.159-168, May 1994.

[20] E. Yu, J. Mylopoulos, From E-R to ‘A-R’ – Modelling Strategic Relationships for Business Process Reengineering, Int. Journal of Intelligent and Cooperative Information Systems, 4(2&3), pp.125-144, 1995.

[21] E. Yu, L. Liu, Modelling Trust for System Design Using the i* Strategic Actors Frame-work, in: Trust in Cyber-Societies – Integrating the Human and

Artificial Perspectives, R. Falcone, M. Singh, Y.H. Tan, eds., LNAI-2246, pp.175-194, Springer, 2001.

[22] G. Wiederhold, Mediators in the Architecture of Future Information Systems, IEEE Computer Magazine, 25:38-49, March 1992.

[23] M. Wooldridge, N. Jennings, Intelligent agents: theory and practice, Knowledge Engineering Review, vol. 10, N. 2, pp. 115-152, October 1995.

[24] M. Wooldridge, An Introduction to Multiagent Systems, John Wiley & Sons, 2002.