TOWARDS AUTOMATED SERVICE TRADING

Manuel Resinas, Pablo Fernandez, Rafael Corchuelo

ETS Ingenieria Informatica

University of Seville

Keywords:

Service Oriented Computing, SLAs, Trading.

Abstract:

The service-oriented architecture is a promising means to support outsourcing amongst real-time enterprises.

In this context, SLAs (Service Level Agreements) are essential because they grant guarantees about how

a service must be provided or consumed. We deﬁne service trading as the process of locating, selecting,

negotiating, and creating SLAs. Although automating the service trading process is a key characteristic of a

real-time enterprise, to the best of our knowledge it has not been completely addressed yet.

In this article, we propose a conceptual framework for automated service trading. Therefore, our goal is not

to implement a concrete architecture but to develop a framework that can be used to deﬁne, compare and

analyse the interoperability of different service trading architectures. The novel contributions of this paper are

threefold: we identify the roles and interactions that are necessary to carry out this automated service trading,

we motivate and introduce the idea of trading protocols, and we deﬁne the elements that are necessary to

support an automated decision-making in service trading.

1 INTRODUCTION

In recent years, we have witnessed how new tech-

nologies are enabling the emergence of a new age of

enterprises that quickly adapt to their ever-changing

business environments but keep their costs under con-

trol. This is the main characteristic of what has been

called real-time enterprises. Two elements are the key

to achieve this vision: the management and analysis

of the information collected by the enterprises related

to their business environment, and the ability to use

products or services offered by other enterprises as

components for further innovation.

The service-oriented computing paradigm

(Curbera et al., 2003) and the service-oriented

architectures based on web services are the mechan-

ims used to support this idea of using services offered

by other companies as pieces of our systems. In this

context, SLAs (Service Level Agreements) are a key

point because they grant guarantees about how a

service will be provided or consumed by establishing

both functional and non-functional requirements that

must be fulﬁlled by both parties during the service

execution. Additionally, SLAs allow providers to

deploy an automated provision of services based on

the SLAs agreed with their customers (Ludwig et al.,

2005).

We deﬁne service trading as the process of locat-

ing, selecting, negotiating, and creating SLAs. The

service trading is a subprocess of a more general con-

tracting process that was already deﬁned in (Ludwig,

2003). Although there are infrastructures to provision

SLAs and services (Ludwig et al., 2005) that agree

with them automatically, there is little support, to the

best of our knowledge, to tackle the service trading

process, which is still mostly a human-centric pro-

cess. However, automating the service trading pro-

cess is a key characteristic of a real-time enterprise.

In this paper, we take the ideas exposed in (Lud-

wig, 2003) as a starting point and propose a concep-

tual framework for automated service trading. The

framework is divided into six organisations

(discov-

ery, information, selection, agreement making, bind-

ing, and trading), and each one cares for a speciﬁc

subgoal in the whole service trading process. Our

goal is not to implement a concrete architecture but

We borrow this term from the GAIA methodol-

ogy(Zambonelli et al., 2003). An organisation does not

amount to a company or a department but to a number of

agents that work together

Resinas M., Fernandez P. and Corchuelo R. (2006).

TOWARDS AUTOMATED SERVICE TRADING.

In Proceedings of the International Conference on e-Business, pages 38-45

DOI: 10.5220/0001428000380045

 SciTePress

to develop a conceptual framework that can be used

to deﬁne, compare and analyse the interoperability of

different service trading architectures.

Our work advances the state of the art in service

trading in the following. First, we clearly identify the

roles that are necessary to carry out this service trad-

ing as well as the relationships between them. Sec-

ond, we motivate and introduce the trading protocols,

which are a speciﬁcation of the global behaviour of

the trading system from a temporal point of view.

And third, we deﬁne the elements that are necessary

for an automated decision-making in the service trad-

ing process. This bridges the two key elements of a

real-time enterprise mentioned before: the manage-

ment and analysis of the information collected by the

enterprises as the basis of the decision-making, and

the ability to use services offered by other enterprises

through the automated creation of SLAs.

The structure of this article is the following. Next,

