REPUTATION MANAGEMENT IN GRID-BASED VIRTUAL

ORGANISATIONS

Alvaro Arenas, Benjamin Aziz

e-Science Centre, STFC Rutherford Appleton Laboratory, Oxfordshire OX11 0QX, U.K.

Gheorghe Cosmin Silaghi

Babes-Bolyai University, Faculty of Economics, Cluj-Napoca, Romania

Keywords:

Reputation Management, Grid computing, Virtual Organisations.

Abstract:

Grid computing allows one to access, utilise and manage heterogeneous resources in virtual organisations

across multiple domains and institutions. The formation and operation of virtual organisations involve estab-

lishing trust among their members and reputation is one measure by which such trust can be quantiﬁed and

reasoned about. This paper presents a reputation model for Grid-based virtual organisations that can be used to

rate users as well as resources and their providers. The model is based on utility computing, which expresses

the satisfaction of an entity in its interactions with other entities with respect to some issues of interest. We

show how the model can be used to rate users according to their resource usage and resource providers ac-

cording to the quality of service provided. Finally, we demonstrate through Grid simulations, how the model

can be useful in improving completion and welfare in a virtual organisation.

1 INTRODUCTION

A Virtual Organisation (VO) can be seen as a tem-

porary or permanent coalition of geographically dis-

persed organisations that pool resources, capabilities

and information in order to achieve common goals.

VOs are given attention by researchers within a wide

range of ﬁelds, from social anthropology and organ-

isational theory to computer science. Their impor-

tance resides in providing an abstraction to represent

organisational collaborations, a topic of fresh inter-

est given the current exploitation of Internet technol-

ogy to create virtual enterprises, or the sharing of re-

sources across different organisations as envisaged by

Grid computing (Foster et al., 2001).

This paper investigates how to exploit reputation

systems for managing Grid-based VOs. Reputation

is one measure by which trust among different mem-

bers of a VO can be quantiﬁed and reasoned about.

We focus on Grids where the availability of resources

and user tasks is highly dynamic, and both resource

providers and users have to compete for providing and

employing resources. Reputation systems are then

used to manage reputation of resource providers, ac-

cording to the Quality of Service (QoS) provided, as

well as reputation of users, according to their usage of

resources.

The main contribution of the paper is to study

the impact of applying reputation in Grid-based VOs.

Resource-providers reputation can be used by re-

source brokers in order to improve allocation of user

tasks by selecting reputable providers. Conversely,

users reputation can be used by resource providers in

order to deﬁne security level for users; low-reputable

users would be assigned tight measures when access-

ing a resource.

The structure of the paper is the following. Sec-

tion 2 describes our model of VOs. Then, section

3 introduces the reputation model used in the pa-

per, a utility-based model that uses information pro-

vided by monitors to rate entities within a Grid.

This reputation model is used in section 4 to model

resource-providers and user reputations. Next, sec-

tion 5 presents the system architecture and gives an

example of a usage scenario. Then, section 6 shows

experimental results and discusses the use of rep-

utation for both brokering and controlling resource

usage. Section 7 reviews related work and ﬁnally,

section 8 concludes the paper and highlights future

work.

538

Arenas A., Aziz B. and Cosmin Silaghi G. (2008).

REPUTATION MANAGEMENT IN GRID-BASED VIRTUAL ORGANISATIONS.

In Proceedings of the International Conference on Security and Cryptography, pages 538-545

DOI: 10.5220/0001925305380545

 SciTePress

2 A MODEL OF VIRTUAL

ORGANISATIONS

In order to support rapid formation of VOs, we use

the concept of virtual breeding environment (VBE)

(Camarihna-Matos and Afsarmanesh, 2003). A VBE

can be deﬁned as an association of organisations ad-

hering to common operating principles and infrastruc-

ture with the main objective of participating in poten-

tial VOs. In this paper, we have adopted the view that

organisations participating in a VO are selected from

a VBE, as illustrated in ﬁgure 1. Such organisations

may provide resources, represented by ovals, and in-

clude users that utilise VO resources, represented by

small squares.

