Inf Syst Front (2007) 9:181–194DOI 10.1007/s10796-007-9031-x

From trading to eCommunity management:Responding to social and contractual challenges

Lea Kutvonen · Janne Metso · Sini Ruohomaa

Published online: 12 May 2007© Springer Science + Business Media, LLC 2007

Abstract The increasing pressure for enterprises tojoin into agile business networks is changing the re-quirements on the enterprise computing systems. Thesupporting infrastructure is increasingly required toprovide common facilities and societal infrastructureservices to support the lifecycle of loosely-coupled,eContract-governed business networks. The requiredfacilities include selection of those autonomously ad-ministered business services that the enterprises areprepared to provide and use, contract negotiations, andfurthermore, monitoring of the contracted behaviourwith potential for breach management. The essentialchange is in the requirement of a clear mapping be-tween business-level concepts and the automation sup-port for them. Our work has focused on developingB2B middleware to address the above challenges; how-ever, the architecture is not feasible without manage-ment facilities for trust-aware decisions for enteringbusiness networks and interacting within them. This pa-per discusses how trust-based decisions are supportedand positioned in the B2B middleware.

Keywords Inter-enterprise collaborations ·B2B middleware · Trust management ·Interoperability

L. Kutvonen (B) · J. Metso · S. RuohomaaDepartment of Computer Science, University of Helsinki,P.O. Box 68, FI-00014, Finlande-mail: Lea.Kutvonen@cs.helsinki.fi

1 Introduction

In the current trend, electronic business networks arebuilt from autonomous business services. This trend canbe seen in the use of Web Services (Booth et al. 2004),various consortia standards on inter-enterprise busi-ness process management (e.g., OASIS ebXML Col-laboration Protocol Profile and Agreement TechnicalCommittee 2002; Thatte et al. 2005), and in the rise ofservice-oriented architecture (SOA) (Papazoglou andGeorgakopoulos 2003; Singh and Huhns 2005). It canalso be seen in the number of eContract-relatedresearch projects in action (e.g., Chiu et al. 2005;Dellarocas and Klein 1999; Griffel et al. 1998;Daskalopulu 2002; Grosof and Poon 2003; Xu andJeufeld 2003; Linington et al. 2004; Schoop et al. 2003;Angelov and Grefen 2003).

We call the collaborative, inter-enterprise businessnetworks eCommunities. An eCommunity is dynami-cally established to serve a certain business scenario oropportunity and is governed by an electronic contractthat is multilaterally negotiated. The contract, eCon-tract, is structured by a business network model (BNM)that represents the selected business scenario in termsof roles for the business services involved, and requiredinteractions between those roles. In the eContract, theactual role players are identified, and policy rules forthe whole eCommunity are agreed at a more detailedlevel than the business network model can define.

To support this view, the Pilarcos architecture pro-vides generic middleware services for inter-enterprisecollaboration management (Kutvonen et al. 2005, 2007).Within this frame, the contractual aspects addressedrange from information representation issues to tech-nical and business aspects. Capturing the dependent

182 Inf Syst Front (2007) 9:181–194

elements from the business level and the technical levelto the same eContract makes the Pilarcos solutiondiffer from most eContracting proposals.

The management services include a number of per-vasive functions as follows. First, tools and repos-itories support developing and publishing of newmodels for business networks, and defining new ser-vice types for business services in such a way that theservice types match the needs of the business networkroles (Ruokolainen and Kutvonen 2006). A servicetype defines common properties of a class of servicesin terms of the interface definitions, business proto-cols, and data semantics for properties such as com-munication and computing platform requirements of aservice and other application-area-specific properties.Second, service offer repositories enable enterprises topublish business services to the open service marketstogether with metainformation as required by the de-noted service type. This metainformation is later usedfor automated matching of services to roles and forinteroperability testing against peers in the businessnetwork (Kutvonen et al. 2007). Third, means are re-quired for declaring policies that govern the use and theavailability of business services. Fourth, new protocolsare needed for negotiating eContracts to govern a newbusiness network (Kutvonen et al. 2005); the estab-lishment phase is partially performed by a third-partypopulation process, partially by a collective, refining ordropping-out negotiation protocol between becomingpeers. Finally, facilities are needed for monitoring thebehaviour within eCommunities and manage breacheswithin them as specified in the eContract (Metso andKutvonen 2005).

For the pervasive services, there is a network man-agement agent (NMA) for each enterprise, to representthe enterprise to the rest of the network and to serveas an interface to the external services, such as thecommon repositories.

We believe that by this kind of generic B2B mid-dleware services that are available through privateagents at each enterprise, the right kind of softwareinvestment cycles can be supported. The middlewareservices themselves are separated from the applica-tion software, thus making applications less dependenton the platform technologies. At the same time, thegranularity of provided services grows to be under-standable at the business strategies level; understand-ing the relationship between business services and thecomputational counterparts is a necessary requirementfor controlling them (Kutvonen and Metso 2005). Fur-thermore, the development of B2B middleware andSOA-guided eContract-based architectures require theseparation of various business and technical concerns in

the contracting process, for example, security, trust andreputation, and business policies.

This paper elaborates on the business network es-tablishment phase in which decisions on required in-teroperability are done and enhances it by addressingissues of trust management; it also discusses the oper-ational time monitoring needs. The middleware agentthat performs the establishment phase analysis is calledthe populator, and its task is to fill the different rolesof a business network model with service offers ofacceptable types, and to check that the selected servicesare able to interoperate. In the present situation, theimportance of the populator lies in its ability to checkinteroperability conditions, but not in becoming an au-tomated contract initiator with new partners from openservice markets. The main hindrance in automated se-lection of partners is the lack of trust in unknown ser-vice providers and the lack of any framework contractsto govern the service markets. In the operational timeenvironment, monitoring of contracted behaviour, ad-herence to enterprise policies, and managing breachesof trust are of importance. The monitoring results areto be used for feedback through the reputation systemfor more aggregated information in the later businessnetwork establishment events.

This paper discusses the effects and techniques ofintroducing trust-related decisions into eContracting.Trust is evaluated between peers, while the middlewarelayer should provide a trustworthy platform from whichtrustworthy information can be retrieved, and wheretrustworthy private agents are running. A secure com-munication infrastructure is assumed to be in place.

This paper is structured as follows. Section 2 dis-cusses the social and contractual challenges addressedwith dynamic collaborations formed from open servicemarkets. Section 3 addresses the trusted role of thenew infrastructure agents for providing an environmentin which to manage these collaborations. The popu-lator functionality and its implementation are furtherdiscussed in Section 4, while Section 5 introduces thetrust concepts and discusses embedding trust consider-ations into the populator functionality. The monitoringmethods and the effect of their usage is discussed inSection 6. We conclude with future challenges on re-search and standardisation on open business networkmanagement.

2 Addressing social and contractual needsby eContracts

Establishing new eCommunities from business ser-vices at the open markets raises problems that can be

Inf Syst Front (2007) 9:181–194 183