in Section 2, we brieﬂy introduce the organisational

metaphor and we describe the conceptual framework.

Section 3 compares our framework with other propos-

als developed by both the industry and the academy,

and we conclude and enumerate future work in Sec-

tion 4.

2 CONCEPTUAL FRAMEWORK

Several phases have been identiﬁed on the contracting

process (Ludwig, 2003) (as it is shown in the left part

of Figure 1): The ﬁrst step that appears in the ﬁgure is

outside the contracting process and it has been called

preparation phase. This step involves the creation of

the offer by the provider of the service and the anal-

ysis of its functional and non-functional requirements

by the consumer. In the contracting process itself, ﬁrst

step is deﬁned as information phase whose goal is to

match service providers with potential consumers and

vice versa. In the next phase, they may start a ne-

gotiation with those consumers or providers to ﬁnd

a mutually acceptable agreement. At the end of this

phase the result is the creation of an agreement on the

execution of a service between a provider and a con-

sumer. In the fourth phase, both service provider and

service consumer set up a deployment plan to make it

possible to follow all terms established in the agree-

ment settled in the previous phase. The last phase in

the contracting process is the fulﬁlment phase. This

phase involves the fulﬁlment of the obligations estab-

lished in the agreement and in the monitoring of the

whole process in order to ensure that both parties ob-

serve the agreement correctly.

The conceptual framework proposed in this article

is focused on the information and negotiation phases.

Therefore, on the one hand, input to the framework

Figure 1: Conceptual framework.

consists in the requirements gathered during prepa-

ration phase. We call user preferences to this set of

information developed in the preparation phase; addi-

tionally, it is worth pointing out that our idea of user

is independent of the nature of the stakeholder, i.e.

whether user stands for a service consumer or a ser-

vice provider. On the other hand, the output of the

framework is a established SLA. This SLA can be

used to drive the further deployment and fullﬁlment

phases.

In order to deal with the complexity of the service

trading problem, we use the organisational metaphor

(Zambonelli et al., 2003) where organisations are out-

lined developing a general architectural characteriza-

tion of the problem. In so doing, our model is com-

posed of six organisations (depicted in the central-

right part of Figure 1) that interact amongst each

other.

As an introduction to the conceptual framework,

we can sketch the global behaviour of organisations as

following: The discovery organisation performs the

process of locating a set of potential providers or con-

sumers according to a number of functional and non

functional requirements; candidates discovered, are

then passed to the information organisation in order to

gather detailed information about the characteristics

and preferences of each potential party. This infor-

mation is subsequently used by the selection organi-

sation to create and select a set of promising agree-

ment proposals with other parties. Proposal selected

are also analysed to decide whether we would start

a negotiation process with other parties or produce

a take-it-or-leave-it offer. This instructions are del-

egated to the agreement making organisation respon-

sible to actually negotiate or propose the agreement to

other party. During this procedure, agreement making

organisation interact with the binding organisation by

asking for approval to make or accept binding offers.

In so doing, the responsiblity of the binding organisa-

TOWARDS AUTOMATED SERVICE TRADING

tion can be seen as to determine when an offer may

be accepted.

Finally, the main goal of the trading organisation is

to specify a choreography that will regulate how the

whole process is carried out, that is, it cares of start-

ing the search for parties, submitting offers, waiting

for responses, starting negotiations or sending binding

offers. Additionally, trading organisation monitorise

the market (making use of the discovery organisation)

in order to decide when the agreement search should

be started.

The remainder of this section describes each organ-

isation detailing their goals and the roles that can be

identify on them.

2.1 Trading

In general, service trading is a process whose de-

tails change from scenario to scenario depending on

the type of parties involved and the temporal require-

ments to be met. In order to deal with these issues, it

is necessary an orchestration of the different stages in

the trading process.

The trading organisation focuses on the global be-

haviour from a temporal point of view. Its goal is the

coordination of the remain layers so as to implement

a trading protocol.

To understand what a Trading Protocol is, we use a

simple real-life example: A public bidding where an

institution looks for a service provider and devises a

trading protocol that consists of the following stages:

the announce of the bidding, a deadline for the sub-

mission of proposals, a period of resolution and, ﬁ-

nally, the communication of results. The trading pro-

tocol also states temporal constraints for each stages.

Building on these ideas, the trading organisation

should address the following issues: (i) A taxonomy

of Trading Protocols, (ii) a repository with implemen-

tations for each Trading Protocols, (iii) the manage-

ment of the life-cycle of the elements in the system,

including a mechanism for the instantiation of the ac-

tors that implement the trading protocol, and (iv) a

deﬁnition of the temporal parameters that will control

the behaviour of other organisational. These parame-

ters would be passed to the actors of those organisa-

tions.

This organisation is composed of the following

roles:

• The Trading Protocol Selector role analyses user

preferences to decide which of the known trading

protocols best suits to the temporal contraints es-

peciﬁed on the preferences.

• The Customer Manager role is in charge of inter-

acting with the environment in order to handle user

preferences. Consequently, this role transmit the

appropriate part of these preferences to the rest of

the roles. Additionally, this role is the responsi-

ble for trigger the search based on market status

and knowledge harvested from pervious searches.

Once a given search is about to start, this role is

asisted by the Trading Protocol Selector to invoke

the approporiate actors that would develop the trad-

ing protocol used on the search.

2.2 Discovery

In the discovery organisation the main aim consist in

locating potential parties demanding (or supplying) a

service that other party provides (or needs). In order

to deal with the issues related with discovery, we can

identify the following requirements:

• An infrastructure for a taxonomy of services. Each

demand or provision of service should be cat-

alogued based on the taxonomy; the classify-

ing criteria may include both functional and non-

functional features.

• A method for registering new trading events. An

example of such an event would be the fact that an

entity is searching for service providers of a given

type (as speciﬁed in the taxonomy).

• A way to store access points to the different actors

that generate events.

• A method for subscribing to events. This is nec-

essary to feed the knowledge base used to decide

when an agreement search must be started or the

results of a previous search must be reﬁned. This

information might also be useful for some negotia-

tion strategies.

• A protocol to exchange and propagate events

amongst organisations.

• An addressing speciﬁcation to provide a mecha-

nism to access and identify actors.

Roles in this organisation include:

• The Discovery Service role represents an abstrac-

tion of the discovery infrastructure that should be

reﬁned in further concrete models. Different infras-

tructures can be selected from a wide range of mod-

els: from a centralized paradigm to a distributed

one.

• The Market Mediator role is in charge of adapt-

ing local knowledge model in a given party to the

appropriate discovery infrastructure. This adapta-

tion make independent the characteristics of mar-

ket modelized by the discovery service to the rest

of organisations.

• The Tracker role is the active part that make use of

the discovery service to search for some particular

trading event.

ICE-B 2006 - INTERNATIONAL CONFERENCE ON E-BUSINESS

• The Advertiser role is the complementary role for

Tracker generating trading events to be searched.

This trading events, should be parametrized with

the most signiﬁcative user preferences that can be

made public.

2.3 Information

The goal of this organisation is to manage the pub-

lic information about the user preferences and the

potential candidates found by the discovery organ-

isation. The amount and type of information col-

lected from each candidate may be different; how-

ever, at a conceptual level the information should in-

clude, at least, the public features about the service

demanded/supplied. In addition, some information

can be harvested from external sources, e. g., infor-

mation about the reputation of the candidate.

Roles in this organisation include:

• The Inquirer role polls the different Informants lo-

cated by the Discovery organisations. In this pro-

cess, this role can select different strategies of quer-

ing, depending on the intraction standard and the

type of information needed to match user prefer-

ences.

• The Informant role is the responsible for publish

all the public user preferences that can be usefull to

other parties in order to evaluate the possibilities to

become a business partner.

Both Inquirer and Informant must implement a

compatible speciﬁcation of a format to express func-

tional and non-functional features of services and a

procedure to query and to inspect services. In addi-

tion, the Inquirer must provide an integration of the

service features format with the taxonomy of the dis-

covery layer.

2.4 Selection