Organisations pre-register to a VBE via the VO

Manager component, including description of the re-

sources they are willing to share in a Grid and the

list of potential users belonging to the organisation.

When a user requires to create a VO, he assumes the

role of VO Owner and contacts the VO Manager with

the description of needed resources. The VO Man-

ager includes a resource broker component that select

potential resource providers. The VO Owner then se-

lects resource providers and deﬁne list of users of the

VO.

Note that a VBE can be seen as a market place,

where resource providers are competing to partici-

pate in a VO, and users within a VO are competing to

use resources. Reputation information about resource

providers can be used as another parameter for guid-

ing the selection of VO partners. On the other hand,

having reputation information about users could help

resource providers to implant tighter security mecha-

nisms for accessing resources. Next sections would

develop these ideas for Grid-based VOs.

Figure 1: VBE and VO Models.

3 UTILITY-BASED REPUTATION

MODEL

The reputation model presented here is based on the

reputation model described in (Silaghi et al., 2007).

This section summarises the main properties of such

a model and adapts it for deadling with Grid-based

VOs.

Central to our model is the notion of organisation;

the set of all organisations is denoted by Org. From

the perspective of the reputation model, a VO is rep-

resented just as a set of organisations; we keep track

of all VOs that have existed and use the set VOId to

denote the set of all VO identiﬁers.

The entities we want to keep reputation values are

deﬁned as elements of the set Ent. An obvious restric-

tion is that an entity must belong to an organisation.

We are interested in some particular issues of interest

associated to an entity; the set of all issues of inter-

est is represented by Issue. The individuals that use

(consume) the entities and qualify them are members

of the set Cons. The sets Ent, Issue and Cons are

considered type parameters that will be instatiated ac-

cording to the domain we are interested in. Below we

represent above types and their associations as func-

tions, using the mathematical notations provided by

the Z speciﬁcation language (Woodcock and Davies,

1996).

[Org, VOId]

VOS : VOId 7→ P Org

[Cons, Ent, Issue]

EntOrg : Ent → Org

EntIssue : Ent → P Issue

EntCons : Ent 7→ P Cons

Notation [Org, VOId] introduces Org and VOId as ba-

sic types. VOS associates a VO with the set of organ-

isation participating in it. Function EntOrg associates

an entity with the organisation to which belongs to;

EntIssue relates an entity with its issue of interests;

and EntCons associates an entity with its consumers.

In our model, it is assumed the existence of mon-

itors that deliver events indicating the current value

produced by an entity for a consumer in relation to a

particular issue of interest within a VO. We represent

an event as a tuple that contains at least four elements:

a consumer, an entity, an issue, and a VO. A trace cor-

respond to a sequence of events:

Event == Cons × Ent × Issue × VOId × ···

Trace == seq Event .

A utility function reﬂects the satisfaction of a con-

sumer in relation to particular entity. It relates an

REPUTATION MANAGEMENT IN GRID-BASED VIRTUAL ORGANISATIONS

539

event with a numeric value indicating what is really

expected by the consumer:

utility : Event → R .

The complete deﬁnition of a utility function is consid-

ered to be domain speciﬁc.

Utility functions are used to deﬁne the reputation

of an entity in relation to a particular issue of interest

from the perspective of a consumer.

[Cons, Ent, Issue]

rep eic : (Cons × Ent × Issue × VOId) → R

∀c : Cons, e : Ent, i : Issue, vo : VOId •

rep eic(c, e, i,vo) =

∑

ev∈Trace{(c,e,i,vo,··· )∈Event}

utility(ev)

#(Trace{(c,e,i,vo,···)∈Event})

where #s denotes the cardinality of sequence s and

s  A denotes the largest subsequence of s containing

only those objects that are elements of A. Reputation

rep

eic is deﬁned as the average of the utilities ob-

tained from all generated events so far; it is deﬁned

as a generic function paremeterised by sets Cons, Ent

and Issue.

Aggregating all consumers reputation about an en-

tity within a VO produces the reputation of the entity

in the VO. Let us ﬁrst deﬁne the reputation of an en-

