Service level agreement (SLA) is a formal contract between a service provider and a service consumer, used to guarantee the achievement of Quality of Service (QoS) expectations. An IoT application is made up of several layers in which several devices are used, the main challenges can be summarized into two points: (1) how to describe the SLA terms, such as QoS properties, service levels, penalties in SLA violation, and (2) how to integrate an SLA into all the application layers. For that, SLAs must be specified more expressively and encompass concepts and constraints related to the multi-layered nature of IoT applications and user preference-aware. However, almost all existing SLA specifications are unable to cover all these requirements. We believe that an SLA can be represented in a domain-specific language (DSL) to facilitate the expression of SLA terms, automate the negotiation, and adapt the provided services according to these terms. Therefore, in this paper, we propose a DSL called ML-SLA-IoT, which is a multi-level SLA specification language with customisable, parametrised and dynamic management, intended for IoT applications. ML-SLA-IoT is more advantageous than others languages in terms of specification of user preferences, the use of microservices and the ML-SLA concepts.
Services are marketed under formal contracts known as Service Level Agreements (SLA) which
is a formal contract between a service provider and a service consumer. It formally specifies
the provided services, the obligations of each party and the applicable penalties in the case of
non-compliance with the contract [
User expectations must be provided with guaranteed QoS levels, in which requirements are
formally specified in SLA. Guaranteeing QoS is a dificult task to achieve [
There are three types of SLAs [
Mostly, SLAs were written using natural language and the agreement compliance verification
used to be done manually. Some solutions have been proposed to facilitate this process using
SLA models, nevertheless, those solutions lead to new problems in specifying diferent service
levels for diferent customers [
The most optimal way to specify an SLA is to use a Domain-Specific Language (DSL), it
is generally a small programming language dedicated to a specific application domain. It is
designed to provide solutions to the problems raised in a particular field and is, therefore,
dificult to reuse in other fields. This is why this type of programming language difers from
General-Purpose Language (GPL) such as Java, C and C++, whose purpose is to ofer solutions
to any problem, which may not be the most optimal way, then, the DSL concepts and notations
must be close to the objects handled in the treated field [
IoT applications become more complex since several services have to be provided
simultaneously with high expected QoS. Indeed, the eficient management of these services is an
important issue, hence, one of the solutions is to use a microservices-based approach.
Microservices [
Existing SLA specification languages for IoT applications have limitations such as (a) eficient application management through consideration of the multi-layered nature of IoT, (b) clear and expressive specification of terms and obligations, and (c) consideration of user preferences. However, an SLA specification language for IoT applications must: (1) be domain-specific to handle all IoT constraints (such as the multiplicity of the provided services, the variety of the used devices, and the management of preferences), (2) allow a low coupled architecture to facilitate reusability, scalability, and integration, to ensure the QoS across all layers of the application, and (3) be user preference-aware. Therefore, this paper aims to propose ML-SLA-IoT, a DSL for SLA specification, intended for IoT applications. It difers from other SLA specification languages in the description of user preferences, microservices, and ML-SLA concepts. ML-SLA-IoT allows to: • Overcome the problems of traditional SLAs in terms of fixed QoS and pricing. • Facilitate the SLA management, and select the best service ofer from the end user’s point of view. • Identify the diferent resources used in the IoT application. • Clarify the ofered services by fragmenting each of them into a set of microservices for ease of integration, scalability, extensibility, and low coupled architecture.
• Define the obligations of each party and the associated sanctions.
We propose the creation of ML-SLA-IoT, and not to extend one of the existing languages because of: (1) the existing SLA specification languages for IoT are dificult to use because of their complex syntax (e.g. IoT-SLA is specified in JSON, and WSN-SLA is specified in XML), (2) the existing languages do not allow to cover all the essential aspects of a contract for an IoT application (e.g. the consideration of the multi-layered nature of IoT applications), and (3) existing languages are intended for other areas, such as cloud computing, and reorienting the domain of a language causes loss of eficiency and expressiveness. This is why we propose ML-SLA-IoT, which is easy to understand and use, because its syntax is close to human language, and it is practical for IoT application management (because of the use of diferent concepts such as ML-SLA and microservices). In terms of real world applications, ML-SLA-IoT can be used for the eficient QoS management of the services provided as part of an IoT application, and especially in the phases: (1) contract term negotiation (ML-SLA-IoT provides a high level of clarity and expressiveness), and (2) verification of contract compliance (by monitoring the parameters specified in the SLA).
The remainder of this paper is structured as follows: Section 2 discusses some related work. In Section 3, the proposed SLA specification language is described. Section 4 illustrates the proposed language through a case study. Section 5 presents a comparative study using relevant criteria. In Section 6, the paper is concluded and future work are presented.
Initially, SLAs were written in natural language. However, from the 2000s, the field saw the creation of SLA specification languages, and this language creation mechanism has slowed down in recent years. In this section, we will present the most used languages. Each area of computer science has its own SLA specification languages, in this section, we will review the best-known languages in each area.
Regarding Cloud Computing, CSLA [
SLAC [
In the field of web services, WSLA [
WS-Agreement [
For IT services, SLA* [
SLALOM [
For IoT, WSN-SLA [
SLA-IoT [
In what follows, we will present ML-SLA-IoT according to the DSL development lifecycle, the ifrst subsection will summarize the first three steps of the lifecycle(decision, analysis and design), and the second subsection will present the last three steps (implementation, evaluation and deployment).
The language meta-model has already been presented in [
We used the concept of ML-SLA as a solution to:
• Cover all layers of an IoT application (sensing, network, service and interface [
To implement our language, we used Xtext, which is a free framework developed in Eclipse; Xtext facilitates the implementation of textual DSLs, it works on a JVM (Java Virtual Machine), and it is made up of several APIs that describe the diferent aspects and ofer a full implementation of this language. We use Xtext because it covers all aspects of a complete language infrastructure, starting from the parser, code generator, or interpreter, up to a complete Eclipse IDE integration (with all the typical IDE features). Besides, Xtext generates a grammar description, a parser and an abstract syntax tree. It also ofers an initial grammar that can be extended to define the final one. The initial grammar ofers important elements such as space management, carriage return, tabulation, strings, integers, etc.
Xtext allows to generate the initial grammar from the meta-model, then, we enrich the grammar by adding the desired rules. Listing 1 shows a part of the ML-SLA-IoT Xtext file, and the Listing 2 shows the rule concerning the specification of a device.
Listing 2: The device specification rule Now, after defining the grammar, we create the Plug-in using Eclipse, which allows us to write an SLA in the proposed language. The proposed SLA is machine-readable to automate monitoring whether the parties hold the agreements and guarantees. On the other hand, it is human-readable to facilitate configuration and maintenance tasks.
This section illustrates how to create an SLA for an IoT application, using ML-SLA-IoT. We developed a Java application with a useful GUI that facilitate the SLA establishment by enabling, on the one hand, users to enter information related to their preferences in the application form, and on the other hand, the provider to choose options related to the microservices that can be provided in the application. Indeed, it allows the generation of SLA terms according to our proposed microservice and ML-SLA concepts.
As shown in figure 4, the interface contains five tabs: the tab (a) "General information" is used to specify the SLA name, the start and end dates, and the involved parties, the tab (b) "Resources" lists the resources used in the IoT application and their metrics, the tab (c) "Services" indicates the microservices that must be provided, the tab (d) "Preferences" shows user preferences which are resource and metric preferences, and the tab (e) "Obligations" allows to express SLOs and rules.
To show the usability and eficiency of ML-SLA-IoT, we have used a reduced example of Smart Home, in which the consumer wants a service for the control of the ambient temperature, the consumer wants to have three air conditioners, and that the temperature is below 23 °C in summer, and a short response time. This SLA is made up of a single service which is the ambient temperature control. This service comprises two microservices: the air conditioner adjustment and temperature monitoring. The resources used are temperature sensors and air conditioners. The metrics associated with these devices is temperature and response time. The SLA has two SLOs and a Rule, the first SLO concerns ambient temperature, and the second concerns device response time.
The SLA will be automatically generated after filling in all the fields of the tabs and confirming, as shown in Listing 3, and the elements listed below are the key points of the language: • Line 26 to 30: ML-SLA-IoT focuses on the consumer by specifying his preferences to precisely target the desired goals; • Line 12 to 15: the use of microservices allows eficient management due to weak coupling according to two points: the first one is flexibility in the case of dynamic requirement changes, and the second one is the resource optimization; • Line 36: rules allow the combination of SLOs to facilitate the management of obligations; • Line 22 and 23: the use of multi-level metrics to dispense with problems of fixed pricing 1 2 3 4 5 6 7 8 9 10
and QoS level change.
SLA " SLA_for_Smart_Home " S t a r t _ d a t e " 0 3 / 0 3 / 2 0 2 1 " End_date " 0 3 / 0 3 / 2 0 2 2 " P a r t i e s {
Customer { " William_Smith " } ,
Provider { " Bosch_Smart_Home " } } S e r v i c e s {
S e r v i c e [ " A m b i e n t _ t e m p e r a t u r e _ c o n t r o l " , l i s t _ o f _ m i c r o s e r v i c e s { Temperature_monitoring , A i r _ c o n d i t i o n e r _ a d j u s t m e n t } ] }
Micro_Services { 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35
Current SLA specification languages have limitations, such as the expression of user preferences, ifxed pricing despite QoS degradation, poor service specification, and tightly coupled service architecture that afects management, scalability, and service provision. For that, we proposed ML-SLA-IoT, which is an SLA language specification intended for IoT, it allows to: identify the involved parties, express the consumer preferences, identify the diferent resources used in the system, clarify the ofered services by fragmenting each of them into a set of microservices, use ML-SLA in the partition of metrics in several levels to optimise the management and the provision of services, define the obligations of each party and the associated sanctions. Figure 5 presents a comparison diagram between ML-SLA-IoT (our proposed language) and some languages close to our contribution, this diagram includes two levels: • Unsupported criterion: (the white zone) means that the language does not support the • Supported criterion: means that the solution supports the criterion, it includes two criterion. sub-levels:
covered. – Low: (the light gray zone) this evaluation indicates that the criterion is partially – High: (the dark gray zone) this evaluation indicates that the criterion is completely covered.
We discussed and examined the languages based on the following criteria: • Multi-level: indicates if the language takes into account the notion of ML-SLA. • QoS parameters: show if the solution specifies the QoS parameters or not. • Microservice: expresses whether the notion of microservices is considered. • Penalties expression: indicates whether the language expresses penalties. If it is the case, it covers all the SLA life cycle, otherwise, it does not cover it. • User preferences: indicates whether the language takes into account user preferences. • Used devices: indicates if the language defines the diferent devices used in the service provision. As shown in figure 5, no language allows to specify the user preferences, use the microservice approach to specify services, and support the ML-SLA concept. Only ML-SLA-IoT and WSN-SLA allow specifying the used devices.
This paper has presented ML-SLA-IoT, an SLA specification language for IoT applications, it is a clear, simple, expressive and well-described language, it is user preference-aware allowing to ensure that the provided QoS meets the agreed consumer expectations, it plays a central role in selecting the best service ofer from the end user’s point of view, and it covers customer’s requirements to facilitate the SLA management. ML-SLA-IoT is composed of six parts: The ifrst one is responsible for identifying the involved parties in the SLA, such as the consumer and the provider. The second one is dedicated to the specification of user preferences, it allows a consumer to determine its preferences in terms of resources and metrics. The third one is for specifying the provided services, where each service is divided into a set of microservices for ease of integration, reusability, scalability, extensibility and low coupled architecture. The fourth one is for the identification of the resources used in the IoT application. The fifth one is for the specification of the set of metrics relating to resources, for the parameterised QoS level management, we used ML-SLA to solve problems related to the static nature of traditional SLA approaches in terms of QoS and pricing. Finally, the sixth one is to specify the obligations of each party, these obligations are of two types: guarantees and penalties, a guarantee can be an SLO or a Rule that represents a composition of SLOs.
As long as services evolve, their SLAs become more complicated, even if some points have already been explored. As a result, challenges remain in SLA management in terms of scalability, dynamic environmental changes, heterogeneity, etc. Regarding our future work, we intend to integrate a monitoring module that uses ML-SLA-IoT language to provide and monitor the QoS as eficient and customized as possible in smart healthcare systems.
This work was partially supported by the LABEX-TA project MeFoGL:"Méhodes Formelles pour le Génie Logiciel".