The aim of the selection organisation is to choose a

set of candidate parties with whom a negotiation pro-

cess can be started or to whom an agreement proposal

can be submitted. The selection starts with a set of

information about potential parties coming from sev-

eral sources: information provided by the information

organisation after an active search, agreement propos-

als received from other parties, and non-successful of-

fers

coming from the binding organisation, so that

they can be processed again.

The selection process is carried out by the follow-

ing roles:

These offers are non-successful because either they

were not good enough for us or the other party rejected

them.

• The Proposal builder role creates agreement pro-

posals based on the information gathered by the in-

formation organisation. Then it sends these agree-

ments proposals to the Proposal collector.

• The Proposal collector receives the agreement pro-

posals generated by the Proposal builder as well as

the agreement proposals coming from other parties

through the Proponent role and submits them to the

Proposal ﬁlter. Optionally, it can kept them until an

event occurs. For instance, they can be kept until

the negotiation phase ﬁnishes.

• The Proponent role represents the party that is sub-

mitting us a proposal.

• The Proposal ﬁlter role is in charge of ﬁltering the

agreement proposals collected by the Proposal col-

lector and the non-successful offers coming from

the binding organisation. The ﬁlter criteria are not

unique but, in most cases, they depend on the pref-

erences given by the user and the status of the

whole service trading process. After this process,

several proposals are rejected and the others are

sent to the Proposal dispatcher role.

• The Proposal dispatcher sends the proposal to the

most appropriate Agreement Maker. One system

may have several Agreement Makers with differ-

ent characteristics and one of them may be better

than the others for certain conditions. For instance

one Agreement Maker can implement auction pro-

tocols, another one can implement bilateral nego-

tiation protocols, and another one can implement

just a take-it-or-leave-it protocol.

2.5 Agreement Making

The goal of the agreement making organisation is to

provide a mechanism to create agreements, possibly

through an automated negotiation process, that are ac-

ceptable to all the parties involved in them. There-

fore, the result of this organisation is an agreement

that speciﬁes the terms under which the service shall

be executed. This may include both functional and

non-functional terms.

Consequently, the requirements of the agreement

making organisation are: it must support an agree-

ment format that must be understood by both parties

and that allows them to identify the terms of the agree-

ment; it must implement at least one protocol to create

agreements and, optionally, to negotiate them; it must

provide decision making mechanisms to evaluate the

offers received and generate their own bids or coun-

teroffers if necessary, and it must offer a way to create

reliable and non-repudiable agreements.

The protocols to create agreements can range from

a very simple form of communication such as the sub-

mission of an offer by one party and its acceptance o

TOWARDS AUTOMATED SERVICE TRADING

rejection by the other one, to a more complex form

based on negotiation protocols. A negotiation proto-

col establishes the rules that govern the negotiation

and the way the communication amongst the parties

involved in the negotiation is carried out. The most

common negotiation protocols are based on the sub-

mission of offers and can be categorised into auctions

(Str

obel and Weinhardt, 2003) (e.g. English, Dutch or

Vickrey) and bilateral negotiations. Bilateral negotia-

tions involve the exchanging offers and counteroffers

between the two parties carying out the negotiation

(Sierra et al., 1997).

The decision-making mechanisms determine the

way the parties involved in the negotiation process be-

have. There are four parts that sould be implemented

in these decision-making mechanisms: (i) an offer

evaluation, usually carried out through the deﬁnition

of utility functions to each term of the agreement; (ii)

a decision on which response shall be sent to the coun-

terparty; (iii) a construction of a counteroffer if nec-

essary (Faratin et al., 1998; Faratin et al., 2002; Karp

et al., 2004), and (iv) a model of the world and of our

opponents in order to improve our negotiation capa-

bilities (Zeng and Sycara, 1998).

We have identiﬁed three roles in this organisation:

• The Agreement Maker is the role that implements

our agreement creation mechanism. Therefore, it

must understand an agreement format and support

at least one protocol to create agreements. This

role can act almost as a proxy if it just imple-

ments a take-it-or-leave-it agreement creation pro-

tocol. However, it can be very complex if it under-