considered social. As the services involved are devel-oped independently, there is no inherent knowledge forthe intended business processes between partners, orknowledge of the competence of the potential partners.Thus, the interoperability demands between partnersemerge to sharing external business processes, meetingon business value, understanding the pragmatics ofenterprise policies, and furthermore, embedding man-agement of trust between potential collaborators. Thissituation of autonomous domains with a need for fed-erated management of collaboration relationships in adynamic manner is very challenging.

The goal is to provide automated support for es-tablishing new eCommunities, but in a controlled way.The automation should be limited to routine cases, andmore vulnerable, new, or otherwise delicate decisionsshould enforce human decision-making. Although theautomated part can be considered somewhat trusted,the autonomy of partners in the process still requiresthat privacy of decision-making (motivations, strate-gies, policies) should be protected by the overall archi-tecture. The strengths of the automation should comefrom the management of routine configuration workthat is dependent on the collaboration decisions, notedlevel of trust between partners, and available techno-logical solutions.

From the business point of view, there are two con-tradictory requirements for making business servicesavailable. On one hand, it is preferable to have allpotentially marketable services openly available forall potential clients and collaborators, while on theother hand, the integrity and privacy of enterprise ICTsystems require efficient access management, securetransfer of information and strict authentication pro-cedures. In open business networks, traditional hardsecurity falls short in protecting an enterprise, becauseit divides other actors too narrowly into those trusted(authenticated and authorised) and untrusted (all oth-ers), with little ability to adjust to the misbehaviourof trusted actors, for example. Social control methods,such as trust management, allow the system to be moreopen for collaboration, while still protecting itself bothfrom unknown actors as well as those authorised forthe time being (Rasmusson and Jansson 1996). In thecentre, the service itself is aware of its required integrityand security constraints, and refuses access that wouldbreak these limits, regardless of the requestor.

At present, there are no commonly accepted eCon-tract structures that would sufficiently cover the variousbusiness and technical aspects of the eContract. Webelieve the necessary aspects should be captured in acommon upper-level ontology that is further refinedwith published business network models. Final details

are added from service offers, role-by-role, as part-ners enter eCommunities. In addition, the eContractstructures should address the needs of eCommunitymembership and life-cycle management at runtime, in-cluding interoperability monitoring.

The business network models, specific to theirbusiness-areas, should define a sufficient structure foreach eCommunity type to support the actual eContract-ing (negotiation, establishment, monitoring). Thesemodels bring in aspects of regulatory systems, busi-ness targets, and common practices; the descriptionsof available business services in turn define the limitswithin which the providing enterprises are willing toassume responsibilities in the potential eCommunities.Information related to the eContracts becomes de-fined by designers, policy creators, service implemen-tors, and enterprise system owners in separate stepsof systems engineering and use. Figure 1 illustratesthe flow of business-related and technology-relatedmetainformation in the eContracting process in thefundamental steps of metainformation and softwareproduction processes for inter-enterprise collaborativesystems (Kutvonen and Metso 2005; Ruokolainen andKutvonen 2006). The elements are described below.

A business network model defines the topology of aneCommunity in terms of roles and interactions betweenthem. A role is a placeholder for a business service:the role definition sets direct requirements with whichthe service types must conform, and it can, in addition,define assignment rules for other features, for examplenon-functional aspects or the identities of the partic-ipants acceptable for the role. The interaction decla-rations set conformance requirements for the businessprocesses to be executed between participants. Thedesign of business network models is a profession onits own, requiring understanding of regulatory frame-works on the business area, best business practices, andstrategical methodologies suitable for the business.

A service type defines the syntactical structure of in-terfaces, the semantics of documents to be exchanged,and the service behaviour in terms of the local businessprocess, as observed outside of the software moduleproviding the service. For each service type, there isa set of associated properties that are required foreach service offer for this type. A service offer is adeclaration of a provided service, naming its servicetype and giving values to the required properties.

A computational service is a collection of business-relevant software modules. However, it has been adesign aim here that the software elements do not needto consider the business strategies or policies. Instead,the runtime environment provides metainformation-driven monitors for governing the software elements.

184 Inf Syst Front (2007) 9:181–194

Fig. 1 Information flows forbuilding eContracts andbusiness services

We call the combination of the monitor, the governingrules, and the computational service a business service.It should be noted that part of the governing rules arepublic as well as part of the eContract, while others areprivate and known only to the provider of the businessservice.

While the eContract structuring by business networkmodels capture most social behaviour requirementsin the eCommunity, we must consider other layersof interoperability simultaneously. We understand in-teroperability, or the capability to collaborate, as theeffective capability to mutually communicate informa-tion in order to exchange proposals, requests, results,and commitments. The term covers technical, seman-tic and pragmatic interoperability. Technical interop-erability is concerned with connectivity between thecomputational services, allowing messages to be trans-ported from one application to another. Semantic in-teroperability means that the message content becomesunderstood in the same way by the senders and thereceivers. This concerns both information representa-tion and messaging sequences. Pragmatic interoperabil-ity captures the willingness of partners to perform theactions needed for the collaboration. This willingness toparticipate refers both to the capability of performing arequested action, and to policies dictating whether it ispreferable for the enterprise to allow that action to takeplace.

To capture these interoperability levels, we use thefive ODP-RM viewpoints (Open Distributed Process-ing Reference Model) (S10746 1996) to structure themetainformation in service offers and eContracts. TheEnterprise viewpoint is focused on defining the rolesand interactions needed between them in order to reach

the goal of the community. This corresponds to thedefinition of external business processes and policiesover the eCommunity. The Information viewpoint is fordefining the information repositories and the exchangeof information elements, as well as calculi for invariantsand well-formed changes of the state of the informa-tion. The Computational viewpoint is for defining thecomputational services involved with the community, interms of interfaces and behaviour towards them. Thetechniques for describing and comparing behaviouraltypes of services are still immature (Ruokolainen andKutvonen 2006). The Engineering viewpoint is for ex-pressing how the computational services and the sup-porting infrastructure are to be used. The Technologyviewpoint is for expressing which standard solutions arerequired for computing or communication platforms, orinformation exchanges.

The brief analysis above brings us to structuringeContracts and service offers as shown in Table 1. TheeContract is structured according to the roles defined inthe business network model, and refined by instructionsfound for each service type required in the roles. Inaddition, the eContract is structured by epochs, periodsof activity where the jointly provided service and thestructure of the eCommunity is stable. Separate epochscan be used for breach recovery or otherwise well-limited activity with different set of roles still progress-ing the work of the eCommunity. The final level ofdetail captures the requirements on the technical com-munication. The eContract must also address breachdetection and recovery by choosing a published modelfor that.

In contrast to some upper-level ontology develop-ment initiatives, where the aim often is to define a

Inf Syst Front (2007) 9:181–194 185

Tab

le1

Tec

hnic

alst

ruct

ure

and

XM

L-t

ags

for

eCon

trac

tcon

tent

s

Con

trac

tele

men

tlab

elIn

form

atio

nty

pean

dso

urce

Exp

lana

tion

Iden

tifica

tion

and

stat

em

anag

emen

tco

ntra

ctID

Stri

ngas

sign

edby

the

init

iati

ngN

MA

Iden

tity

for

the

eCom

mun

ity;

pote

ntia

llyjo

intl

