from trading to ecommunity management: …...inf syst front (2007) 9:181–194 doi...
TRANSCRIPT
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: [email protected]
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.