stand several negotiation protocols and has to cre-

ate bids or counteroffers. There is no restriction on

the number of Counter-parties that the Agreement

Maker can be negotiating simultaneously.

• The Counter-party role represents the party that we

are trying to reach an agreement with. This role

must implement the same communication protocol

and agreement format as the Agreement Maker.

• The Notary role must guarantee that the agreement

created between the two parties is reliable and non-

repudiable.

2.6 Binding

The goal of the binding organisation is to determine

when a binding offer must be submitted and whether

a binding offer that has been received should be ac-

cepted. In addition, this organisation must establish

when these decisions are going to be made. For ex-

ample, one option is to make the decision as the offers

are received; another possibility is to make the deci-

sions at some points in time that has been previously

set. These points may be dynamically selected, de-

pending on changing conditions of the environment

such as the frequency of arrival of offers, or statically

determined based on temporal constraints imposed by

the trading protocol, or a combination of them both.

Therefore, the responsibilities of this organisation are

not only to determine whether a binding offer must

be accepted or submitted but to establish when these

decisions shall be made as well.

The decisions made in this organisations are based

on several factors and they may vary depending on

whether it is a service consumer who is making the

decision or it is a service provider. Nevertheless, we

can divide these factors in three groups: First, User

preferences about the contents of the agreement. For

instance, constraints about the values of the terms of

the agreement or an utility function indicating the im-

portance of these terms to the user. Second, user pref-

erences about the agreement process. Some exam-

ples are the deadline and the eagerness to reach an

agreement. Third, external factors that may prevent

a party to commit to an agreement. For instance, the

provider’s capability to accept new agreements or the

existence of dependencies amongst the agreements a

service consumer wants to reach.

This organisation is composed of three roles:

• The Commit Handler role has the ﬁnal decision on

whether to bind to an offer or not and it is also

in charge of determining when these decision are

made. To make these decisions it takes into ac-

count the user preferences about the contents of the

agreement and the agreement process and it con-

sults other roles about the feasibility of committing

to an agreement.

• The Capacity Planner role analyses the provider’s

capability to provision a certain agreement and rec-

ommends the Commit Handler to commit or not to

that agreement. This role is speciﬁc to the concrete

deployment of the service provider.

• The Demand Planner is the role that plans the

search of multiple agreements. For instance, a ser-

vice consumer may want to reach agreements on

different services, and there may exist dependen-

cies between those services. These dependencies

can be like “I want either an agreement on all dif-

ferent services or no agreement at all ”. The De-

mand Planner is in charge of enforcing these re-

strictions.

The most important decisions of the whole system

take place in this organisation because it is where it is

decided when to commit to an agreement. Therefore,

in a real-time enterprise, the roles in this organisation

are likely to be very complex and supported by addi-

tional components that manage and analyse the infor-

mation collected by companies using methods such us

data mining, forecasting or stochastic modelling.

ICE-B 2006 - INTERNATIONAL CONFERENCE ON E-BUSINESS

3 RELATED WORK

In this section, we analyse related proposals from two

points of view: First, we focus on different concep-

tual architectures or frameworks that address the in-

teroperability of web services. Second, we give an

overview of current technologies that can be used to

develop different parts of the organisations identiﬁed

in our framework.

Since web services and service-oriented comput-

ing paradigm were introduced, some architectural re-

search has been developed. The comparative analysis

carried out amongst them, focuses on automating the

service trading; particularly, in Table 1 we study, for

each of the proposals, if the organisational goals in-

dentiﬁed in our conceptual framework are addresed.

Web Service Architecture (WSA)(W3C WSAG,

2004) is the reference architecture built by W3C. Due

to the abstraction level of this conceptual architecture,

SLAs automation creation is marginaly dealt and the

only issues directly handled are discovery ones. How-

ever, in the last couple of years, an extended web ser-

vice architecture (Weerawarana et al., 2005) have ad-

dressed Information problem in terms of standards for

metadata interchange.

In the area of integration and virtual organisa-

tions, an evolved grid paradigm has emerged in

the last years: the service grid. There is a wide

