SLA@SOI

Our project is about managing Service Level Agreements, so in this post it is a good opportunity to discuss them in general and see some aspects of their management.

A Service Level Agreement (SLA) is a representation of all those features that a user should expect to receive by a service. By features here we refer not only to the functionality delivered by the service, but also to the quality that the user experiences. As a matter of fact, SLAs are typically associated with Quality of Service (QoS), but in a formal representation it is reasonably expected to find the service description as well.

Given the definition above, SLAs may be represented in various ways; SLA@SOI considers only their electronic representation for purposes of automated management by means of machine-readable documents. In a direct analogy with contracts as known from traditional business, we commonly refer to SLAs in our context as electronic contracts. As a consequence of this analogy, the following important questions come up:

1. What are the legal implications of electronic contracts, when it is software that is making the decisions?
2. What is the language that an electronic contract is written?
3. How is electronic contract negotiation happening?
4. How can the terms of the contract be expressed in uniform, commonly understood ways?

With regard to legal implications, it is clear that machines and software cannot be held accountable in the case of penalties, or more severe breach of contract. Therefore, it is commonly accepted that a formal (non-electronic) contract negotiated between humans needs to be in place, governing all automated interactions between software entities. This contract will have to define what are the purposes of the automated SLAs, the capabilities and administrative boundaries of the negotiating software entities, acceptable terms and penalties, and in general all those business and technical characteristics that apply to the automated interactions. Therefore, a framework contract must be in place to reflect accountability and responsibilities of involved business parties.

This contract will probably have to also define the language in which SLAs are negotiated and established. Just like typical business contracts which may be written in English, German, French or any other language, electronic contracts have to be expressed unambiguously in a commonly agreed machine-readable language. A few efforts on this front have taken place in the past, such as WSLA [1] and SLAng [2], but the only standardised such language which is also actively maintained, is WS-Agreement [3]. WS-Agreement is developed by the Open Grid Forum’s [4] GRAAP Working Group [5]. It defines the necessary building blocks for establishing a contract, currently in the form of a single-round negotiation without counter-offers: One party makes an offer, and the other party simply accepts or rejects it.

Although currently not a part of the standardised protocol, multi-round negotiation is in the works and will be made available soon in an amendment of the standard. This extension is a simple series of agreement template exchanges, each template defining candidate terms to be agreed and the acceptable ranges for these terms. When both involved parties agree on a template, then an offer is made by one of the two parties. Renegotiation is still not addressed but will probably take the same form.

Having defined in complete a signalling protocol for the establishment of SLAs, the question of proper definitions for terms comes up. WS-Agreement does not go into this area, which is domain-specific and cannot be addressed uniformly except for specific common definitions for terms such as cost/price, re-negotiation policies, etc. Therefore, domain-specific languages have to be agreed and implemented by WS-Agreement users, or existing languages can be reused. For instance, infrastructure provisioning requests may be addressed by embedding OVF [6] requests in WS-Agreement offers; for Grid storage reservations, SRM [7] can be used as a term language; for job submission, JSDL [8] is a typical candidate. WS-Agreement’s extensible characteristics allow the inclusion of any language deemed appropriate.

The above points address SLAs as documents/contracts. In next posts of the SLA@SOI blog, we will address in more detail the business-logic side of establishing agreements, such as offer optimisation, service provisioning, agreement persistency, monitoring, violation management, etc.

[1] http://www.research.ibm.com/wsla/
[2] http://doi.ieeecomputersociety.org/10.1109/FTDCS.2003.1204317
[3] http://www.ogf.org/documents/GFD.107.pdf
[4] http://www.ogf.org/
[5] https://forge.gridforum.org/projects/graap-wg
[6] http://en.wikipedia.org/wiki/Open_Virtualization_Format
[7] http://en.wikipedia.org/wiki/Storage_Resource_Manager
[8] http://www.gridforum.org/documents/GFD.56.pdf

Tags: contract, management, sla

This entry was posted on Tuesday, March 17th, 2009 at 16:15 and is filed under Articles, Latest News. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.