The terms section of an iAgree document describes both the characteristics of the services to be provided and the guarantees on such services by involved parties. in iAgree, the service terms are divided into pricing, metrics and guarantees.
Pricing section defines the properties to properly process the service billing such as currency, accounting period or cost. The cost depends on the service and can be measured by time units (e.g. 3e/hour) and/or other metrics (e.g. number of executed
3.2. WS-AGREEMENT AND IAGREE
instances). Commonly, compensations are described with a percentage discount or fee over the billing, as consequence of under- or over-fulfillment of SLOs. Therefore, the percentage property is named in the pricing but the compensation definition is related to the SLO in the corresponding Guarantee.
Metrics use iAgree schemas to describe the data types of the service properties that are monitorable or computed (e.g. availability of a computation unit). A metric defini- tion can include an endpoint to get the execution values. The values can be monitored in a specific time window (monthly, hourly, ...) and this window can be static (e.g.: natural weeks from Monday to Sunday) or dynamic (the previous 7 days from a given moment). The monitoring mechanism is not defined in the model, just the service end- point that provides the metric. These metrics can be used to define guarantees, which are detailed in next subsection. In our example, we include the metric Monthly Uptime Percentage (MUP), which measures the availability of the computing units in Amazon EC2 for a given user. It is measured by natural months according to the computing regions defined by Amazon Web Services2.
terms : p r i c i n g : b i l l i n g : period : monthly i n i t i a l : ’2017−11−12T10 : 3 5 : 3 6 . 0 0 0 Z ’ p e n a l t i e s : − over : S e r v i c e C r e d i t : $ r e f : ’#/ c o n t e x t / d e f i n i t i o n s /schemas / . . . ’ g u a r a n t e e s : . . .
Figure 3.4: Terms section using iAgree syntax
In the example in Figure §3.4, we describe the pricing term and the metrics for Amazon service. In this case, the billing is monthly required and the compensation is defined with a variable ServiceCredit over it. The only metric in this service is the MUP.
Guarantee Terms
The guarantee terms (GTs) describe the SLOs that an obligated party, usually the service provider, must fulfill as part of the agreement. The SLO of a guarantee term is defined with an assertion over a monitorable variables which were described in Met- rics section and over external parameters such as date, time, etc.
Each guarantee term can be parameterized with additional properties to specify the scope where it is applied such guarantee. In the Amazon computing service, they define an SLA with a single SLO. However, they organize their global computation service by regions and the billing and the context to apply the guarantee is limited to each single region (Amazon currently defines more than 15 computing regions). That is, if the objective of 99.95% is not accomplished in a region, the penalty is applied
for the billing of that same region. We can parameterize the guarantee using the re- gion as scope. Then, the guarantee is evaluated for each region value (e.g.: Canada, US East, ...). In practice, adding a scope variable with N possible values to a guaran- tee, it is as defining N guarantees (e.g.: G1.1 : MUP ≥99.5 AND region = Canada, G1.2 : MUP≥99.5 AND region = USEast, etc). We have described in the Figure §3.5 the SLA from Amazon EC2, with the clause offered by Amazon to penalize itself by a service unavailability. In the clause, the customer is able to claim for a reward of a Service Credit when MUP objective is not achieved. However, information such as the claiming procedure or the fact that Amazon requires that the customer proves this violation, is not supported by iAgree formalisation. In order to prove the violation the customer has to monitor and compute the MUP by subtracting from 100% the unavail- able period. It is not the case of Amazon, but the SLOs can be defined different for each value of the scope variables (e.g. to define a different goal and compensation for each specific region). id : Amazon_EC2 . . . terms : . . . g u a r a n t e e s : − id : Amazon_GT scope : r e g i o n : * o f : − o b j e c t i v e : MUP >= 9 9 . 9 5 scope : r e g i o n : * with : MUP: { } window : type : s t a t i c period : monthly i n i t i a l : ’2016−07−13T00 : 0 0 : 0 0 . 0 0 0 Z ’ p e n a l t i e s : − over : S e r v i c e C r e d i t : $ r e f : ’#/ c o n t e x t / d e f i n i t i o n s /schemas / . . . ’ o f : − value : ’ 1 0 ’
c o n d i t i o n : MUP >= 9 9 . 0 0 && MUP < 9 9 . 9 5
− value : ’ 3 0 ’
c o n d i t i o n : MUP < 9 9 . 0 0
Figure 3.5: Guarantees using iAgree syntax
Regarding the penalties, Rana et al. in [151] provide an approach to (1) identify classes of penalty clauses that can be associated with an SLA; (2) define how to spec- ify penalties in an extension of WS-Agreement; and (3) specify to what extent penalty clauses can be enforced based on monitoring of an SLA. An extended analysis of com- pensations have been described during the current work and it is included in the Ap- pendix §A.
As summary, a compensation function is usually defined as a function from the metric M guaranteed in the SLO toR that associates a compensation to each of the val-
3.2. WS-AGREEMENT AND IAGREE
ues of M. The compensation function is usually proportional to the utility of the met- ric values (i.e.: Poor availability can be penalized, high availability can be rewarded). As in the SLA, both service parties, customer and provider, can commit to different SLOs, the responsible of the compensation can be either the service provider or the service customer. Therefore, the compensations have two roles, namely guarantor and beneficiary of a guarantee, and they are usually provider and customer but it can be the opposite. For example, in a cloud scenario, the availability guarantor is the cloud provider and the beneficiary is the customer.
WS-Agreement also proposes to add other service properties as Terms to describe the service as it is, not to negotiate about them and their performance. An example of these properties, namely Service Description Terms, would be origin and destination cities in the Transport Service example.
In order to simplify, the Agreement definition in iAgree, all the terms are manda- tory. However, the terms in a WS-Agreement document can be grouped using three different terms compositors denoting that the comprised terms are either mandatory, optional, or alternative, as it is depicted in Figure §3.1.
• All terms compositor: every comprised term or compositor is mandatory. In other words, all of them must be fulfilled. WS-Agreement specification imposes that at the top level of the terms section, all terms must be inside a mandatory terms compositor. For the sake of simplicity we consider as implicit such a top level mandatory terms compositor.
• OneOrMore optional terms compositor: every comprised term or compositor is optional. In other words, a set of them, but at least one, must be fulfilled.
• ExactlyOne exclusive terms compositor: comprised term or compositor are ex- clusive. In other words, only one of them must be fulfilled.
Term compositors can be nested, therefore enabling the specification of alternative branches with potentially complex nesting within the agreement terms. Choices ex- pressed using compositors can be exercised by the party that makes the next step in the agreement creation process, i.e., by the agreement initiator if it is creating an offer from a template, by the agreement responder if it is creating an agreement from an offer, or by the service provider if it is delivering the service according to a previously created agreement.
Note that parties can exercise the choice but it is not mandatory to do so. In other words, the term compositors can remain in an offer and even in a final agreement, exactly as they were defined in the former template.
Furthermore, in WS-Agreement, the guarantees can be categorised using also asser- tions, namely qualifying condition (QC), or a set of service operations, which express the conditions under which the guarantee holds. WS-Agreement also considers that
CHAPTER 3. SLA MANAGEMENT-UDL Service Terms WS-Agreement Context Service Description Terms Guarantee Terms Service Properties Creation Constraints QC-SubL SLO-SubL
SP-SubL BVL-SubL CC-SubL
Service Reference
mandatory optional
Context
-SubL SDT-SubL SR-SubL
requires
Figure 3.6: WS-Agreement and sublanguages
SLOs can be related to externally defined key performance indicators (KPIs), i.e. exter- nally defined monitorable variables and to a list of business values (BVL) to describe the relative importance between the terms, penalties, etc.