range of on-going standarising work in this context.

As part of this work, a conceptual architecture has

been developed: the Open Grid Service Architecture

(OGSA)(Globus Alliance, 2005). This approach tries

to address a highly distributed scenario of collabo-

rative stakeholders. Concerning our organisational

goals, OGSA deals with all organisations that in-

volves some kind of interaction (Discovery, Informa-

tion and Agreement Making) in an explict way. Nev-

ertheless, organisations centered in decision-making

mechanisms (Selection and Binding) are not well de-

ﬁned and the needed elements have not been identi-

ﬁed. However, in OGSA there are some references to

the capacity planning issues.

The Semantic Web has inﬂuenced several research

ﬁelds; particularly, semantic approaches have boosted

several open research efforts in the web services ﬁeld.

One of the most active is the Web Service Modelling

Ontology (WSMO) that comprises a group of espec-

iﬁcations and systems for dealing with semantic web

services. In particular, there is a conceptual archi-

tecture called WSMO-Full that describes the abstract

background of WSMO. In this approach, interactions

related to the information organisation are not clearly

isolated and no further architectural element is out-

lined. However, there are some subtle references to

additional information needs after a discovery phase.

WSMO-Full(Preist, 2004) is more centered on de-

cision making than other architectures and they ex-

plicitly propose a selection after the discovery of po-

tential candidates. Nevertheless, it does not identify

the issues related to the decision-making in the bind-

ing organisation. WSMO-Full supports the creation

of agreements and deﬁnes contract agreement chore-

ographies that are protocols for message interactions

between at least one service requestor and at least one

service provider. However, unlike our trading proto-

cols they do not cover all phases of service trading but

only the creation of agreements, and they are more

focused on the messages exchanged rather than the

temporal behaviour of the system.

Following the idea of semantic web services, a

joint effort of several research groups in the area have

developed a more general and abstract conceptual

framework called Semantic Web Service Architecture

(SWSA)(Burstein et al., 2005). SWSA completely

covers discovery and agreement making. However,

information issues are not addressed in a explicit ar-

chitectural concept, although some higly related re-

quirements are deﬁned. Additionally, some match-

making mechanisms are stated as part of their dis-

covery phase. Nonetheless, this matchmaking is only

about the advertised information of the service, while

in our proposal, there is an additional selection car-

ried out by the selection organisation that chooses

amongst concrete agreement proposals instead of just

advertised information.

We have analysed how different approaches differ

based on the organisational outlining of our frame-

work. Additionally, another signiﬁcative difference

amongst frameworks is the way they integrate the be-

haviour of service consumer and service provider into

the overall architecture: on the one hand, WSMO-Full

is aligned with our approach and the elements of its

architecture are independent of the nature of the stake-

holders, i.e. whether the are service consumers or ser-

vice providers. On the other hand, SWSA strongly

links the behaviour of active roles to the service con-

sumer side while the more passive roles correspond to

the service provider.

Several standards have emerged to enrich the basic

web service stack. Table 2 shows a distribution of

stadards over the conceptual organisations identiﬁed.

Concerning the discovery organisation, there are

three speciﬁcations that can be used to implement

its requirements: (i) UDDI can be used as a ﬂexible

repository that can be used to store the access points

of elements and the taxonomies used by the discov-

ery organisation. (ii) WS-Notiﬁcation (Graham et al.,

2005) can be used to subscribe and broker notiﬁca-

tion events. (iii) Lastly, WS-Adressing (Weerawarana

et al., 2005) provides an speciﬁcation of the refer-

ences/locations of web services by means of a stan-

dardization of the concept of endpoint references.

There are a number of standards that deal

with the exchange of service descriptions, from

TOWARDS AUTOMATED SERVICE TRADING

Table 1: Comparative analysis of conceptual frameworks.

Phases Discovery Information Selection Agreement Binding Trading

Architectures Making

WSA (W3C WSAG, 2004) + ∼

OGSA (Globus Alliance, 2005) + + + ∼

WSMO-Full (Preist, 2004) + ∼ + +

SWSA (Burstein et al., 2005) + ∼ +

