1. Gestione di Service Level Agreements (SLA) in sistemi Grid
Dip. di Ingegneria Informatica e delle Telecomunicazioni
Università di Catania
Orazio Tomarchio

2. Agenda Towards Service Oriented GRIDs Service Level Agreements concept
The WS-Agreement specification
The proposal: dynamically modifiable SLAs
Conclusion
Grid Open Days al LNS - Catania 23 gennaio 2008

3. Convergence between Grid and SOA
Software engineering evolution
GRID evolution
More computational power
for e-science applications
through modularisation
Handling complexity
High Performance
Computing
Object
orientation
Cluster
Computing
Component based
architectures
Networked Computing
(GRID)
Business
requirements
SOA
Service Oriented
Architectures
Service Oriented GRID:
Computing and storage
available on the Internet
Common challenges

4. Fully Networked Business Interactions
Many potential providers
can be found for each
required function.
The distinction between
internal and external
applications and providers
looses importance

5. IT for the New Enterprise
Today it is vital to adapt the computing model to the business interaction model
Need to encapsulate business function to make it available to partners: service components.
Services must be defined by explicit contracts to allow independent party access.
Consequence is automatic binding.
Core concern of business is to integrate business processes and functions.
Business components are integrated creating service compositions.
New value is created through integration/composition.

6. Service Level Agreements
SLA
Service Customer
Service Provider
Service Level Agreement (SLA): Formal negotiated agreement between a Service Provider and a Service Customer
The contract involves parameters relating to the service to be provided, both functional and non functional (QoS)
QoS to be achieved is expressed through the Service Level Objectives (SLOs)

7. SLA in GRID environments
GRID resources:
CPUs
Storage
In GRID environments “services” take the form of resource leasing
GRID VO are the service (or resource) providers
QoS to be guaranteed in SLAs is to be expressed in terms of computational power and storage capability

8. The WS-Agreement specification
Developed by the GRAAP working group (Grid Resource Allocation Agreement Protocol) of the Open Grid Forum (OGF)
It has been recently published (May 2007) as an OGF Proposed Recommendation
The objective of WS-Agreement is to define a language (XML based) for establishing and monitoring Agreements between two parties
Main features
One-shot interaction
It allows the use of custom languages for the description of domain– specific resources
No support for negotiations

9. One-shot interaction
Agreement Initiator (on behalf of the Service Customer)
Agreement Responder (on behalf of the Service Provider)
Negotiation Phase
Agreement Offer
Accept/Reject
Monitoring Phase
Terminate

10. WS-Agreement’s limitation
Once agreed by the parties, the Service Level Objectives can not be modified during the service provision
Sometimes the parties are not able to honor the Agreement, due to:
Resource management issues for Service Providers
Dissatisfaction of the perceived QoS for Service Customers
Agreement’s violation:
Penalties for the violator
Waste of resources, time and money
The WS-Agreement protocol is not flexible:
No room for any re-negotiation of the terms
No means to modify the terms

11. WS-Agreement in composite services scenarios
Service Provider
SP4
Ag41
Ag1c
Ag21
Service Provider
SP1
Consumer c
Ag32
Service Provider
SP2
These limitations are particularly pressing in composite services scenarios, where multiple one-to-one Agreements are established among parties.
For instance, let us assume that C has stipulated an Agreement with SP1 for a given service. And SP1 to provide that service has to rely on some other services (SP2, SP3, SP4,…). If for some reason SP2 is not able to maintain the agreed QoS level, the Agreement is terminated and the service stopped.
These means that also the Agreement 1c between C and SP1 cannot be maintained anymore and it is terminated too.
The Agr. Ag32 and ag41 should not be terminated, but they willproduce a waste of money for sp2 and sp1 respectively, since they are paying for a service that they arenot consuming anymore.
Service Provider
SP3
Grid Open Days al LNS - Catania 23 gennaio 2008

12. Our Work
Objective: Giving the parties the possibility to modify the terms of the Agreement while the service is being provided
A new scenario:
Step 1: The parties negotiate the modification of the terms of the earlier signed Agreement
Step 2: The Agreement is formally modified
Our proposal provides means to support just the formal modification of the Agreement (Step 2). Step 1 is out of the scope of this presentation
We are currently working on the integration of a support for the terms’ (re)negotiation

13. What has been done Integrations to the XML schema of the Agreement
The schema now takes into account for the possibilities of agreeing on SLOs that are modifiable at run-time
An Agreement document conforming to the old XML schema is conformant to the new schema too!
Enhancement of the protocol
New Port Types and Operations have been added to support a new level of interaction between the parties

14. An additional level of interaction
Agreement Initiator (on behalf of the Service Customer)
Agreement Responder (on behalf of the Service Provider)
Negotiation Phase
ModifiableAgreement Offer
Accept/Reject
Re-Negotiation Phase
AgreementModification Offer
Accept/Reject

15. Simple two way interaction
SLOModification Acceptance
Agreement Handler
Agreement
Factory
Agreement Initiator
Agreement Responder
CreateModifiableAgreement
The AR accepts the Agreement offer and creates the new Agreement
Result
Ongoing re-negotiation of the QoS levels
ModifySLO
The AR receives the modification proposal and evaluates it
Result
The AR decides to accept the modification proposal and modifies the Agreement’s terms
Accept
Result

16. A service composition scenario
Ag1c
Ag21
Service Provider
SP1
Consumer c
Ag32
Service Provider
SP2
Service Provider
SP3

17. Three way interaction Service Provider SP3 Consumer
SP1 needs to modify the terms
of its Agreements
In order to accept the modification proposal, on its turn, SP2 has to modify the
Agreement it has with SP3
CondModifySLO
CondModifySLO
CondModifySLO
C agrees to the modification proposal
CondAccept
SP3 agrees to the modification proposal
SP2 agrees to the modification proposal
CondAccept
CondAccept
The modified Agreement becomes effective
Confirm
Confirm
Confirm

18. Ongoing and future Work
Implementation work has been carried out
Based on the CREMONA framework (IBM)
Protocol validation and refinement
Tested the correctness and effectiveness on a B2C scenario
Better understanding of service requirements for the runtime QoS adjustment without the need of service suspension
Introducing the support for automatic negotiation:
Negotiation of resources before the agreement takes place
Re-negotiation of the resources at run-time

19. Thank you for your attention!
Questions?