yw

ith

sess

ionI

Dde

scri

ptio

nSt

ring

assi

gned

byth

eB

NM

desi

gner

Pur

pose

ofth

ebu

sine

ssne

twor

km

odel

;bus

ines

ssc

enar

io.

star

tDat

eSe

tby

init

iati

ngN

MA

duri

ngth

ene

goti

atio

npr

oces

sIf

the

cont

ract

valid

ity

isti

me-

trig

gere

d,th

est

artD

ate

and

endD

ate

are

used

,in

dica

ting

date

and

tim

e.en

dDat

eD

ate

and

tim

e,as

abov

est

ate

Inte

ger

upke

ptby

the

NM

A.

The

eCom

mun

ity

life-

cycl

eis

cont

rolle

dby

ast

ate

mac

hine

wit

hst

ates

ofpo

pula

ted,

in-n

egot

iati

on,

agre

ed,

esta

blis

hed,

inre

nego

tiat

ion,

term

inat

ed.

Dur

ing

the

esta

blis

hed

phas

eth

epr

ogre

ssof

the

conv

ersa

tion

s(e

xter

nal

busi

ness

proc

esse

s)ca

nbe

view

edas

step

sof

cons

ider

ably

larg

eta

skbl

ocks

.

Man

agem

ento

fre

petit

ive

exec

utio

nof

eCom

mun

itybe

havi

our

sess

ions

Arr

ayof

cont

ract

Sess

ions

whe

reel

emen

tsen

code

din

stri

ng-v

alue

dta

gged

field

sE

ach

Con

trac

tSes

sion

elem

ent

cont

ains

the

cont

ract

IDan

dse

ssio

nID

wit

hin

that

cont

ract

,id

enti

fier

for

the

curr

ent

epoc

h,an

dan

inte

ger

code

dst

ate

indi

cato

r.al

low

edSe

ssio

nsIn

tege

r,no

tman

dato

ryM

axim

umlim

itof

sess

ions

for

this

eCom

mun

ity.

used

Sess

ions

Inte

ger

Cou

nter

for

cont

rolli

ngth

em

axlim

it.

conc

urre

ntSe

ssio

nsIn

tege

rL

imit

for

max

imum

num

ber

ofco

ncur

rent

sess

ions

.T

heeC

omm

unity

stru

ctur

ean

dbe

havi

our

busi

ness

Net

wor

k-M

odel

IDSt

ring

Iden

tifie

sth

eco

rrec

tmod

elin

repo

sito

ry

part

icip

ants

Arr

ayof

part

icip

antI

nfo;

part

icip

antI

nfo

elem

ents

enco

ded

asst

ring

-val

ued

tagg

edfie

lds

Apa

rtic

ipan

tInf

oel

emen

tco

ntai

nsse

rvic

eof

fer

info

rmat

ion,

espe

cial

lylo

gi-

cal

and

tech

nica

lad

dres

ses

ofco

mm

unic

atio

nen

d-po

ints

for

the

part

ici-

pant

s,th

em

anag

emen

tint

erfa

celo

cati

on,t

hepa

rtne

r’s

digi

tals

igna

ture

,the

role

itis

asso

ciat

edw

ith

and

whe

ther

this

part

icip

ant

isth

eco

ordi

nato

ror

the

eCom

mun

ity.

bind

ings

Arr

ayof

logi

calc

onne

ctio

nsas

sign

edby

NM

As

Ref

eren

ceto

the

bind

ing

type

for

the

med

iati

ngch

anne

l;pr

ovid

este

chni

cal

requ

irem

ents

.m

odel

Pol

icie

sA

rray

ofpo

licie

s;po

licie

sex

pres

sed

asa

nam

e-va

lue

pair

.P

olic

ies

gove

rnin

gth

eeC

omm

unit

yov

eral

lepo

chs.

arch

itec

ture

Pol

icie

sA

rray

ofpo

licie

sP

olic

ies

gove

rnin

gth

eeC

omm

unit

ydu

ring

one

epoc

h.ro

leP

olic

ies

Arr

ayof

polic

ies

Pol

icie

sgo

vern

ing

each

role

inan

arch

itec

ture

.gl

obal

Rec

over

yPro

cess

Arr

ayof

proc

ess

refe

renc

esP

roce

ssm

odel

sar

eav

aila

ble

inth

ety

pere

posi

tory

.co

nver

sati

onR

ecov

ery-

Pro

cess

Arr

ayof

proc

ess

refe

renc

es

role

Rec

over

yPro

cess

Arr

ayof

proc

ess

refe

renc

es

186 Inf Syst Front (2007) 9:181–194

universal contract structure, we consider the businessnetwork model developed for a specific business do-main as the right scope for the “universe of discourse”when defining contract structures and ontologies. First,the full range of elements affecting interoperability isnot present. Due to the autonomy of service providers,part of the knowledge is private, and failures to con-form to the category-forming selection criteria or mon-itoring rules will raise issues to be addressed by breachrecovery processes at the community level. Second, thestructure of an eContract is not defined by one templateonly, but the construction rules for the eContract struc-ture are retrieved from the business network model,service type descriptions, and service offers.

To pair up with this structure of the eContract, thecorresponding protocol stack is depicted in Fig. 2. Themain difficulty to overcome here is that each stacklayer involves a different set of participants. The tech-nology level protocols are used by the peers in thebusiness network to fulfil basic communication interop-erability needs, while service level protocols are usedbetween potential peers and the open service mar-ket to determine the compatibility of single services.The community-level business processes are used tomanage the dynamics and interoperability of the busi-ness network as a whole. Besides this, the architec-ture must support mapping of the business rules andenterprise policies of the members of the eCommu-nity to the community management protocols on thelayer below. Even contract breaches should be resolvedby community-level business processes. Therefore, thecommunity-level processes form a backbone for in-teroperability and collaboration management, placinghigh demands on the supporting middleware to en-able that. In addition, the lack of workflow enactmentin the stack is intentional. The business applicationsare expected to execute their private (local) businessprocesses independently, only interacting according toa monitored external business process. As the coordi-nation approach here expects business services to beable to initiate the necessary activities themselves, onlybreach detection and recovery processes are needed.

Fig. 2 Interoperability management

The essential failures of service behaviour that weshould expect to address are involved with variousnon-functional aspects (NFA), such as trust, security,QoS, or discrepancies between business policies of au-tonomous participants.

3 New infrastructure services and their trusted role

The introduction of middleware level services that areallowed to make commitments on behalf of enterprisesraises problems in legal terms as well as in terms ofenterprises being able to trust their own middlewareagents and the infrastructure services available in theopen network. In the following, we only address afew aspects of the trustworthiness of the infrastructureservices.

We use a two-phase approach in eCommunity estab-lishment. First, a populator is used to match multipleservice offers into a frame formed by a business net-work model. Then, the eCommunity participants arefurther negotiated based on the proposed eContracts.The negotiation is performed by network managementagents, NMAs, that represent each enterprise.