Ours + + + + + +

Table 2: Related standards.

Discovery Information Agreement Trading

Making

UDDI WS-MetadataExchange WS-Agreement WS-CDL

WS-Notiﬁcation WS-InspectionLanguage FIPA Protocols BPEL

WS-Addressing WS-Agreement

both a functional and a non-functional point of

view and they can be used in the implementa-

tion of the information organisation. For instance,

WS-MetadataExchange (Weerawarana et al., 2005)

and WS-InspectionLanguage. Alternatively, WS-

Agreement (Andrieux et al., 2004a) uses a template-

driven procedure, and those templates can be seen as

a mean of expressing the preferences of a given party.

The most signiﬁcant speciﬁcation that covers most

aspects included in the agreement making organisa-

tion is WS-Agreement (Andrieux et al., 2004a). It

allows to specify the structure of an agreement docu-

ment, so that it must be used together with one or sev-

eral domain-speciﬁc vocabularies to give the proper

semantic to the terms of the agreement. Furthermore,

it deﬁnes a protocol and a web service-based inter-

face to create, represent and allow the monitoring of

agreements.

However, WS-Agreement just deﬁnes a take-it-or-

leave-it protocol. To use more complex negotiation

protocols, other speciﬁcations must be implemented.

For instance, WS-AgreementNegotiation

(Andrieux

et al., 2004b), which builds on WS-Agreement and

speciﬁes a bilateral negotiation protocol, or the nego-

tiation protocols deﬁned by FIPA (FIPA, ).

Concerning the trading organisation, depending on

the complexity of the trading protocol used, different

approaches are possible. For complex coordinations,

there are workﬂow standard such as BPEL (Weer-

awarana et al., 2005) or choreography languages such

as WS-CDL(Group, 2003). In the case of simple

cases, an alternative to implement Trading Proto-

cols would be the speciﬁcation of ad-hoc elements

in the concrete architecture build upon the conceptual

framework.

Still in a very early stage of development

4 CONCLUSIONS AND FUTURE

WORK

This paper focuses on the problem of service trading.

In this context, our main aim is to achieve an effective

background for the development of automated discov-

ering, selection and negotiation of SLAs. To this end,

a conceptual framework is developed and compared

with related conceptual approaches.

The main contributions of this article are:

• A decomposition of the automated service trading

problem outlining a set of abstract roles and organi-

sations. Unlike other proposals, which are centered

in the interactions between parties, we also identify

the neccesary elements for the automated decision

making.

• The conceptual framework presented aims to deﬁne

and compare different trading architectures. Fur-

thermore, the conceptual background developed

can be used to analyse potential interoperability

amongst architectures.

• We introduce the concept of Trading Protocol as a

method for deﬁning the temporal features and be-

havioral stages of trading scenarios. These pro-

tocols drive the choreography of the different el-

ements and allow a temporal match procedure

among SLA demands/offers of stakeholders.

Additionally, it is worth pointing out that an

automation of the service trading process, shall

beneﬁt not only a cross-organisational scenario

but also an intra-organisational (integration) one:

SLAs have been associated traditionally with cross-

organisational transactions where a company must en-

force a certain level of service to their partners; how-

ever, real-time enterprises paradigm, in most cases, is

ICE-B 2006 - INTERNATIONAL CONFERENCE ON E-BUSINESS

built upon the integration of a complex organisation;

in this context SLAs are starting to be an important is-

sue to be addressed amongst the subsystems involved.

In this integration scenario, the rationalisation of the

usage of resources inside the organisation argues for

SLAs to be managed as automatically as possible. In

so doing, new promising ﬁelds such as the Service

Grid (Globus Alliance, 2005) are aligned with an hy-

brid scenario cross/intra-organisational where SLAs

are comparatively important.

Further work to be done in this ﬁeld is to develop

a reference architecture making use of the conceptual

framework presented. This architecture has been out-

lined in (Resinas et al., pear) although some reﬁne-

ment and implementation must still be developed.

REFERENCES

Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Lud-

wig, H., Pruyne, J., Rofrano, J., Tuecke, S., and Xu,