tity for the case of a particular issue of interest in a

VO as the aggregation of the reputation value given

by each consumer in the VO.

[Ent, Issue]

rep ei : Ent × Issue × VOId → R

∀e : Ent, i : Issue, vo : VOId •

rep ei(e, i, vo) =

∑

c∈EntCons(e)

rep eic(c,e,i,vo)

#EntCons(e)

Reputation function rep ei is deﬁned as a generic

function paremeterised by sets Ent and Issue.

The reputation of an entity in a VO is then the aggre-

gation of the reputation of each of its issues of interest

within the VO.

[Ent]

rep e : Ent × VOId → R

∀e : Ent, vo : VOId •

rep e(e, vo) =

∑

i∈EntIssue(e)

rep ei(e,i,vo)

#EntIssue(e)

The reputation of an entity is an aggregation of its

reputation in all VOs in which it has participated.

[Ent]

rep : Ent → R

∀e : Ent • rep(e) =

∑

vo∈domVOS

rep e(e,vo)

#dom VOS

4 REPUTATION MODEL FOR

GRID-BASED VIRTUAL

ORGANISATIONS

This section describes how above reputation model

can be used to keep reputation on both resource

providers and users within a VO.

4.1 Reputation Management for

Resource Providers

Here we aim at maintaining reputation for organisa-

tions (resource providers) within a VO and the VBE

according to the quality of service (QoS) of the re-

sources they provide. In this model, consumers corre-

spond to the users in a VO, denoted by VOUser, and

entities correspond to the VO resources, denoted by

the set Res. There are several options for selecting

issues of interest. We can have either a ﬁne granu-

larity where each service level objective deﬁned for a

resource can be seen as an issue of interest or a coarse

granularity where the whole QoS can be seen as a sin-

gle issue. For simplicity, we have selected the last

option, having the whole QoS as our only issue of in-

terest.

Functions UsersVO and ResVO represent the set

of users of a VO and the resources that an organisation

provides to a VO respectively.

UsersVO : VOId → P VOUser

ResVO : VOId × Org → P Res

This model requires the existence in the system of

monitors capable of detecting how the QoS varies

for a resource and generating events to inform the

reputation system about such changes. An event is

then represented as a tuple denoting the current value

of the QoS of a resource being used by a user within

a VO.

Event == VOUser × Res × {QoS} × VOId × R

where QoS is a name indicating the QoS issue.

In order to deﬁne the corresponding utility func-

tion, we introduce an auxiliary function indicating the

service level agreement (SLA) accorded between a

VO user and a resource provider for a particular re-

source within a VO.

SLA : VOUser × Res × VOId → R

The SLA function represents the expected quality of

a resource. It is then used to deﬁne the utility (satis-

faction) a user gets when employing a VO resource.

SECRYPT 2008 - International Conference on Security and Cryptography

540

utility : Event → R

∀(u, r, QoS, id, v) ∈ Event •

utility((u, r, QoS, id, v)) =



1 if v ≥ SLA(u, r, id)

SLA(u,r,id)

if v < SLA(u, r, id)

We can now deﬁne the reputation of a resource using

the reputation functions deﬁned in the previous sec-

tion. Here Res rep eic denotes the reputation value

given by a particular VO user to a resource in relation

to its QoS in a VO. Res rep ei represents the reputa-

tion of a resource taking into account its QoS in a VO;

it is an aggregation of the reputation of all users of the

resource in relation to the QoS issue within such VO.

Res rep e denotes the reputation of a resource in a

VO. Finally, Res rep indicates the reputation of a re-

source in the VBE. Note, since we have only one issue

of interest, Res rep ei and Res rep e are equivalent.

Res rep eic == rep eic[VOUser, Res, {QoS}]

Res rep ei == rep ei[Res, {QoS}]

Res rep e == rep ei[Res]

Res rep == rep[Res]

Using above functions, we can deﬁne the reputa-

tion of an organisation within a VO and in the VBE.

The reputation of an organisation in a VO, denoted by

Org rep VO can be deﬁned as the aggregation of the

reputation of all resources it provides to the VO.