The populator is responsible for providing a reliablefacility to produce interoperable sets of service offersin such a way that they fulfil the requirements of aselected business network model. The interoperableset of service offers means that based on the networkmodel, each service that must communicate with otherscan do it technically and semantically. The willingnessof the participants to interoperate (i.e. pragmatic in-teroperability) is not considered during the populationprocess and it will be determined at a later time duringthe negotiations.

The populator chooses the most suitable service of-fers for each role. First of all, the offers must be ofan acceptable service type for the role. The selectionis further restricted by policy constraints defined inthe business network model or required by the ini-tiator. Finally, a group of additional requirements israised when the properties declared (e.g., expectationson communication platform and properties) in serviceoffers for interacting roles are matched.

The population process results in a set of eContractproposals, still requiring a negotiation round amongstthe proposed partners before the eCommunity estab-lishment phase is completed. The protocol in itself issimple: the initiating NMA receives a specified max-imum number of contract proposals from the popu-lator and the initiator orders them according to itspreferences. Then it sends out the first proposal to allpartners referred to in that proposed eContract. These

Inf Syst Front (2007) 9:181–194 187

peers can respond by accepting the proposal, or makinga refined proposal, or rejecting it. The responses aresent back to the initiator for combination and furtherrefinement cycles, or for initiation of a new round withthe next eContract proposal. During the negotiations,the participating organisations refine the contract termsuntil they are satisfactory.

The technical environment of the populator iscreated by the other Pilarcos middleware services(Kutvonen et al. 2007, 2005). As a representative ofopen service markets, the populator uses a service offerrepository. The technical contents of a service offer isdescribed in Table 2. Service offers have mandatorytypeIDs which define the mandatory elements for theoffer, including attributes.

The metainformation elements provided through theinfrastructure repositories must be trustworthy, as thepopulator builds on the model and typing informationto refine it into business network proposals. Trustingthe eContracting infrastructure requires strict controlover the type repository and business network modelrepositories. Before published entries can be stored,they must be validated, also in relation to the existingentries. The asserted relationships between stored en-tries must remain consistent.

These repositories have a considerable organisa-tional effect too, as they provide a means to regulateelectronic service markets. Service offer repositoriescan be controlled by requiring well-formed offers, oreven requiring certified enterprises to test offers beforeaccepting them. However, the service provider remainsautonomous, and its actions in the eCommunity maynot be in accordance with the service offer or the nego-tiated eContract. In other words, trust in the infrastruc-ture does not directly imply trust between potentialpartners in the eCommunity that is being formed. Trustbetween eCommunity partners is a concern of its own,

and is one of the aspects to be included into the eCon-tracting process.

The populator uses the type and service offerrepositories to produce interoperable business networkproposals. Like the repositories, population can beprovided as a service by a third party, although a peerimplementing a populator for itself is not unfeasible ei-ther. A populator must be trusted by the initiator of aneCommunity to match the business network model andservice offers as specified, but no further. The populatoroperates on published information only, and it is notnecessary to trust it with a private partner preferencepolicy, for example, unless there is a benefit in doingso. The populator is not told which of the proposals itproduces is accepted in the end.

A network management agent (NMA) represents aneCommunity member in the business network (Metsoand Kutvonen 2005). It handles negotiations with po-tential new members and renegotiations if members arechanged, it upkeeps state information for the eCom-munity, and determines the suitable reaction to theinformation passed to it by local monitors. For example,if the monitors detect a breach of the terms of theeContract, the violation can at worst lead to a reorga-nisation of the business network. Every member of theeCommunity has its own network management agent,and they are considered to be fully trusted local agents.

In order to bring trust considerations into the de-cision processes, support for trust management mech-anisms must be added into the infrastructure. Ourapproach is based on a dynamic combination of ex-perience information and a subjective analysis of thesituation in which trust is needed. Earlier experiencewith the eCommunity member being evaluated is gath-ered both locally and received through a global rep-utation network, and it forms a basis for predictingthe member’s future behaviour. On the other hand,

Table 2 Technical structure and XML tags of service offers

Element Mandatory Instances Explanation

typeID Yes 1 Identifies the service type the offer is based on.portOffer Yes 1-* Defines operations and their order regarding one port. Describes the proper-

ties of each port, and contains the pre and post conditions of each operation.syncStruct No 1 Provides causal relation of the events for synchronization.typingContext Yes 1 Defines the typing hierarchy that contains the service type which is used by

this service offer.serviceProperty No * Gives values to service attributes. Defines a name-value pair. The value can

either be a single type or a value range. The attributes must correspond tothe ones in the service type.

providerProperty Yes 1-* Describes properties of the service provider. The description is based on acommon ontology.

188 Inf Syst Front (2007) 9:181–194

subjectively estimated risk and tolerance for it alsodepend on various factors not directly dependent onthe particular member being evaluated, and our modelcontains factors to accommodate these considerationsas well.

4 eCommunity population

When an eCommunity is wanted for accomplishing ajoint goal or for some collaboration, one of the partnersinitiates the eCommunity establishment via its localNMA. This NMA first calls the populator, then, basedon the proposed eContracts, it runs a negotiation withthe NMAs of the other proposed partners.

The population request carries two information el-ements. The first, general part includes a reference tothe business network model to be used during the pop-ulation and directions for the populator for selectingservice offers for any of the roles. These directionscan advise on the desired number of returned sets ofoffers, or the maximum time the populator can use forsearching the interoperable sets. The directions can alsorestrict possible service providers or attribute values.The initiator can also refine the properties expressed inthe business network model. The model itself expressesrequirements for the eCommunity participants, for ex-ample, the offers can be required to indicate capabil-ity to support transactions. The second part expressesadvise on filling each role separately and can include apre-selected service offer, or directions to use specificselection criteria, or role-based utility functions. Theinitiator can also fill in service offers for known partnerswhich will participate in the following eCommunity.The populator respects these preliminary choices made,and even makes use of the knowledge by restricting thepotential search space accordingly.

Although the initiator is not required to include itsown service offer in the population request to representits own role in the business network, this is beneficial.The included offer will go through the same checkingprocess as all other service offers that will be consideredfor the business network. At the same time the includedservice offer and its attribute values acts as the startingpoint of the properties for the business networks. Simi-larly, the properties in the business network model havean effect on the eCommunity and its properties.

The population algorithm has seven steps (Ponka2004):

1. Retrieve the business network model and servicetypes referred to in the role descriptions.

2. Create role populators, set utility functions.3. Request matching service offers for roles from

the service offer repository using all appropriateservice types.

4. Check the interoperability of pre-filled roles.5. Find service offers for each role.6. Walk through the search tree and test interoper-

ability of service offer combinations.7. Return business network proposals.

At the first step, the populator retrieves the businessnetwork model from the corresponding repository. Themodel infers the roles and properties of interest. Ifthere is a conflict with the properties of the businessnetwork model and the properties given in the popula-tion call, the population algorithm is terminated.

For the second step, the populator creates role pop-ulators for each role named in the network model,to maintain role-specific information. This informationincludes current limits for attribute values, and theavailable service offers based on the attribute values.Utility functions are set as defined in the call; generalutility functions are individually set to each role.

