2.2 SLA support in OWL-Q

Introduction

This is an innovation item which focuses on the extension of the OWL-Q semantic non-functional service description language towards the specification of SLAs. This extension has been carefully designed in order to make a complete coverage of the SLA domain allowing the capturing
of information which provides sufficient support for all the service management lifecycle activities. Some interesting features of the OWL-Q SLA extension are the following:

(a) modelling of SLAs and SLA templates;

(b) modelling of Service Levels (SLs) and supporting the dynamic and on-demand transitioning between SLs;

(c) modelling of SLOs, including the definition of qualifying conditions, penalties and rewards;

(d) specification of service price models;

(e) modelling of critical conditions leading to respective settlement actions, like service re-negotiation or cancelling;

(f) capability to specify hierarchical SLAs (covering the delivery of BPaaS and the lower-level cloud services required to support its execution).

 

Research Problem

Due to the heterogeneity, both structural and semantic, in QoS term description which is inherent in the service and cloud world, there is a need for introducing a semantic language which is able to cover the non-functional service description. As such, the use of such language will enable reaching better accuracy levels in service discovery and composition. Apart from non-functional service profiles and requests, this language should be able to specify SLAs in the way that extends the current state-of-the-art. This means that it should be complete enough in order to cover all information required for supporting the management of all service lifecycle activities.
The required language should be able to also specify KPIs as well as link them to goals in order to support BPaaS evaluation as well as goal analysis enabling broker to inspect whether their strategic, tactical and operational goals are satisfied. The current set of languages employed for this purposes suffer from the following drawbacks: (a) they are not rich or complete enough to cover the respective domain; (b) they are mapped to a quite technical level which is not suitable for business experts; (c) they are not able to exploit different information sources, even external to the respective BPaaS (management) system; (d) in some cases, they are not linked to goals.

Solution Approach

OWL-Q is a language which has been considered one of the most prominent non-functional service specification languages by survey papers in service quality description. This is due to its expressivity, richness and completeness (in terms of domain coverage) as well as to the fact that it relies on semantics and ontologies in particular. OWL-Q extends the W3C OWL standard and has been designed into several facets, each one focusing on different measurability aspects, including attribute, metric, unit (of measurement), and value type. It is also assorted by: (a) semantic rules specified in the SWRL language (W3C Submission) which enable the validation of OWL-Q models as well as the derivation of new knowledge that can take even the form of matches between quality terms. An overview of OWL-Q can be seen in the following two figures, where the first figure covers the 5 facets and the second the last one.
 
OWL-Q has been recently extended in order to also specify SLAs as well as cover the previously referred research gap in SLA description. In a nutshell, the OWL-Q SLA extension, named as Q-SLA, has the following capabilities: (a) it can specify both SLA and SLA templates; (b) it captures directly the notion of a Service Level (SL) to be delivered by a service which maps to a logical combination of Service Level Objectives (SLOs). The latter are simple constraints over quality terms; (c) it enables the transitioning from one SL to another in order to allow for flexibility in SLA management. In particular, such a SL transitioning can be beneficial for a signatory party as it enables the on-demand modification of the SL to be delivered without the need of performing a critical action, such as SLA re-negotiation. Such a modification might be required when specific party requirements are modified, e.g., due to increase in workload due to an increase of the party clientelle; (d) it associates an SLO to various important concepts, like qualifying conditions, dictating when the SLO should hold, as well as penalties and rewards to be supplied when the respective SLO is violated or surpassed, respectively; (e) it is able to specify service price models and connect then to the SLO penalties and rewards; (f) it enables the hierarchical specification of SLAs which is highly needed in the case of BPaaS services, which are cross-level agglomeration of cloud services; (g) finally it allows the definition of critical situations for settlement along with the respective actions that need to take place, such as SLA re-negotiation or cancelling. As Q-SLA builds on top of the OWL-Q specification facet, an overview of this extension is depicted in the following figure which uses different colours to characterise concepts which are original or new with respect to the OWL-Q language.
 
By again focusing on the respective research gap identified previously, another OWL-Q extension was developed in order to cover the modelling of KPIs and goals as well as their linkage. This extension is depicted in the following figure where different colours (red vs. other) are being used to denote extension or original OWL-Q concepts. In summary, the following features characterise this OWL-Q extension: (a) it specifies KPIs as extensions to simple constraints which are enhanced with the description of additional thresholds (warning apart from violation ones); (b) it enables issuing queries over databases or calling APIs and using the respective result as an input argument to a KPI metric formula; (c) it enables specifying direct relationships between KPIs (child-parent) in order to enable KPI drill-down to discover the root causes of a high-level KPI violation; (d) it covers the modelling of manual measurements as humans are usually another source of information apart from the automatic ones; (e) it allows the modelling of KPI evaluations which can assist in the checking of respective trends in BPaaS performance; (f) it covers the specification of goal hierarchies as well as the linking of goals to KPIs via goal contributions.
 
Both OWL-Q as well as its extensions are supported by a JAVA programmatic API which enables the parsing as well as the serialisation of OWL-Q models. This API can be used to construct non-functional service matchmaking and selection algorithms as well as customised OWL-Q editors. For the time being, the latter type of editor does not yet exist but is planned to be developed. In case the interested reader and possible adopter of OWL-Q desires to manually edit an OWL-Q model, then he/she can use well-known ontology editors, like Protege, for now.

 

Information

CloudSocket Webinar BPaaS semantics with OWL-Q
CF2016_Semantic+SLAs+for+Services+with+Q-SLA_FORTH.pdf
CloudSocket_D3.3_BPaaS-Allocation-Execution-Environment-Blueprints-v1.0_20160630-FINAL.pdf
CloudSocket_D3.4_BPaaS-Allocation-Execution-Environment-Prototypes-v1.0_FINAL.pdf
CloudSocket_D3.5_BPaaS-Monitoring-Evaluation-Blueprints-v1.0_20161223.pdf
OWLQ Parser Wiki
Q-SLA
CloudSocket Webinar

Extend

https://omi-gitlab.e-technik.uni-ulm.de/cloudsocket/owlq_parser

Additional Information

Originator: Kyriakos Kritikos (FORTH)
Technology Readiness Level: 5
Related CloudSocket Environment: Allocation