to ensure a high quality as well as technical, finan-
cial and juridical reliability (Braun et al., 2008). Such
contracts usually contain clauses about minimum or
maximum average values of technical characteristics,
tolerance ranges, usage constraints and other restric-
tions. In addition, they may contain compensation
rules. Finally, any contract will have a set of metadata
such as the unambiguous identification of the partici-
pating partners – or parties, in legalese –, the duration
of validity, associated tariff models and disclaimers.
Without the metadata, the contract would just be an
agreement without legal relevance. Often, the term
SLA is used to refer to purely technical contracting
approaches and Quality of Service (QoS) guarantees.
On the other hand, formal service interface defini-
tions as described by the Web Service Description
Language (WSDL) or the older Interface Description
Language (IDL) are also named contracts in the con-
text of software engineering. Our understanding of
contracts requires the mutual acceptance of an SLA
by at least two involved parties.
Several declarative languages for expressing agree-
ments and contracts have been created over the last
decade. Among them, WS-Agreement, WSLA and
SLA-ng have been subject to a considerable amount
of analysis, critique and proposed improvements
(Tian et al., 2004; Frankova et al., 2006; Truong et al.,
2008). A number of service execution platforms have
been specifically developed or extended to exploit the
contents of such contracts and act accordingly in de-
cisive situations where the contracts conflict with the
state of the platform. Depending on the nature of
the situation, either the contracts can be modified by
renegotiating or cancelling them, the service execu-
tion can be modified by terminating, reconfiguring,
rebinding or otherwise adapting services, and the plat-
form can be modified by acquiring more resources,
migrating workload to other servers or equivalent ac-
tions which help solve the conflict. These technical,
corrective actions belong into the functionality of all
adaptive platforms for contract-bound service execu-
tion. The term Service-Level Management (SLM) en-
compasses adaptivity but especially includes changes
of a contract within its lifecycle as well as admission
control functionality to reduce the need for adaptivity.
An approach to SLM is proposed by (Wang et al.,
2007) and refers to technical QoS management and
admission control using a custom QoS specification
language. Some of its goals like end-to-end QoS guar-
antees are feasible in closed environments but unsuit-
able for Internet-scale service delivery. Furthermore,
no contract lifecycle guidance for users is offered by
the system. In (Ludwig and Franczyk, 2006), current
SLA languages are compared and evaluated for suit-
ability for automated contract management in service
grids. The authors conclude that several ambiguities
are present in all of them which makes automated ap-
proaches hard or impossible for more complex condi-
tions. When elastic infrastructures are used beneath a
user-oriented participative Internet of Services (pIoS),
user guidance through contract services becomes even
more important.
While the autonomous handling of contracts is suf-
ficiently covered by existing approaches, additional
SLM aspects are needed for conveying the conflicts
and decisions to the user in an intuitive and compre-
hensible way. No previous concepts are known at this
point which could fill this gap. Hence, we introduce
dedicated, reusable contract services as a novel con-
cept. Furthermore, we propose Contract Wizard as
an intuitive user interface to contract services in the
context of pIoS.
3 CONTRACT SERVICES
Given that the processes of creating, storing, man-
aging and terminating contracts encompass multiple
steps, we propose a set of individual contract services
which are loosely coupled so they can be used both
as standalone platform services and as a composite
service which manages all of the contractual aspects.
The research is focused on initial, user-driven ne-
gotiation of SLA parameters (technical perspective),
tariff selection and auctioning (business perspective),
contract monitoring and status visualisation, interac-
tive feedback collection and the adherence to contract
law (legal perspective) in any of these steps. We do
not consider contract services aimed at providers who
place service offerings at marketplaces in this paper,
although it can be assumed that the basic functional-
ity would be comparable. Figure 1 shows the overall
picture.
3.1 Initial SLA Negotiation
The scope of the initial negotiation is the user-driven
transformation of a service description or an SLA
template into an SLA. A set of templates is attached to
a service description within the service registry, from
which the user may choose one to initiate the negotia-
tion process. If no templates are present, an uncon-
strained negotiation can be initiated. The resulting
SLA will be linked to the user to form the base for
a valid contract between two parties. The term ini-
tial serves to differentiate this step from autonomous
renegotiations which may happen once the SLAs have
become binding. It is assumed that only NFPs are
ACT4SOC-EHST 2009 - 4th International Conference on Software and Data Technologies
370