Steps from three to five can execute concurrently.During the third step each role populator retrievesservice offers from the service offer repository for theirown role, taking into consideration the current limita-tions. A queue of service offers is attached to the rolepopulator, and each offer is flagged either to fulfil ornot fulfil the current additional requirements. While therole populators are waiting for the offers, they checkthe interoperability of service offers given for the pre-filled roles, potentially finding discrepancies and needfor terminating the algorithm.

The fifth step forms the main body of the populator.The population advances as a depth-first search in theirqueues of service offers. This corresponds to a tech-nique called forward checking, although the populatorimplementation includes other variations as well.

Here, a role populator locks the first offer of thequeue into the corresponding role. This proposed se-lection arises further requirements for offers to be ac-cepted for other roles, and those additional restrictionsare propagated to the other role populators. Those rolepopulators flag mismatching offers in their queues, thusreducing the search space. However, this temporaryremoval also allows the process to roll back in caseone or more remaining roles have no possible offersleft. The locking of service offers to roles is repeated ateach role populator until every role has a service offerlocked, all possible combinations are exhausted, or thetime limit given for the search is exceeded. The rolepopulators may retrieve more service offers from the

Inf Syst Front (2007) 9:181–194 189

offer repository, if the queue becomes empty before thesearch limits have been reached.

The populator uses attribute frameworks to managechains of attributes in the roles of the network modelthat must all have the same value, because the valuehas an effect on the interoperability of all roles in thechain. An example of such a requirement is transactionsupport along the whole supply chain. Essentially thismeans that each service offer must have the same at-tribute value for a given set of attributes if a role is apart of an attribute framework. Attribute frameworksmake the propagation of constraint values easy, andthey enable the populator to detect which attributevalues affect which roles.

The populator is able to match several differenttypes of attributes while testing service offers. The mainXML Schema simple data types are supported (all nu-meral types, string, anyURI, time, date, datetime, andboolean). In addition, there are a few different rangeswhich can be used. These include SomeOf and Exactly.The SomeOf range means that a number of the givenvalues must be the same but not all. Exactly meansthat all values must be the same as in other serviceoffers. For continuous values, the ranges are given as aminimum–maximum value pair and for non-continuousvalues the ranges are given as sets of values.

Utility functions are used to determine the benefitof including a given service offer to the eCommu-nity. Utility functions can be role specific, networkmodel specific, or the initiator can do the populationwithout them. The utility functions are defined as fol-lows (Ponka 2004):

U(a1, ..., an) =∑

i

wi fi(ai)

where ai is a constraint on attribute i, wi is the weightof the attribute, and fi is the function to calculate utilitybased on the value of the attribute. The function returnsa value from range [0,1]. The sum of the attributeweights is scaled to 1. It follows that the value of anutility function U is always in the range [0,1]. The higherthe value, the higher the utility.

Even though the populator can use utility functionsand first tries the offer with the highest utility value,it does not mean that the resulting business networkproposal has the highest possible total utility. This isbecause the depth-first search. For example, if the bestoffer for role two is chosen, the populator will try everypossible offer to role three before selecting the second-best offer for role two. Therefore the best offer for roletwo can result in a lower utility on the whole than thesecond-best offer for role two. This all depends on the

values of the attributes in a given service offer and theeffect the values have on the remaining roles.

Finally, at the seventh step, the populator returns thebusiness network proposals to the requesting networkmanagement agent. The populator cannot guaranteethat it finds the requested amount of proposals.

The populator has been found feasible to use foreCommunity discovery (Kutvonen and Metso 2005).The performance behaviour of the populator is ac-ceptable both in terms of delay and scalability. Theperformance of the populator is dependent on the con-straint propagation scheme used. The forward checkingmodel is efficient in reducing the size of the remainingsearch tree. The size of the search tree will effectivelydetermine how many possible combinations are left ata given time during the population. The size of thetree is not consistent through the whole population. Asmore roles have been filled with service offers, the sizeof the search tree will decrease. If the process has toroll back a role, the tree will grow in size again. Themain cost in this model is dependent on the efficiencyof calculating new constraints on the service offer at-tributes and propagating them. These constraint valuesare always recalculated when a role is filled duringthe population. The utility functions are just anotherway of calculating the constraints on the service offers.However, the complexity of an utility function plays afactor when using them. The more complex the utilityfunctions, the more time it takes from the populator tocalculate the utility value.

Compared to traditional trading facilities such asCORBA Trader (OMG 2002) and UDDI (Uddi reg-istry - technical specification 2006) the main advantageof our approach is the ability to match multiple serviceoffers into a functioning eCommunity, using an en-hanced service type system, in a way that is suitable forautomated interoperability testing and enforcement.The Pilarcos type repository provides an extensibleservice type system with a strict type discipline thattakes into account aspects of service behaviour andsemantics, subtyping, and relaxed matching of inde-pendently defined types with assessed relationships ortransformations between them. The service types pro-vide a basis for interoperability negotiations in termsof service offers and suitability to roles within knownbusiness network models.

5 Trust in eCommunity establishment

The population process acts on the public informationavailable in business network models and service offers.However, entering a collaboration involves additional

190 Inf Syst Front (2007) 9:181–194

motivations, policies and reasoning that is of a privatenature. Most importantly, the private decisions relateto trust between partners and trust in their businessservices.

Service offers and business network models are pub-lic information, but trust information includes privateevaluations which can have averse effects if they be-come public knowledge. For example, a subcontractormay not wish to make its distrust in a large vendorknown to the world, nor reveal details of its evaluationsof risks and incentives related to a particular businessnetwork composition. Participants should therefore beable to set trust requirements related to their businessnetwork models and service offers, while retaining con-trol of their private trust information. In addition, eventhese trust requirements should be made public only ifit adds value to the process.

Standard trust-related requirements, such as certi-fication for a particular service, can be included innetwork models and service offers and checked by thepopulator. They can be used as minimum requirementsor scored for utility calculations. The initiator can alsoprovide blacklists in its populator request to avoid re-curring proposals with unsuitable service providers.

In the Pilarcos middleware, the population of abusiness network can be provided as a service to theinitiator by a third party. If this party would be trustedby all potential partners, the private trust or policyinformation could be given out, but it is more realisticto keep the private decisions at the local NMAs. Afterhaving analysed different methods of using trust infor-mation in the population process, we have decided thatdue to privacy concerns, a populator is not given accessto enough information to filter or arrange service offersbased on trust (Kutvonen et al. 2006).

Therefore, trust decisions on the populator’s propos-als must be made at the negotiation phase. First, the ini-tiator selects a proposal it finds optimal and begins thenegotiations by sending it to other potential networkmembers, who can either accept it, make changes to itor reject it altogether. Trust decisions are made by theinitiator and the other negotiators on whether to jointhe network and on what terms (Kutvonen et al. 2006);later, during the operational phase, further trust deci-sions are made on whether a particular risk-relevantcommitment is considered reasonable (Ruohomaaet al. 2006).

In this negotiation phase, each NMA makes a trustdecision before committing to participate in the eCom-munity. A trust decision is the result of a subjectiveevaluation of local information combined with addi-tional third-party experience information received via

a reputation network. More formally, we define trust asthe extent to which one party is willing to participate ina given action with a given partner, considering the risksand incentives involved.

