Based on preceding work as described in Section 5.1 and the preliminary work described in Section 5.2 this section presents the final steps towards the specification of a multi-round negotiation protocol for WS-Agreement. The integration with Agreement is realised following a loosely coupled layered design exploiting WS-Agreement’s template mechanism.
While providing a first standard draft for a generic
ne-Figure 5.3.1: Struc-ture of a SmartLM license agreement template [131]
gotiation protocol the design allows to easily exchange this protocol with other, probably domain-specific pro-tocols supporting, e.g, auction-like negotiations, or se-mantically enriched negotiations.
In ”Extending WS-AGREEMENT with multi-round ne-gotiation capability” [131] the state of OGF’s work on the draft of the WS-Agreement Negotiation specification is presented along with a detailed discussion of the first implementation of the draft in the context of the Euro-pean project SmartLM [145] [29]. For the implementa-tion of WS-Agreement and WS-Agreement-Negotiaimplementa-tion, the SmartLM component SLA and Negotiation Service uses the Agreement Framework for Java [163]. WS-Agreement for Java (WSAG4J) implements both the ba-sic features of the Agreement protocol and the WS-Agreement Negotiation. The SLA and Negotiation Ser-vice implements the WSAG4J engine and exposes an agreement factory that pro-vides an agreement template after the user requested a template (see Figure 5.3.1).
5.3. Progress towards WS-Agreement Negotiation 41
This template contains the XML schema of a license agreement including creation constraints. To retrieve the template, to negotiate the template and to create agree-ments, this agreement factory provides the following WSAG4J server actions:
GetLicenseTemplateAction implementing GetTemplateAction to retrieve a li-cense template,
NegotiateLicenseTemplateAction implementing NegotiateAction to negotiate the variables of a license template according to the creation constraints,
CreateLicenseAgreementActionimplementing CreateAgreementAction to final-ly create the agreement based on the initial template satisfying all creation con-straints.
The user completes theLicense Description of the template with application name, and probably version and features of an application. TheNegotiation Goal can be used to retrieve all features of an application with the corresponding maximum val-ues. The corresponding negotiation goal is “FEATURES”. The default negotiation goal is “TIMESLOT” which tells the server that the user wants to receive a free time-slot for his selected features and values. The resulting negotiation quote is sent to theSLA and Negotiation Service which in turn replies with a template filled with a valid license description and a free time-slot. This can be employed by the user to initiate the agreement creation or to continue negotiation with a modified template.
Paper I ”A proposal for WS-Agreement Negotiation” [11] presents almost final details of WS-Agreement Negotiation to the scientific community. In this paper, the authors describe the Web Services Agreement Negotiation protocol, a proposal by the GRAAP-WG to extend the existing WS-Agreement specification: ”This proposal is the result of combining various research activities that have been conducted to define protocols for negotiating service levels or to supersede the existing ”take-it-or-leave-it” protocol. The main characteristics of this proposal are the multi-round negotiation capability, re-negotiation capability, and compliance with the original specification” [11] .
As described in Paper I WS-Agreement Negotiation offers three different nego-tiation models.
1. The basic Client–Server model, which is realised through asymmetric deploy-ment of the WS-Agreedeploy-ment Negotiation Port Types.
2. The bilateral negotiation model, which is realised trough a symmetric deploy-ment of WS-Agreedeploy-ment Negotiation, where the Negotiation Initiator is also the Agreement Initiator and the Negotiation Responder is the Agreement Re-sponder. Both parties thus have an active role in the negotiation process.
3. The model for the re-negotiation of agreements. This is realised through sym-metric signalling on the Negotiation and Agreement Layer. Both parties imple-ment the WS-Agreeimple-ment Negotiation and WS-Agreeimple-ment port types. More-over, both parties have their own instance of the original agreement. After the negotiation process, the responder of the original agreement creates the re-negotiated agreement.
The specification of WS-Agreement Negotiation was based on [11] with minor corrections and changes. Version 1.0 of the specification was published in 2011 as
42 5. Electronic Negotiation of Service Level Agreements
proposed recommendation [158]. It has been implemented and used in a number of Grid and Cloud projects described in Chapter 6.
Consumer Agreement Initiator
Negotiation Initiator Negotiation Responder
Agreement Responder
Provider
Factory Negotiation
Operations:
Negotiate(input) Advertise(input) Terminate(reason)
Service Instance Factory
Factory
Agreement
Negotiation Layer
Agreement Layer
Service Layer Operations:
GetResourceProperty() Terminate(reason) create()
negotiate()
create()
foo() inspect()
Figure 5.3.2: WS-Agreement Negotiation layered approach [158]
As discussed earlier, one important characteristic of the negotiation protocol is compatibility with WS-Agreement. Figure 5.3.2 shows the approach taken. Com-patibility is achieved by adding a separate layer for the negotiation. The outcome of a negotiation (based on a negotiation template that is basically an agreement template plus negotiation constraints) is a valid agreement template that is then processed in the usual way in the agreement layer. It should be noted that success-ful negotiations do not imply that an SLA shall be created automatically. Rather, the outcome is an agreement offer that is binding for the negotiation initiator. The creation of the SLA, i.e. the commitment of the agreement responder is left to the discretion of the agreement responder as defined in the protocol of the agreement layer.
Figure 5.3.3 depicts the state machine
Figure 5.3.3: WS-Agreement Negotiation state machine [158]
for the negotiation protocol. Messages exchanged during the negotiation are offers and counteroffers where each par-ty may adapt the negotiation constr-aints for each offer or counteroffer. Al-so, each party may decide to start ne-gotiation based on a new offer . Either party may decide that continuation of the negotiation is no longer expected to converge to an acceptable result and may enter the rejected state, which terminates the negotiation.
A Java reference implementation of WS-Agreement Negotiation is part of the WSAG4J framework that is available on sourceforge [163].
6. Service Level Agreements in Distributed Computing
This chapter present projects we have participated in and contributed to that have been used WS-Agreement and WS-Agreement Negotiation for the creation of SLAs in Grid and Cloud computing environments.
Machine-processable SLAs in the context of distributed computing infrastruc-tures have been a topic of research and development work since around the year 2000.
Most of the initial work was targeting Grid infrastructures managed by web-service-based Grid middleware. Some of this work with own contributions is presented in Section 6.1. Some other work is mentioned briefly. Section 6.2 does the same for Cloud computing. Most of the research and development work has been part of pub-licly funded projects. The report ”Cloud Computing Service Level Agreements” [79]
provides a comprehensive overview up to the year 2013. Since then, only a few new projects have emerged which have been briefly described in Section 4.3. However, working group 3 of ISO/IEC SC 38 on Cloud Computing and Distributed Platforms started addressing the standardisation of SLA terms in 2014 [71]. In Sections 6.1 and 6.2 we briefly present several Grid and Cloud projects projects to which we contributed SLA and resource management developments.