Org rep VO : Org × VOId → R

∀o ∈ Org, vo ∈ VOId •

Org rep VO(o,vo) =

∑

e∈ResVO(vo,o)

Res rep e(e,vo)

#ResVO(vo,o)

Reputation of an organisation in the VBE can then be

deﬁned as follows.

Org rep VBE : Org → R

∀o ∈ Org •

Org rep VBE(o) =

∑

vo∈{v∈domVOS|o∈VOS(v)}

Org rep VO(o,vo)

#{v∈domVOS|o∈VOS(v)}

4.2 Reputation Management for VO

Users

Here we aim at maintaining reputation for users

within a VO and the VBE according to their usage

of VO resources. In this model, users, denoted by

set VOUser, are seen as entities who could execute

some pre-deﬁned actions on resources following pre-

established policies. Resources, denoted by set Res,

are seen as consumers that qualify users in relation to

their actions. If a user attempts to executate an action

that is not allowed by the VO policy, it will be given

a ”bad qualiﬁcation” by the resource that would be

reﬂected in the user reputation.

Set Action denotes the set of possible actions to be

perfomed on resources. A policy indicates the set of

actions a user can perform on a resource in a VO. It

represents the expected behaviour of a user.

policy : VOUser × Res × VOId → P Action

A penalty function penalises a user with a value in the

interval [0, 1) if he executes non-permitted actions

penalty : VOUser × Res × VOId × Action → [0, 1)

∀u : VOuser, r : Res, vo : VOId, a : Action •

(u, r, vo, a) ∈ dom penalty ⇒

a 6∈ policy(u,r, vo)

Events are deﬁned as follows

Event == Res × VOUser × {Usage} × VOId × Action

where Usage is a name indicating the resource-

usage issue.

Functions policy and penalty are used to deﬁne the

utility that a resource gets according to the actions

performed by a user in a VO.

utility : Event → R

∀(r, u, Usage,vo, a) ∈ Event •

utility((r, u, Usage,vo, a)) =



1 if a ∈ policy(u,r, vo)

penalty(u, r, vo, a) if a 6∈ policy(u, r, vo)

We can now deﬁne the reputation of a user using

the reputation functions deﬁned in section 3. Here

User rep eic denotes the reputation value given by

a particular resource to a VO user in relation to the

Usage of the resource in a VO. User rep ei rep-

resents the reputation of a user taking into account

its resource usage in a VO; it aggregates the reputa-

tion of the user for all resources he uses in the VO.

User rep e denotes the reputation of a user in a VO;

it corresponds to an aggregation of the reputation of

all his issue of interest. Since we have only one issue

of interest, User rep ei and User rep e are equiva-

lent. Finally, User rep indicates the reputation of a

user in the VBE.

User rep eic == rep eic[Res, VOUser, {Usage}]

User rep ei == rep ei[VOUser, {Usage}]

User rep e == rep ei[VOUser]

User rep == rep[VOUser]

5 A REPUTATION

MANAGEMENT SYSTEM

Here we present the architecture of a VO that uses

reputation management in order to facilitate the rat-

REPUTATION MANAGEMENT IN GRID-BASED VIRTUAL ORGANISATIONS

541

ing of both VO resources and VO users. The archi-

tecture is being implemented in the EU FP6 project

GridTrust

. In this architecture, the VO Management

subsystem consists of other services in addition to the

Reputation Management (RM) service, such as a VO

Manager (VOM), a Reputation-aware Resource Bro-

ker (RRB) and a Resource Usage Control and Moni-

toring (RUCM) service. These services are shown in

Figure 2.

Figure 2: Reputation Management in VOs.

The VOM informs the RM service of the setting up of

a new VO, which includes the registration of the list

of VO resources and users, as shown in the following

protocol:

VOM→ RM : setVO(VO ID, Resource ID List, User ID List)

RM→ VOM : ack()

Where VO ID is the identity of the VO being regis-

tered, Resource ID List is the list of resources of the

VO, and User ID List is the list of users in the VO.

On the other hand, the termination of an existing VO

is carried out through the following protocol:

VOM→ RM : endVO(VO ID)

RM→ VOM : ack()

Where VO ID is the identity of the VO being termi-

nated. The RRB service is used during the setting of

new VOs by the VOM. During this phase, the RRB

may request from the RM service the reputation of

a resource in a particular VO or in the general VBE

before proposing it to the VOM:

RRB→ RM : getResourceRep(Resource ID, VO ID)

RM→ RRB : return(Resource ID, Reputation Value)

https://www.gridtrust.eu

In case the VO ID is assigned a NULL value, the re-

turned reputation will be the resource’s reputation in

the general VBE.

The RUCM service is a service that monitors

requests and replies sent to and from a resource in its

interaction with a VO user. The RUCM service can

detect any undesirable behaviour by the user in its

usage of the resource being protected by that instance

of the RUCM service. This could be for example the

excessive storage of data on the resource beyond the

user’s quota. Hence, the RUCM service can report

prohibited actions performed by the VO users to the

RM service as follows:

RUCM→ RM : reportUser(Resource ID, User ID, VO ID, Action)

RM→ RUCM : ack()

The RM service can also accept ratings by the VO

users of the QoS levels they have experienced in their

interactions with VO resources. This is done through

the following protocol, in which the user reports the

QoS value:

User→ RM : rateResource(User ID, Resource ID, VO ID, QoS Value)

RM→ User : ack()

Finally, any of the entities in a VO may request from

the RM service the reputation of a user:

Any→ RM : getUserRep(User ID, VO ID)

RM→ Any : return(User ID, Reputation Value)

Again, in the event that the VO ID is assigned a NULL

value, the returned reputation will be the user’s repu-

tation in the general VBE.

5.1 Usage Scenario

We consider here an example of a usage scenario of

the RM system as shown in Figure 3. We assume that

a RRB starts by querying the RM system for the rep-

utation of a couple of resources, Resource1 and Re-

source2, in order to join them to a new VO. After

that, the VOM signals to the RM system the setting

up of the new VO and informs the latter of the two

resources and three users, User1, User2 and User3.

Once this operation is acknowledged by the RM sys-

tem, the VO becomes operational and the users can

avail of the resources offered.

At some stage, the RCUM service at Resource1

captures a prohibited action performed by User3 and

thus reports it to the RM system. Based on the utility

function for Resource1 and the penalty for the pro-

hibited action, the RM system computes the satisfac-

SECRYPT 2008 - International Conference on Security and Cryptography

542

Figure 3: Usage Scenario of the Reputation Management System.

tion of resource1 regarding this action and updates ac-

cordingly the different reputation values User3 * for

User3. Some time later, the RCUM service for Re-

source1 requests to obtain the new reputation value

for User3. Based on this new value, RCUM revises

its decision to grant access to User3 to use Resource1.

This may or may not change the access right for

User3. Finally, the VOM decides to end the VO (e.g.

as a result of achieving its goals) and informs the RM

system of this decision. The RM system acknowl-

edges this decision.

6 ANALYSIS OF THE

REPUTATION MODELS

This section describes the results we obtained by per-

forming simulations with various VO setups. We

have run our experiments using the SimGrid simula-

tor (Legrand et al., 2003) on which we implemented

the following VO operation scenarios:

• VOs with reputation-rated resource providers;

• VOs with reputation-rated users; and

• VOs with reputation-rated resource providers and

rated users.

In all simulated scenarios, we compared the results

against the case when reputation is not considered to

enhance resource management in VOs.

First, we considered a VO with users submitting

requests to resource providers for a service. We al-

low 20% of the providers to produce random QoS

values uniformly distributed in a variation band be-

tween 85 − 105% of the agreed SLA expected qual-

ity. For scheduling the requests to VO nodes we used

the Res rep e value and we allowed that each node

will obtain a number of service reuqests proportion-

aly with its reputation. For a batch of jobs originating

from the VO users, we computed the total completion

time and the total welfare produced in the system. To-

tal welfare is obtained by suming all utilities acquired

by the users for the submitted jobs. We varied the load

factors of the system. The load factor is deﬁned as the