To produce a trust decision, the trust managementsystem checks whether its completed risk analysis iswithin tolerated values for that situation. A situationalcost-benefit estimate and representation of the toler-ance for the particular situation are generated dynami-cally from 7 factors defined below, and a trust decisionis produced by comparing the two.

Our trust model has 7 factors: trustor, trustee, action,reputation, risk, importance and context (Ruohomaaand Kutvonen 2005). The trustor, trustee and actionparameters, together with the current state of the sys-tem, determine the situation the trust decision is madein. The party making a subjective trust decision, thetrustor, is the guarded service, represented by an agent.The target of the decision is the trustee, another peerin the network. The action parameter denotes a groupof SOAP messages exchanged. For partner selectionpurposes, the action parameter can be seen to extendto cover the entire collaboration from a risk estimationpoint of view. Technically, however, it remains a set ofmessages exchanged with the populator, who in essenceacts as a proxy of the actual trustee by suggesting it as apossible partner for a collaboration.

Reputation is the measure of a peer’s perceivedtrustworthiness. It is based on a subjective view com-bined from experience information received throughlocal monitoring as well as through reports from otherpeers in a global reputation network. The credibilityand information content of the statements are evalu-ated by the recipient in order to build a local reputationvalue.

The risk factor provides a tactical cost-benefit esti-mate on the action considered. It expresses the poten-tial benefits and costs of a positive trust decision todifferent assets, such as money, security and customersatisfaction. The information is stored as probabilityvalues for each severity class of effects to a particularasset, for example a 0.1 probability of a “considerable”loss of security, 0.3 probability of a “minor” loss and0.6 probability of no effect. For example for monetaryassets, a positive result is both possible and desirable.The action parameters and the reputation of the trusteeaffect this estimate, as well as the context adjustmentsdescribed later.

The importance factor represents strategic valu-ations in the enterprise, which are independent ofany estimate of what the trustee might do. Theseconsiderations, such as the cost of denying an action

Inf Syst Front (2007) 9:181–194 191

defined in the eContract, or the benefit of good serviceto creating a working partnership, guide the toleranceof risk.

The context factor represents temporary adjust-ments made to other factors, especially risk and im-portance. The changes can be initiated by any of threepossible source types: the internal state of the peer’ssystem, the state of the enterprise in general or the stateof the eCommunity the peer is a member of.

6 Operational time issues in eCommunity management

The eCommunity establishment phase can consideronly those aspects of interoperability that can be ex-pressed statically in the service type and the businessnetwork model definitions, or as ranges of acceptablepolicy decisions in service offers. However, policies andcontext of the collaboration can change, or the partnerscan even fail or prioritise some other eContract orenterprise policy. Therefore, operational time supportfor the eCommunity is essential.

The operational time support consists of monitor-ing of partners for behaving according to the eCon-tract rules, maintenance of progress information of thecollaboration task, and the management of partner-initiated changes or system-initiated changes that arecaused by breach detection services. Here we concen-trate only on breach detection and breach management.These are the parts mostly involved with trust manage-ment and reputation formation.

In the Pilarcos architecture, each business service isguarded. These guards take care of the restriction ofthe computational service capabilities to those exter-nally available facilities we call the business service.The guards work in two ways. First, they protect thebusiness service from inappropriate messaging fromoutside. Second, they restrict the business service fromusing its full capabilities in situations where enterprisepolicies only allow a restricted form of the service to beprovided to partners.

These guards are implemented by rule-based moni-tors located at the communication end-points of eachservice. The monitors continuously evaluate whetherthe observed messaging is conformant to the expectedbehaviour explicated in the eContract.

The monitors are configured with information fromthe eContract and internal business policies. The coreof the monitors consists of a traffic analyser advisedby a state-machine. For the analyser, it is possible toconfigure different behaviour expectations by describ-ing the incoming and outgoing message exchange of the

current partner as state changes, and to define actionrules and evaluation rules. The action rules are usedfor marking the progress of the business processes andfor collecting a coarse-grain state of the eCommunityprogress. The rule advises the monitor to report thecompletion of a subsequence of messaging as a com-pleted task to the local NMA, which in turn can reportto other NMAs. Logically, this splits the state-machineinto an abstract task-oriented machine, and a concretemessage-level analyser. The grouping of messages totasks can be derived from annotations in the busi-ness network models. The evaluation rules can addressany aspect of the exchanged messages, for example,aspects common in the security area: the content ofmessages for information content restrictions, or even,use techniques from intrusion detection (Ruohommaet al. 2006; Viljanen 2005b). Based on the evaluationrules, the monitor can raise problem notifications onbreach, missing message, and information content mis-match issues.

If a monitor detects a pattern of abnormal behaviour,it sends a report to the local NMA. The NMA decideswhether the abnormal behaviour triggers a breach orwhether it is a minor incident that is to be repairedlocally. If the NMA considers the incident to be seri-ous, it contacts the other NMAs of the eCommunity,suggesting that a resolution process is started.

The monitors can be set either to passive, active,or proactive mode. In passive monitoring, the eventsare only logged for further examination, while in ac-tive mode the monitor logs events and actively reportsmismatches to NMAs. Proactive monitoring preventsmismatches from happening by blocking mismatchingmessages from being sent or received by the services.

The proactive monitoring has the highest cost, butprovides the highest level of breach prevention and ser-vice interoperability guarantees. Selecting the granular-ity and mode of monitoring is a major scalability designchallenge for the system administrators. This calls foradditional, more sophisticated tools for analysing costof alternative configurations.

The monitoring approach is used in other relatedprojects as well, ranging from monitoring of the successof business processes (Rabelo et al. 2000; Daskalopuluet al. 2002) and monitoring of the business itself(Scheer et al. 2004) to intrusion detection (Viljanen2005a). Most approaches with the same level of mon-itoring goals use a passive approach: for example,BCA (Quirchmayr et al. 2002) provides a centralisednotary to detect contract breaches post-operatively.

For resolving the detected breaches, the Pilarcosarchitecture requires the eContract to carry references

192 Inf Syst Front (2007) 9:181–194

to the agreed resolution process. In principle, differentbusiness network models have different properties interms of recovery potential, and the choice of the re-covery process is not free. Depending on the verified re-coverability properties of the business network model,it may be possible to compensate and restart, or replacea member and roll it to the state expected by othersin the eCommunity. Furthermore, the participants ofthe recovery phase may be different from the set of theoriginal eCommunity members. The current prototypeis able to initiate a simple negotiation on whether aparticipant is replaced or not but we have envisionedthat a new epoch is started for the resolution.

The resolution process also introduces a position inwhich bad experience or good experience can be fedinto the reputation management system, to be usedin future local trust decisions and shared with othermembers of the reputation network.

7 Conclusion