M. (2004a). WS-Agreement speciﬁcation.

Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Lud-

wig, H., Pruyne, J., Rofrano, J., Tuecke, S., and Xu,

M. (2004b). WS-AgreementNegotiation speciﬁcation,

draft.

Burstein, M., Bussler, C., Zaremba, M., Finin, T., Huhns,

M. N., Paolucci, M., Sheth, A. P., and Williams, S.

(2005). A semantic web services architecture. IEEE

Internet Computing, 9(5):72–81.

Curbera, F., Khalaf, R., Mukhi, N., Tai, S., and Weer-

awarana, S. (2003). The next step in web services.

Commun. ACM, 46(10):29–34.

Faratin, P., Sierra, C., and Jennings, N. R. (1998). Negoti-

ation decision functions for autonomous agents. Int.

Journal of Robotics and Autonomous Systems, 24(3-

4):159–182.

Faratin, P., Sierra, C., and Jennings, N. R. (2002). Using

similarity criteria to make trade-offs in automated ne-

gotiations. Artiﬁcial Intelligence, 142:205–237.

FIPA. FIPA Contract Net Interaction Protocol Spec-

iﬁcation. http://www.fipa.org/specs/

pesspecs.tar.gz.

Globus Alliance, . (2005). Open grid service architecture.

http://www.globus.org/ogsa/.

Graham, S. G., Hull, D., and Murray, B. (2005). WS-

BaseNotiﬁcation Speciﬁcation. http://docs.

oasis-open.org/wsn/wsn-ws_base_

notification-1.3-spec-pr-01.pdf.

Group, X. P. W. (2003). Soap speciﬁcation. http://

www.w3.org/TR/soap12-part0/.

Karp, A. H., Wu, R., Chen, K.-Y., and Zhang, A. (2004). A

game tree strategy for automated negotiation. In ACM

Conference On Electronic Commerce, pages 228–229.

Ludwig, H. (2003). A conceptual framework for build-

ing e-contracting infraestructure. In Corchuelo, R.,

Wrembel, R., and Ruiz-Cortes, A., editors, Technolo-

gies Supporting Business Solutions, chapter 1. Nova

Publishing.

Ludwig, H., Gimple, H., Dan, A., and Kearney,

R. D. (2005). Template-based automated service

provisioning-supporting the agreement-driven service

life-cycle. Technical Report rc23660, IBM Research

Division.

Preist, C. (2004). A conceptual architecture for semantic

web services. In McIlraith, S. A., Plexousakis, D.,

and van Harmelen, F., editors, International Seman-

tic Web Conference, volume 3298 of Lecture Notes in

Computer Science, pages 395–409. Springer.

Resinas, M., Fernandez, P., and Corchuelo, R. (2006 (to ap-

pear)). Automatic creation of agreements in a service-

oriented scenario. In Columbus, F., editor, Progress in

Computer Network Research. Nova Science Publish-

ers.

Sierra, C., Faratin, P., and Jennings, N. R. (1997).

A service-oriented negotiation model between au-

tonomous agents. In Proc. of the 8th European Work-

shop On Modelling Auton. Agents in a Multi-Agent

World, pages 17–35. Springer-Verlag.

Str

obel, M. and Weinhardt, C. (2003). Montreal taxonomy

for electronic negotiation, the. Group Decision and

Negotiation, 12(2):143–164.

W3C W SAG, . (2004). Web services architecture. http:

//www.w3.org/TR/ws-arch/.

Weerawarana, S., Curbera, F., Leymann, F., Storey, T., and

F.Ferguson, D. (2005). Web Services Platform Archi-

tecture. Prentice Hall.

Zambonelli, F., Jennings, N. R., and Wooldridge, M.

(2003). Developing multiagent systems: The gaia

methodology. ACM Trans. Softw. Eng. Methodol.,

12(3):317–370.

Zeng, D. and Sycara, K. (1998). Bayesian learning in nego-

tiation. Int. J. Hum.-Comput. Stud., 48(1):125–141.

TOWARDS AUTOMATED SERVICE TRADING