proportion of the requested system capacity at a given

moment of time vs the total available capacity to be

delivered by the VO. For comparison, we allowed the

resource broker to schedule the requests in a round-

robin fashion. Figures 4 and 5 show the results.

Figure 4: Comparing reputation-based scheduling with

round-robin: completion time.

REPUTATION MANAGEMENT IN GRID-BASED VIRTUAL ORGANISATIONS

543

Figure 5: Comparing reputation-based scheduling with

round-robin: welfare.

We should note that with using a reputation-based

scheduling, the total completion time is better with

around 25% for every load factor of the system. More,

the system produses 25% much welfare with reputa-

tion.

Next, we simulate the system with unreliable

users. An unreliable user tries to execute un-permitted

actions. We set the fraction of unreliable users to

20%, each introducing malicious actions with a sabo-

tage rate of 20%. Each action gets a random penalty

from [0, 1). Each un-permitted request is identiﬁed

and refused by the system after its execution and its

result gets discarded and never reaches back the user.

To simulate this setup, we use a resource centric bro-

kering approach: for an available resource, the next

action/job is selected from the available ones accord-

ing with the reputation of the user who entered the

action in the system. For reputation, we used the

User rep e value.

A more complex scheduling is the one that selects

the most reputable available resource and puts on it

the job of the most reputable user. This later setup

simulates the case of a VO with unreliable users exe-

cuting actions on unreliable resource providers. Our

scheduling intends to protect reputed providers by as-

signing on them actions from reliable users.

As a benchmark, we used the FIFO (round-robin)

scheduling, at each resource executing the oldest re-

quest in the system.

Figure 6 shows the simulation results. We counted

the total welfare (satisfaction) produced and we de-

picted the welfare acquisition curve for each of the

three cases described above. The Y axis plots the pro-

portion of the total satisfaction perceived by the users

during the time. We can note that the case when the

broker is aware both about the reputation of users and

of resources allows for a quicker welfare accumula-

tion. The case when scheduling is done on the basis of

ﬁrst-come ﬁrst-serve (in both regarding the resources

and the user actions) is the worse, letting the users to

accumulate satisfaction only latter in time. We should

note that by the middle of the simulation, for a total of

about 4% (20%x20%) malicious actions, we get about

10% more satisfaction acquired.

Figure 6: Reputation based scheduling with user and re-

source reputation. We allowed 20% of users to be malicious

and having a sabotage rate of 20%.

We should note that in VOs with reliable users and un-

reliable resources, the reputation-based approach in-

creases the overall system performance in the sense

that tasks get faster executed. With unreliable users,

using the reputation-based approach the system in-

creases the user satisfaction by allowing trustfull

users to beneﬁt ﬁrst. Furthermore, the reliable re-

sources are used more effective, in the sense that

trusted actions are assigned on them.

7 RELATED WORK

The work presented here builts on the utility-based

reputation model developed by Silaghi et al in

(Silaghi et al., 2007). We have generalised such

a model by making explicit generic types such as

Entity, Consumer and Issue so that it can be used for

maintaining reputation of several type of entities, as

shown in section 4. The model has also been simpli-

ﬁed by not including the notion of time since similar

results can be obtained by interpreting indexes in se-

quence Trace as indicating the time at which an event

occurred.

Silaghi’s model is based on techniques as those

presented in (Huynh et al., 2006; Sabater and Sierra,

2001), which creates reputation from impressions col-

lected after a transaction, similar to the events gener-

ated by monitors to create reputation. However, in

the utility-based model, several reputation events can

be generated by each transaction, resulting in a more

precise representation of the reputation value.

SECRYPT 2008 - International Conference on Security and Cryptography

544

Our model is close to PathTrust (Kerschbaum et al.,

2006), a reputation system for member selection in

the formation phase of a VO. When inviting members

to join a VO, the initiator selects only those mem-

bers whose reputation is above a certain threshold and

probabilistically selects a member to be in the VO,

as we did for reputation-based scheduling in section

6. The reputation is built by aggregating positive and

negative feedback the user submits after transaction