This paper proposes an automated, generic method foreCommunity management in an inter-enterprise, openenvironment. There are two phases in the manage-ment: community establishment and monitoring of thecommunity for fulfilment of trusted activities. For theestablishment phase the Pilarcos middleware providesfacilities for selecting eCommunity participants withfocus on the social and contractual aspects, especiallyexternal business processes, concept of utility, and trustin potential collaborators. The solution is based onmulti-partner matching of service offers, guided by ajointly selected, public business network model. It thusextends the traditional trading or brokering architec-tures. The presented eContract structure pulls out pub-lishable aspects of interoperability issues, still leavingsome pragmatic aspects private. For the operationalphase the Pilarcos middleware provides facilities formonitoring business services against the expectations ofthe eContract and local enterprise policies. The moni-toring information can be used as feed-in for the repu-tation management network that affects trust decisionsof later eCommunity establishments, and as triggersfor breach management processes for the eCommunityinvolved.

The solution differs from other eContracting ap-proaches by capturing all three aspects, social, contrac-tual and technical, into an automated process where allfunctional and non-functional aspects of the collabora-tion are treated according to a few simple principles.The main design goal has been to separate interoper-

ability and eCommunity management tasks into a B2Bmiddleware layer that is founded on metainformationrepositories for business networks, business servicesand contractual rules. The solution is closely relatedto work on virtual enterprises and virtual enterprisebreeding environments, but takes a more pragmaticview in the separation of generic B2B negotiation andeCollaboration management routines.

The Pilarcos approach is strongly based on feder-ation across enterprises and services that are encap-sulated and autonomously administered. This trend isbecoming visible on larger scale standardisation activ-ities and new EU research agendas. Because of theservice-oriented nature of our approach it aligns wellwith RM-SOA (McKenzie et al. 2006), although thelevel of automation aimed at requires us to introducea more extensive set of concepts than the RM-SOA.NESSI (Nessi strategic research agenda 2006) is a newEuropean initiative to bring service oriented businessmodels closer to reality, with a goal to outline anICT framework for future service-oriented architec-tures and economy. The NESSI goals are similar tothose in EU FP7 (FP7 2006) where the key issuesof Pilarcos goals appear: federation, model-governedmanagement, trust management with local trust deci-sion but with global reputation information and oth-ers. Many other breeding environment projects for vir-tual enterprises, like ECOLEAD (Camarinha-Matosand Afsarmanesh 2006; Rabelo et al. 2006), focus ei-ther on supporting collaboration between humans byjoint facilities, or require stepwise human negotiationfor designing the actual collaboration-supporting agentsystem.

The proposed management of trust consists of localtrust decision when entering eCommunities and at eachtrust-guarded transaction. The decisions take into con-sideration globally available reputation information,either positive or negative. The reputation informa-tion must be associated with fairly permanent targetswith well-known identities; the targets shall be busi-ness services. Our approach differs from other trust-management work by emphasising private, subjectivedecisions at each enterprise at the level of businessservices, based on both technical and business-levelinformation. Otherwise the goals are fairly similar tothose of the TrustCOM project (Wilson et al. 2006) orSECURE (Cahill 2003). However, TrustCOM enforcesdistributed business process execution, and UDDI-based service discovery. For the SECURE project thathas implemented a trust management system aimedfor private persons, the battle against the Sybil attack(results from inexpensive new identities) is essential. In

Inf Syst Front (2007) 9:181–194 193

contrast, we require stable identity management, andfurthermore support of a robust reputation manage-ment network (Ruohomaa et al. 2007).

A number of challenges have to be addressed forfurther maturing the federated management architec-tures. First, the framework for eContracts should bestandardised and a global knowledge base for inter-operability information established (Kutvonen 2007).Second, a suitable identification mechanism needs tobe created for associating trust, reputation, security andcontract information to business services. The existingdevelopment does not address the required granularity.Third, the experience turned into reputation informa-tion should be based on a commonly acceptable frame-work of concepts, ranging, for example, from successfuland correct performance in business transactions toillegal transactions or breaches of technical criteria.For all these axes, ontologies should be developed tocapture the metrics to be used. Finally, the role weenvision for reputation systems, service selection sys-tems and interoperability knowledge-bases in the opencollaborations creates new vulnerabilities. We havestarted a comprehensive threat analysis, but additionalwork is still needed for creating a system that wouldresist these new threats beyond the means alreadyembedded in the architecture. The current facilitiesalready address these threats in ways that determinearchitectural decisions, such as encapsulation of servicetype information into trusted knowledge bases, beingprepared for operational time breaches for autonomyreasons, and including a set of negotiation protocols inthe management facilities.

Acknowledgements This work has been carried out at theDepartment of Computer Science at the University of Helsinki.The research group involved, Collaborative and InteroperableComputing group, builds on work done in various projectsfunded by the national technology development center TEKESand industrial partners.

References

Angelov, S., & Grefen, P. (2003). The 4W framework for B2Be-contracting. International Journal of Networking and Vir-tual Organisation, 2(1), 78–97.

Booth, D., Champion, M., Ferris, C., McCabe, F., Newcomer, E.,& Orchard, D. (2004, February). Web services architecture.(http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/)

Cahill, V. (2003, August). Using trust for secure collaboration inuncertain environments. Pervasive Computing, 2(3), 52–61.

Camarinha-Matos, L. M., & Afsarmanesh, H. (2006, September).Modeling framework for collaborative networked orga-

nizations. In Network-centric collaboration and support-ing frameworks. Seventh IFIP working conference on vir-tual enterprises (pp. 3–14). Berlin Heidelberg New York:Springer.

