Manuel Resinas, Pablo Fernandez, Rafael Corchuelo
ETS Ingenieria Informatica
University of Seville
Service Oriented Computing, SLAs, Trading.
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 define 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 define, 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 define the elements that are necessary to
support an automated decision-making in service trading.
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 fulfilled 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.,
We define 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 defined 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
ery, information, selection, agreement making, bind-
ing, and trading), and each one cares for a specific
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).
In Proceedings of the International Conference on e-Business, pages 38-45
DOI: 10.5220/0001428000380045
to develop a conceptual framework that can be used
to define, 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 specification of the global behaviour of
the trading system from a temporal point of view.
And third, we define 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 briefly 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.
Several phases have been identified on the contracting
process (Ludwig, 2003) (as it is shown in the left part
of Figure 1): The first step that appears in the figure 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, first
step is defined 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 find
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 fulfilment phase. This
phase involves the fulfilment 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 fullfilment
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
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-
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, fi-
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
definition of the temporal parameters that will control
the behaviour of other organisational. These parame-
ters would be passed to the actors of those organisa-
This organisation is composed of the following
The Trading Protocol Selector role analyses user
preferences to decide which of the known trading
protocols best suits to the temporal contraints es-
pecified 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 specified 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 refined. This
information might also be useful for some negotia-
tion strategies.
A protocol to exchange and propagate events
amongst organisations.
An addressing specification 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
refined in further concrete models. Different infras-
tructures can be selected from a wide range of mod-
els: from a centralized paradigm to a distributed
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.
The Advertiser role is the complementary role for
Tracker generating trading events to be searched.
This trading events, should be parametrized with
the most significative 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-
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 specification 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-
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
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 filter. Optionally, it can kept them until an
event occurs. For instance, they can be kept until
the negotiation phase finishes.
The Proponent role represents the party that is sub-
mitting us a proposal.
The Proposal filter role is in charge of filtering the
agreement proposals collected by the Proposal col-
lector and the non-successful offers coming from
the binding organisation. The filter 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 specifies 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
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
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 definition
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 identified 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-
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 final 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 specific 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-
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.
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 identified
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-
dentified 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-
fined and the needed elements have not been identi-
fied. However, in OGSA there are some references to
the capacity planning issues.
The Semantic Web has influenced several research
fields; particularly, semantic approaches have boosted
several open research efforts in the web services field.
One of the most active is the Web Service Modelling
Ontology (WSMO) that comprises a group of espec-
ifications 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 defines 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 defined. 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 significative 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 identified.
Concerning the discovery organisation, there are
three specifications that can be used to implement
its requirements: (i) UDDI can be used as a flexible
repository that can be used to store the access points
of elements and the taxonomies used by the discov-
ery organisation. (ii) WS-Notification (Graham et al.,
2005) can be used to subscribe and broker notifica-
tion events. (iii) Lastly, WS-Adressing (Weerawarana
et al., 2005) provides an specification 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
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
UDDI WS-MetadataExchange WS-Agreement WS-CDL
WS-Notification 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 significant specification 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-specific vocabularies to give the proper
semantic to the terms of the agreement. Furthermore,
it defines a protocol and a web service-based inter-
face to create, represent and allow the monitoring of
However, WS-Agreement just defines a take-it-or-
leave-it protocol. To use more complex negotiation
protocols, other specifications must be implemented.
For instance, WS-AgreementNegotiation
et al., 2004b), which builds on WS-Agreement and
specifies a bilateral negotiation protocol, or the nego-
tiation protocols defined 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 workflow 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 specification of ad-hoc elements
in the concrete architecture build upon the conceptual
Still in a very early stage of development
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
The conceptual framework presented aims to define
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 defining 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
benefit 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
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 fields 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 field 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 refine-
ment and implementation must still be developed.
Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Lud-
wig, H., Pruyne, J., Rofrano, J., Tuecke, S., and Xu,
M. (2004a). WS-Agreement specification.
Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Lud-
wig, H., Pruyne, J., Rofrano, J., Tuecke, S., and Xu,
M. (2004b). WS-AgreementNegotiation specification,
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-
Faratin, P., Sierra, C., and Jennings, N. R. (2002). Using
similarity criteria to make trade-offs in automated ne-
gotiations. Artificial Intelligence, 142:205–237.
FIPA. FIPA Contract Net Interaction Protocol Spec-
Globus Alliance, . (2005). Open grid service architecture.
Graham, S. G., Hull, D., and Murray, B. (2005). WS-
BaseNotification Specification. http://docs.
Group, X. P. W. (2003). Soap specification. http://
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
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
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-
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.
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:
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.,
Zeng, D. and Sycara, K. (1998). Bayesian learning in nego-
tiation. Int. J. Hum.-Comput. Stud., 48(1):125–141.