execution. We consider our model more suitable for

Grid systems, since it does not require direct feedback

from users, the utility functions measures directly the

users’ satisfaction.

The GridEigenTrust model (von Laszewski et al.,

2005) integrates trust management as part of the QoS

management system. They consider both direct and

indirect trust, acquired at the level of grid entities and

contexts (i.e. service delivery), after transaction ex-

ecution. It is grounded on the EigenTrust approach

(Kamvar et al., 2003), which uses the notion of tran-

sitive trust: a peer i has a high opinion of those peers

who have provided it good services and therefore,

peer i is likely to trust the opinions of those peers. The

idea of transitive trust leads to a system where global

trust values correspond to the left principal Eigenvec-

tor of a matrix of normalized local trust values.

8 CONCLUSIONS

In this paper, we deﬁned a utility-based reputation

model geared for Grids. The system is general in the

sense that it can be used to rate both users and re-

sources in a VO with respect to issues of interest such

as QoS and resource usage. It also allows an entity

reputation to be aggregated to the level of the Grid in

general.

The model constitutes the basis for a design of a

reputation management system that is being currently

implemented in EU FP6 project GridTrust. Finally,

we carried out simulations of the model to demon-

strate its behaviour regarding completion time and

welfare, both of which showed improvements over

non-reputation-based VOs. We plan to carry out fur-

ther simulations in order to understand better other

behaviour of the model.

ACKNOWLEDGEMENTS

This work is funded by the European Commission un-

der the FP6 IST project GridTrust (project reference

number 033817).

REFERENCES

Camarihna-Matos, L. M. and Afsarmanesh, H. (2003). Ele-

ments of a ve infrastructure. Journal of Computers in

Industry, 51(2):139–163.

Foster, I., Kesselman, C., and Tuecke, S. (2001). The

anatomy of the grid: Enabling scalable virtual organi-

zations. International Journal of Supercomputer Ap-

plications, 15(3).

Huynh, T., Jennings, N. R., and Shadbolt, N. (2006). An In-

tegrated Trust and Reputation Model for Open Multi-

Agent Systems. Autonomous Agents and Multi-Agent

Systems, 13(2):119–154.

Kamvar, S., Schlosser, M., and Garcia-Molina, H. (2003).

The EigenTrust Algorithm for Reputation Manage-

ment in P2P Networks. In WWW ’03: 12th Inter-

national Conference on World Wide Web, pages 640–

651. ACM Press.

Kerschbaum, F., Haller, J., Karabulut, Y., and Robinson, P.

(2006). PathTrust: A Trust-based Reputation Service

for Virtual Organization Formation. In iTrust2006:

Proceedings of the 4th International Conference on

Trust Management, volume 3986 of Lecture Notes in

Computer Science, pages 193–205. Springer.

Legrand, A., Marchal, L., and Casanova, H. (2003).

Scheduling Distributed Applications: the SimGrid

Simulation Framework. In CCGRID ’03: Proceed-

ings of the 3st International Symposium on Cluster

Computing and the Grid, page 138, Washington, DC,

USA. IEEE Computer Society.

Sabater, J. and Sierra, C. (2001). REGRET: A Reputa-

tion Model for Gregarious Societies. In Fourth Work-

shop on Deception, Fraud and Trust in Agent Soci-

eties. ACM Press.

Silaghi, G., Arenas, A., and Silva, L. (2007). A Utility-

Based Reputation Model for Service-Oriented Com-

puting. In Priol, T. and Vanneschi, M., editors, Toward

Next Generation Grids, CoreGRID Series, pages 63–

72. Springer.

von Laszewski, G., Alunkal, B., and Veljkovic, I. (2005).

Towards Reputable Grids. Scalable Computing: Prac-

tice and Experience, 6(3):95–106.

Woodcock, J. and Davies, J. (1996). Using Z: Speciﬁca-

tion, Reﬁnement, and Proof. Prentice-Hall, Inc., Up-

per Saddle River, NJ, USA.

REPUTATION MANAGEMENT IN GRID-BASED VIRTUAL ORGANISATIONS

545