Chiu, D. K. W., Cheung, S. C., Hung, P. C. K., Chiu, S., &Chung, K. (2005, July). Developing e-Negotiation Supportwith a contract template meta-modeling approach in a WebServices environment. Special issue on web services andprocess management in the Decision Support System (DSS),40(1), 51–69. (http://teaching.ust.hk/~csit600c/eNeg.pdf)

Daskalopulu, A. (2002). Evidence based electronic contract per-formance monitoring. The INFORMS journal of groupdecision and negotiation. Special issue on formal modellingin E-Commerce.

Daskalopulu, A., Dimitrakos, T., & Maibaum, T. (2002, Novem-ber). Evidence-based electronic contract performance mon-itoring. Group Decision and Negotiation, 11(6), 469–485.

Dellarocas, C., & Klein, M. (1999, December). Designing robust,open electronic marketplaces of contract net agents. In Pro-ceedings of the 20th International Conference on InformationSystems (ICIS), Charlotte, NC.

FP7 (2006, April). European commission 7th frameworkprogram. (http://ec.europa.eu/research/fp7)

Griffel, F., Boger, M., Weinreich, H., Lamersdorf, W., & Merz,M. (1998). Electronic contracting with COSMOS – Howto establish, negotiate and execute electronic contractson the Internet. In Proceedings of second internationalEnterprise Distributed Object Computing Workshop(EDOC’98).

Grosof, B. N., & Poon, T. (2003). SweetDeal: Representing agentcontracts with exceptions using XML rules, ontologies andprocess descriptions. In Proceedings of International Confer-ence on the world wide web.

IS10746 (1996). Information Technology – open systems intercon-nection, data management and open distributed processing.Reference model of open distributed processing.

Kutvonen, L. (2007). Building B2B interoperability middleware– Knowledge management issues. In Interoperability for En-terprise Software and Applications (I-ESA2007).

Kutvonen, L., & Metso, J. (2005, September). Services, contracts,policies and eCommunities – Relationship to ODP frame-work. In P. Linington, A. Tanaka, S. Tyndale-Biscoe, & A.Vallecillo (Eds.), Workshop on ODP for Enterprise Comput-ing (WODPEC 2005) (pp. 62–69).

Kutvonen, L., Metso, J., & Ruohomaa, S. (2006, October). Fromtrading to eCommunity population: Responding to socialand contractual challenges. In Proceedings of the 10th IEEEinternational EDOC conference (EDOC 2006). Hong Kong:IEEE.

Kutvonen, L., Metso, J., & Ruokolainen, T. (2005). Inter-enterprise collaboration management in dynamic businessnetworks. In On the Move to Meaningful Internet Systems2005: CoopIS, DOA, and ODBASE: OTM ConfederatedInternational Conferences, CoopIS, DOA, and ODBASE.(Vol. 3760). Agia Napa, Cyprus.

Kutvonen, L., Ruokolainen, T., & Metso, J. (2007, Janu-ary). Interoperability middleware for federated businessservices in web-Pilarcos. International Journal of En-terprise Information Systems, Special issue on Interop-erability of Enterprise Systems and Applications, 3(1),1–21.

Linington, P. F., Milosevic, Z., Cole, J., Gibson, S., Kulkarni, S., &Neal, S. (2004, October). A unified behavioural model and acontract language for extended enterprise. Data Knowledgeand Engineering Journal, 51(1), 5–29.

194 Inf Syst Front (2007) 9:181–194

McKenzie, C. M., Laskey, K., McCabe, F., Brown, P. F., &Metz, R. (2006, July). Reference model for service orientedcomputing 1.0. (http://www.oasis-open.org/committees/download.php/19679/soa-rm-cs.pdf)

Metso, J., & Kutvonen, L. (2005, September). Managing vir-tual organizations with contracts. In Workshop on ContractArchitectures and Languages (CoALa2005). Enschede, TheNetherlands.

Nessi strategic research agenda (2006, February 13). NESSI SRA.(Public draft 1).

OASIS ebXML Collaboration Protocol Profile and AgreementTechnical Committee (2002, September). Collaboration-protocol profile and agreement specification. (http://www.oasis-open.org/committees/ebxml-cppa/documents/ebcpp-2_0.pdf)

OMG (2002). Corba trading service. (http://www.omg.org/cgi-bin/doc?formal/2000-06-27)

Papazoglou, M. P., & Georgakopoulos, D. (2003). Introduction.Communications of the ACM, 46(10), 24–28.

Ponka, I. (2004). Populaattori. University of Helsinki. (Internalreport, in Finnish.)

Quirchmayr, G., Milosevic, Z., Tagg, R., Cole, J., & Kulkarni,S. (2002). Establishment of virtual enterprise contracts. InDatabase and expert systems applications : 13th internationalconference (Vol. LNCS 2453, p. 236). Berlin Heidelberg NewYork: Springer.

Rabelo, R., Camarinha-Matos, L. M., & Vallejos, R. V. (2000).Agent-based brokerage for virtual enterprise creation inthe moulds industry. In E-business and virtual enterprises.(http://gsigma-grucon.ufsc.br/massyve)

Rabelo, R. J., Gusmeroli, S., Arana, C., & Nagellen, T. (2006).The ECOLEAD ICT Infrastructure for Collaborative Net-worked Organizations. In Network-centric collaborationand supporting frameworks (Vol. 224, pp. 451–460). BerlinHeidelberg New York: Springer.

Rasmusson, L., & Jansson, S. (1996). Simulated social controlfor secure Internet commerce. In Proceedings of the 1996workshop on new security paradigms (pp. 18–25). Lake Ar-rowhead, Calfornia, USA: ACM.

Ruohomaa, S., & Kutvonen, L. (2005, May). Trust manage-ment survey. In Proceedings of the iTrust 3rd internationalconference on trust management (pp. 77–92). Paris, France:Springer-Verlag (LNCS 3477/2005).

Ruohomaa, S., Kutvonen, L., & Koutrouli, E. (2007, April). Rep-utation management survey. In Proceedings of the second in-ternational conference on availability, reliability and security(ARES) (pp. 103–111). Vienna, Australia: IEEE ComputerSociety.

Ruohomaa, S., Viljanen, L., & Kutvonen, L. (2006, March).Guarding enterprise collaborations with trust decisions—The TuBE approach. In Proceedings of the first inter-national workshop on Interoperability Solutions to Trust,Security, Policies and QoS for Enhanced Enterprise Systems(IS-TSPQ 2006). Bordeaux, France: Springer-Verlag.

Ruokolainen, T., & Kutvonen, L. (2006). Service typing in col-laborative systems. Interoperability for Enterprise Softwareand Applications Conference (I-ESA’06). Bordeaux, France:Springer-Verlag.

Scheer, A.-W., Abolhassan, F., & Jost, W. (2004). Businessprocess automation: ARIS in practice. Berlin HeidelbergNew York: Springer.

Schoop, M., Jertila, A., & List, T. (2003). Negoisst: A negotiationsupport system for electronic business-to-business negoti-ations in E-Commerce. Data and Knowledge Engineering,47(3), 371–401.

Singh, M.P., & Huhns, M.N. (2005). Service-oriented computing:Semantic, processes, agents. New York: Wiley.

Thatte, S., et al. (2005). Business process execution languagefor web services. (ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf)

Uddi registry - technical specification (2006, February).(http://uddi.org/pubs/uddi_v3.htm)

Viljanen, L. (2005a). A survey on application level intrusiondetection vol.C-2004-61; Tech. Rep. University of Helsinki,Department of Computer Science.

Viljanen, L. (2005b). Towards an ontology of trust. In Proceed-ings of the 2nd international conference on Trust, Privacyand Security in Digital Business (TrustBus’05). Copenhagen,Denmark: Springer-Verlag, LNCS 3592/2005.

Wilson, M., et al. (2006, March). The TrustCoM approach toenforcing agreements between interoperating enterprises.In Interoperability for Enterprise Software and ApplicationsConference (I-ESA’06). Bordeaux, France: Springer-Verlag.

Xu, L., & Jeusfeld, M. A. (2003). Pro-active monitoring ofelectronic contracts. In Proceedings of CAiSE 2003. BerlinHeidelberg New York: Springer.

Lea Kutvonen holds a PhD in Computer Science from Universityof Helsinki. She leads a research group on Collaborative andInteroperable Computing (CINCO), within the specialisationarea of Networking in Open Distributed Systems of the Depart-ment of Computer Science. Her interests include inter-enterprisecomputing and interoperability, developing B2B middleware so-lutions, distributed computing architectures, trust managementand other nonfunctional aspects of enterprise interoperability.

Janne Metso holds a MSc in Computer Science and he iscurrently a PhD student in the CINCO group at the University ofHelsinki. His research is focused on runtime negotiation facilitiesand expert system support for establishing and maintaing inter-enterprise collaborations.

Sini Ruohomaa holds an MSc in computer science and she is cur-rently a PhD student in the CINCO group. Her research interestsinclude trust and reputation management in open collaborationsystems and inter-enterprise computing.