=Paper=
{{Paper
|id=Vol-3067/paper5
|storemode=property
|title=Multi-Level SLA Specification Language for IoT Applications
|pdfUrl=https://ceur-ws.org/Vol-3067/paper5.pdf
|volume=Vol-3067
|authors=Noureddine Staifia,Meriem Belguidoum
|dblpUrl=https://dblp.org/rec/conf/tacc/StaifiB21
}}
==Multi-Level SLA Specification Language for IoT Applications ==
https://ceur-ws.org/Vol-3067/paper5.pdf
Multi-Level SLA Specification Language for IoT
Applications
Noureddine Staifi1 , Meriem Belguidoum1
1
LIRE Laboratory, University of Constantine 2, Algeria
Abstract
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.
Keywords
Service Level Agreement, Quality of Service, SLA specification, Domain-specific language, Internet of
Things, Multi-level SLA, User preference-aware, Microservices.
1. Introduction
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 [1]. The SLA aims to meet customer’s Quality of Service
(QoS) expectations and allows each party to respect its commitment, and in the case of conflict,
it improves the understanding aspect between the involved parties. The consumer uses SLA as
a legal description of what a provider has promised to provide. In turn, the provider uses it as a
record of what to be delivered [2].
User expectations must be provided with guaranteed QoS levels, in which requirements are
formally specified in SLA. Guaranteeing QoS is a difficult task to achieve [3], e.g. IoT application
systems are generally made up of several layers involving multiple heterogeneous hardware and
software resources, multiple data types from digital and wearable sensors and multi QoS levels
Tunisian Algerian Conference on Applied Computing (TACC 2021), December 18–20, 2021, Tabarka, Tunisia
$ noureddine.staifi@univ-constantine2.dz (N. Staifi); meriem.belguidoum@univ-constantine2.dz (M. Belguidoum)
0000-0001-9965-9785 (N. Staifi); 0000-0002-2936-6810 (M. Belguidoum)
© 2021 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073 CEUR Workshop Proceedings (CEUR-WS.org)
from the lowest to the highest one. Providing QoS guarantees requires the technical ability to
ensure that their QoS requirements are met on each IoT application system layer.
There are three types of SLAs [4], firstly, Customer-based SLA is an agreement that puts all
the customer’s requirements and expectations into a single document, this means that all the
provided services will be described and contained in one SLA. Secondly, Service-based SLA is
an agreement in which the provider lists services in a service catalogue, each service has its
own fixed SLA parameters, which do not take into account user preferences. Finally, multi-level
SLA (ML-SLA) is an agreement that is classified into different stages, it is customized according
to the end-user requirements, it allows the user to integrate several conditions into the same
system to create a more suitable service. ML-SLA is a solution to solve the problems related
to: (1) the integration of contracts into the entire multilayer architecture, and (2) the flexibility
limitation resulting from the static nature of traditional SLA approaches in terms of QoS and
pricing.
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 different service
levels for different customers [5]. To resolve these problems, it is necessary to automate the
process in which different SLAs are described, provided and observed flexibly. To simplify the
contractual process for the involved parties and optimise time and costs, researchers from the
service provider community have developed several SLA specification languages [5]. These
languages are important for clarifying expectations and quantifying them in measurable terms.
Indeed, specifying expectations provides guarantees to customers and helps them to focus on
what is the most important.
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,
difficult to reuse in other fields. This is why this type of programming language differs from
General-Purpose Language (GPL) such as Java, C and C++, whose purpose is to offer 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 [6]. DSLs are created through a process
that includes the following steps: decision, analysis, design, implementation, evaluation, and
deployment. The decision and analysis determine the need for a DSL as well as the domain model.
The design that results from the formalisation of the DSL abstract syntax is then presented. The
implementation includes the integration of DSL artefacts into the infrastructure. The evaluation
phase is used to validate the DSL, followed by the deployment phase used to deliver the DSL [7].
IoT applications become more complex since several services have to be provided simul-
taneously with high expected QoS. Indeed, the efficient management of these services is an
important issue, hence, one of the solutions is to use a microservices-based approach. Microser-
vices [8] refer to both an architecture and a software development approach which consists
in dividing applications into simplest and independent elements. Unlike a classic monolithic
approach, where all components form an inseparable entity, microservices aim to divide the
business behaviour into small services, which can be run independently of each other. It offers
reusability, scalability, extensibility, ease of integration, low coupled architecture, flexibility,
continuous deployment, complexity management and ease of QoS management.
Existing SLA specification languages for IoT applications have limitations such as (a) efficient
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 differs 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 offer from the end user’s point
of view.
• Identify the different resources used in the IoT application.
• Clarify the offered 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 difficult 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 efficiency 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 different concepts
such as ML-SLA and microservices). In terms of real world applications, ML-SLA-IoT can be
used for the efficient 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.
2. Related work
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 [9] is proposed to address problems raised by current
SLA solutions that are unable to offer an SLA language capable of managing the Cloud dynamic
nature, multiple QoS settings, WAN access and fluctuation in end users. A contract in CSLA is
made up of parties and obligations. However, CSLA does not consider multi-party contracts, it
does not use ML-SLA and does not specify the devices used to provide services.
SLAC [10] is designed to specify SLAs for Cloud Computing. The main differences from the
existing specification languages are that SLAC is domain-specific, its semantics are formally
defined to avoid ambiguity, and it supports leading Cloud deployment models, and allows the
specification of multiparty agreements. An SLA in SLAC consists of: the contract description,
the specification of the contract conditions and the guarantee definitions for these conditions.
Nevertheless, SLAC does not use ML-SLA and does not specify the devices and user preferences.
In the field of web services, WSLA [11] is a framework for defining and monitoring SLAs for
web services. It provides a formal language, an XML schema, and a runtime architecture that
interprets the language and manages SLA tasks. It describes the expected service levels about
business and technical objectives. The same service can be offered at different levels. An SLA in
WSLA describes all the contracted aspects between the signatory parties concerning a specific
service, and it consists of parties, service description and obligations. Even though, WSLA is
difficult to use because of its complex grammar, it does not consider multi-party contracts, and
it does not specify the devices and user preferences.
WS-Agreement [12] is an SLA specification language for Web services. It is an XML-based
Web service language and protocol to generate a proposed offer agreement that the agreement
initiator wants to establish, negotiate this agreement according to specific constraints, create
an agreement between the service provider and the customer with all the conditions and
restrictions, and then observe the final compliance. An SLA in WS-Agreement is made up of
context, service terms and guarantee terms. Nevertheless, WS-Agreement does not specify the
QoS parameters, devices and user preferences, and does not consider multi-party contracts.
For IT services, SLA* [13] is an SLA specification language, it is a domain-independent syntax.
SLA* was developed as a refinement of XML standards specific to Web services: WS-Agreement
and WSLA. Now, instead of Web services, SLA* is domain-independent, and instead of XML,
it is language independent. In SLA*, a contract consists of the SLA template attributes, the
agreement parties, the service descriptions, the declarations of variables, and the agreement
terms. Nonetheless, SLA* does not consider multi-party contracts, and it is not easy to use.
SLALOM [14] is a domain-specific language to reduce the gap between the customer’s point
of view (business-oriented) and that of the provider (business-oriented towards implementation).
SLALOM facilitates SLA specification and monitoring. The authors note that the evaluation
of the isolated components does not measure QoS, they, therefore, use SLALOM to support
the composition of the measurements from various data sources to present and justify the
measurements of these compositions. An SLA in SLALOM is made up of parties and a set
of clauses, each addressing an IT service. However, SLALOM does not consider multi-party
contracts, and it does not specify the devices and user preferences.
For IoT, WSN-SLA [15] is a model for specifying SLA. The authors extend the WSLA model by
integrating elements that meet the constraints of sensor networks. Before the SLA negotiation,
the customer must provide the number, position and characteristics list of each device. This
device specification describes the sensor subsets with different QoS requirements. An SLA
consists of parties, devices, service definitions and obligations. Nevertheless, WSN-SLA does
not use ML-SLA and does not specify the QoS parameters and user preferences.
SLA-IoT [3] is an end-to-end SLA specification language for IoT, it is a new conceptual model
that captures the knowledge base of IoT-specific SLAs, expressing IoT system entities and their
relationships in the SLA context. It proposes a new multilayer grammar to specify SLA for IoT
applications. It is a tool for final and standardized SLA specification and composition with a full
vocabulary, which provides a finer specification level of the user’s needs. A contract is made up
of parties, SLOs, workflow activities, services and infrastructure resources. However, SLA-IoT
does not specify the penalties, devices and user preferences.
3. ML-SLA-IoT: an SLA specification language for IoT systems
In what follows, we will present ML-SLA-IoT according to the DSL development lifecycle, the
first 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).
3.1. ML-SLA-IoT meta-model
The language meta-model has already been presented in [16], in this paper we will present
an extended version of the meta-model. In this extension, the third-party has been eliminated
and its role has been replaced by the implementation of a monitoring module (outside the
scope of this paper). The elimination of the third-party benefits both parties; for the service
provider, eliminating the third-party reduces costs and minimises the unnecessary allocation of
resources; for the service consumer, the elimination helps ensure data trust and save time due
to the automation of parameters control and monitoring. As shown in Figure 1, ML-SLA-IoT is
composed of six parts: The first one is responsible for identifying the involved parties in the
SLA, ML-SLA-IoT dispenses with the third-party who is responsible for monitoring the SLA
terms. The second one is for the identification of the resources used in the IoT application. The
third one dedicated to the specification of user preferences, it allows a consumer to determine
its preferences in terms of resources and metrics. The fourth one is for the specification of the
set of metrics relating to resources. The fifth 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. Finally, the sixth one of the language 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 (for example, the
automatic lighting service is made up of two microservices: the first for lamp management, and
the second for automation and control).
Figure 1: ML-SLA-IoT meta-model
We used the concept of ML-SLA as a solution to:
• Cover all layers of an IoT application (sensing, network, service and interface [17]). As
shown in figure 2, metric levels concern the sensing layer, resource specification applies
to the network layer, microservices are used for the service layer, user preferences and
obligations concern the interface layer.
• Manage the flexibility resulting from the static nature of traditional SLA approaches in
terms of QoS and pricing. As shown in figure 3, each QoS metric is divided into three
levels where each level has its price.
Figure 2: ML-SLA covering all IoT layers
Figure 3: ML-SLA for multiple QoS and pricing
3.2. ML-SLA-IoT implementation
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 different aspects and offer 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 offers an initial grammar that can be extended to define the final
one. The initial grammar offers 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.
1 s l a r e t u r n s SLA :
2 ’ SLA ’ Name = E S t r i n g
3 ’ S t a r t _ d a t e ’ S t a r t = EString
4 ’ E n d _ d a t e ’ End = E S t r i n g
5 ’ Parties { ’
6 p a r t y += P a r t y ( ’ , ’ p a r t y += P a r t y ) ∗
7 ’} ’
8 ’ Consumer_preferences { ’
9 p r e f e r e n c e += P r e f e r e n c e ( ’ , ’ p r e f e r e n c e += P r e f e r e n c e ) ∗
10 ’} ’
11 ’ Services { ’
12 s e r v i c e += s e r v i c e ( ’ , ’ s e r v i c e += s e r v i c e ) ∗
13 ’} ’
14 ’ Micro_Services { ’
15 M i c r o _ s e r v i c e += M i c r o _ s e r v i c e ( ’ , ’ M i c r o _ s e r v i c e += M i c r o _ s e r v i c e ) ∗
16 ’} ’
17 ’ Obligations { ’
18 o b l i g a t i o n += O b l i g a t i o n ( ’ , ’ o b l i g a t i o n += O b l i g a t i o n ) ∗
19 ’} ’
20 ’ Resources { ’
21 r e s o u r c e += R e s o u r c e ( ’ , ’ r e s o u r c e += R e s o u r c e ) ∗
22 ’} ’
23 ’ Metrics { ’
24 m e t r i c s += M e t r i c ( ’ , ’ m e t r i c s += M e t r i c ) ∗
25 ’} ’
26 ’ end ’
27 ;
Listing 1: A part of the Xtext file
1 Device :
2 ’ D e v i c e { ’ name= E S t r i n g ’ , L o c a l i s a t i o n : ’ l o n g i t u d e = E F l o a t ’ , ’ latitude =
EFloat ’ , ’ h e i g h t = EFloat ’ } ’ ;
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.
4. ML-SLA-IoT tool for IoT application
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 efficiency 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;
Figure 4: ML-SLA-IoT graphical interface
• Line 12 to 15: the use of microservices allows efficient 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
and QoS level change.
1 SLA " SLA_for_Smart_Home "
2 Start_date " 03/03/2021 "
3 End_date " 0 3 / 0 3 / 2 0 2 2 "
4 Parties {
5 Customer { " W i l l i a m _ S m i t h " } ,
6 Provider { " Bosch_Smart_Home " }
7 }
8
9 Services {
10 Service [ " Ambient_temperature_control " , list_of_microservices {
Temperature_monitoring , Air_conditioner_adjustment } ]
11 }
12 Micro_Services {
13 micro_service ( " Temperature_monitoring " , id1 , l i s t _ o f _ r e s o u r c e s [
Temperature_sensor ] )
14 micro_service ( " A i r _ c o n d i t i o n e r _ a d j u s t m e n t " , id1 , l i s t _ o f _ r e s o u r c e s [
Air_conditioner ])
15 }
16
17 Resources {
18 Device [ " T e m p e r a t u r e _ s e n s o r " , l o c a l i s a t i o n ( 1 6 . 2 , 2 3 . 3 , 1 4 . 0 ) ]
19 , Device [ " A i r _ c o n d i t i o n e r " , l o c a l i s a t i o n ( 4 . 2 , 6 . 3 , 1 . 0 ) ]
20 }
21 Metrics {
22 metric [ " T e m p e r a t u r e " , l e v e l " High " ] ,
23 metric [ " R e s p o n s e _ t i m e " , l e v e l " Medium " ]
24 }
25
26 Consumer_preferences {
27 m e t r i c _ p r e f e r e n c e [ T e m p e r a t u r e in A i r _ c o n d i t i o n e r < 2 3 ]
28 , m e t r i c _ p r e f e r e n c e [ R e s p o n s e _ t i m e in A i r _ c o n d i t i o n e r < 3 ]
29 , resource_preference [ A i r _ c o n d i t i o n e r = 3]
30 }
31
32 Obligations {
33 Sanction [ 1 , " N o t i f i c a t i o n " ] , Sanction [ 2 , " Compensation " ] ,
34 SLO [ i d : " SLO1 " R e s p o n s e _ t i m e > 3 f o r _ p e r i o d [ " 0 3 / 0 3 / 2 0 2 0 " t o " 0 3 / 0 3 / 2 0 2 1 " ]
s a n c t i o n = Compensation ] ,
35 SLO [ i d : " SLO2 " T e m p e r a t u r e < 23 f o r _ p e r i o d [ " 0 3 / 0 3 / 2 0 2 0 " t o " 0 3 / 0 3 / 2 0 2 1 " ]
sanction = N o t i f i c a t i o n ] ,
36 Rule [ SLO1 And SLO2 s a n c t i o n = Compensation ]
37 }
38
39 end
Listing 3: SLA for a Smart home specified in ML-SLA-IoT
5. Discussion
Current SLA specification languages have limitations, such as the expression of user preferences,
fixed pricing despite QoS degradation, poor service specification, and tightly coupled service
architecture that affects 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 different resources used in the
system, clarify the offered 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
criterion.
• Supported criterion: means that the solution supports the criterion, it includes two
sub-levels:
– Low: (the light gray zone) this evaluation indicates that the criterion is partially
covered.
– 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 different devices used in the service
provision.
Figure 5: Comparison of SLA specification languages
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.
6. Conclusion and future work
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 offer 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
first 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 efficient and customized as possible in smart healthcare systems.
Acknowledgments
This work was partially supported by the LABEX-TA project MeFoGL:"Méhodes Formelles pour
le Génie Logiciel".
References
[1] I. U. Haq, A. A. Huqqani, E. Schikuta, Hierarchical aggregation of service level agreements,
Data & knowledge engineering 70 (2011) 435–447.
[2] L. Wu, R. Buyya, Service level agreement (SLA) in utility computing systems, in: Per-
formance and dependability in service computing: Concepts, techniques and research
directions, IGI Global, 2012, pp. 1–25.
[3] A. Alqahtani, E. Solaiman, R. Buyya, R. Ranjan, End-to-end QoS specification and monitor-
ing in the internet of things, IEEE Technical Committee on Cybernetics for Cyber-Physical
Systems (2016).
[4] P. Grubitzsch, I. Braun, H. Fichtl, T. Springer, T. Hara, A. Schill, ML-SLA: Multi-level service
level agreements for highly flexible IoT services, in: 2017 IEEE International Congress on
Internet of Things (ICIOT), IEEE, 2017, pp. 113–120.
[5] A. Keller, H. Ludwig, The WSLA framework: specifying and monitoring service level
agreements for web services, Journal of Network and Systems Management 11 (2003)
57–81.
[6] G. Karsai, H. Krahn, C. Pinkernell, B. Rumpe, M. Schindler, S. Völkel, Design guidelines
for domain specific languages, in: Proceedings of the 9th OOPSLA Workshop on Domain-
Specific Modeling, Helsinki: Helsinki School of Economics, 2009, pp. 7–13.
[7] A. Barišić, V. Amaral, M. Goulão, Usability driven DSL development with USE-ME,
Computer Languages, Systems & Structures 51 (2018) 118–157.
[8] H. Vural, M. Koyuncu, S. Guney, A systematic literature review on microservices, in:
International Conference on Computational Science and Its Applications, Springer, 2017,
pp. 203–217.
[9] Y. Kouki, Service Level Agreement-Driven Approach to Cloud Elasticity Management,
Ph.D. thesis, Nantes, Ecole des Mines, 2013.
[10] R. B. Uriarte, F. Tiezzi, R. D. Nicola, SLAC: A formal service-level-agreement language for
cloud computing, in: Proceedings of the 2014 IEEE/ACM 7th International Conference on
Utility and Cloud Computing, IEEE Computer Society, 2014, pp. 419–426.
[11] H. Ludwig, A. Keller, A. Dan, R. P. King, R. Franck, Web service level agreement (WSLA)
language specification, Ibm corporation (2003) 815–824.
[12] A. Andrieux, K. Czajkowski, A. Dan, K. Keahey, H. Ludwig, T. Nakata, J. Pruyne, J. Rofrano,
S. Tuecke, M. Xu, Web services agreement specification (WS-Agreement), in: Open grid
forum (2007), volume 128, 2007, p. 216.
[13] K. T. Kearney, F. Torelli, C. Kotsokalis, SLA*: An abstract syntax for Service Level Agree-
ments, in: 2010 11th IEEE/ACM International Conference on Grid Computing, IEEE, 2010,
pp. 217–224.
[14] A. Correia, V. Amaral, et al., SLALOM: a Language for SLA Specification and Monitoring,
arXiv preprint arXiv:1109.6740 (2011).
[15] G. Gaillard, D. Barthel, F. Theoleyre, F. Valois, SLA Specification for IoT Operation -
The WSN-SLA Framework, Technical Report 8567, INRIA, 2014. URL: http://icube-publis.
unistra.fr/7-GBTV14, 71 pages.
[16] N. Staifi, M. Belguidoum, Adapted smart home services based on smart contracts and
service level agreements, Concurrency and Computation: Practice and Experience (2021)
e6208.
[17] L. Da Xu, W. He, S. Li, Internet of things in industries: A survey, IEEE Transactions on
industrial informatics 10 (2014) 2233–2243.