PAEAN4CLOUD

A Framework for Monitoring and Managing the SLA Violation of Cloud

Service-based Applications

Yehia Taher

, Raﬁqul Haque

, Dinh Khoa Nguyen

and Beatrice Finance

Laboratoire PRiSM, Universit

e de Versailles/Saint-Quentin-en-Yvelines, Versailles, France

Laboratoire d’InfoRmatique en Image et Syst

emes d’information, Universit

e Claude Bernard Lyon 1, Lyon, France

European Research Institute in Service Science, Tilburg University, Tilburg, The Netherlands

Keywords:

Business Transaction, Cloud Computing, Blueprint.

Abstract:

Recently, Cloud Computing has become an emerging research topic in response to the shift from product

oriented economy to service-oriented economy and the move from focusing on software/system development

to addressing business-IT alignment. Technically speaking, Cloud Computing enables to build Cloud Service-

Based Application (CSBA) which cater for the tailoring of services to speciﬁc business needs using a mixture

of SaaS, PaaS and IaaS solutions - possibly from various providers. In other words, in the context of CSBAs,

cloud services are rented by clients from providers instead of owning the services. Due ti this speciﬁc nature,

SLA (Service Level Agreement) has become a very important and up-to-date issues in CSBAs. Therefore

SLA turns to be critical for both cloud service clients and providers and needs constant monitoring for various

reasons mostly detecting if any violation happens but also preventing the violation in efﬁcient way. As in

CSBAs a number of providers are involved, it is a challenge to detect and resist violations of multiple SLAs

that engage different providers form different locations. To deal with such a problem, this paper introduces

a framework called PAEAN4CLOUD. The framework comprises components for monitoring, detecting, and

conﬁguring SLAs. An algorithm is proposed for automatic detection of SLA violations. The conﬁguration

component underpins assembling CSBAs automatically at runtime. The components help in preventing SLA

violations and optimizing application performance as well.

1 INTRODUCTION

Until today, the cloud computing paradigm has given

the rise to a wide variety of services that are grouped

and called Everything as a Service (XaaS). It pro-

motes opportunities to transform an object into a ser-

vice and deliver it to users over the Internet. It enables

building cloud Service-based application (CSBA) that

relies on cloud services such as SaaS, PaaS, IaaS for

designing, implementing, deploying, executing, mon-

itoring, managing applications. CSBAs are highly

customizable and allows building applications by lo-

calizing the services for satisfying the very speciﬁc

needs of a context e.g. organization or individual. CS-

BAs pose various challenges. The major challenge is

detecting and managing different types of violations

of service level agreement (SLA). SLA is a predom-

inant entity in CSBAs. In CSBAs, clients rent ser-

vices from providers instead of buying services. This

means that a CSBA is composition of list of rented

service. Thus, SLA becomes critical to both ser-

vice clients and providers and it needs to be moni-

tored constantly while a CSBA is running to detect

violation and prevent the violation. As in CSBAs a

number of providers are involved, detecting and re-

sisting violations (of multiple SLAs that engage dif-

ferent providers form different locations) are enor-

mously challenging. Therefore, an efﬁcient and effec-

tive approach is paramount importance for CSBAs.

Monitoring and managing SLAs for service based

applications (SBAs) have documented in various bod-

ies of literatures, nonetheless, the solutions proposed

in literature are not the best ﬁt to CSBAs since the de-

velopment landscape of these applications are differ-

ent. This implies that the existing approaches cannot

be reused in cloud environment. In addition, the state

of the art lacks an efﬁcient approach for detecting and

resisting SLA violations in cloud-based environment.

The goal of this research is to address this

shortcoming. To this end, a framework called

361

Taher Y., Haque R., Nguyen D. and Finance B..

PAEAN4CLOUD - A Framework for Monitoring and Managing the SLA Violation of Cloud Service-based Applications.

DOI: 10.5220/0004949403610371

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 361-371

ISBN: 978-989-758-019-2

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

PAEAN4CLOUD is proposed in this paper. The

framework comprises a list of components for mon-

itoring, detecting, and conﬁguring CSBAs. An al-

gorithm is proposed in this paper for automatic de-

tection of SLA violations. The conﬁguration com-

ponent enables assembling CSBAs automatically at

runtime. It assists in preventing SLA violations and

optimizing application performance as well. The re-

mainder of this paper is organized as follows. Section

2 presents a motivating scenario. Section 3 describes

the conﬁguration and deployment of CSBAs. The pat-

terns of SLA violation is explained in section 4. The

PAEAN4CLOUD framework is described in section

5. Section 6 presents the algorithms that automate the

violation detection and reconﬁguration of CSBA. The

related works is described in section 7. The conclu-

sion is drawn in section 8.

2 MOTIVATING SCENARIO

This section illustrates a simple scenario of today’s

industrial reality. This scenario is an extension of

Taxi Application Scenario that was originally co-

developed with several IT companies like Telefonica,

Telecom Italia, Ericson, 2ndQuadrant and SAP for

the EC’s 4CaaSt project (European Comission: Infor-

mation & Communication Technologies Unit, 2010).

The scenario promotes a comprehensive approach to

exist so that the design, conﬁguration, deployment,

monitoring of SLA, and adaptation of a CSBA can

occur.

TaxiTilburg is an application service provider

that offers the taxi ordering application TaxiOrdering-

CSBA in the form of an end-to-end process, as shown

in Fig. 1. The process is composed of several steps

including Receive Order, Allocate Taxi, Calculate

Route, Conﬁrm Order, and Reject Order. In order to

implement the steps S1 (Receive Order), S4 (Conﬁrm

Order), S5 (Reject Order) of the TaxiOrdering-CSBA

process, TaxiTilburg has developed an in-house SMS

software component that is able to receive new or-

ders by sms, and send order conﬁrmations or rejec-

tions to customers. Unfortunately, due to lack of ex-

pertise, TaxiTilburg has to rely on third-party SaaS

offerings for managing its taxi ﬂeet and for calculat-

ing routes, which are the two necessary functionali-

ties to implement step S2 (Allocate Taxi) and step 3

(Calculate Route) in its TaxiOrdering-CSBA process.

These two required functionalities are captured as the

two functional requirements Fleet Management Ser-

vice and Map Service.

Figure 1 also shows the Quality-of-

Service (QoS) offerings (responseTime(s) ≤

Figure 1: The process deﬁnition of TaxiOrdering-CSBA.

15)&(throughput(req/s) ≥ 100) that TaxiTilburg

has promised to its customers. To maintain this

predeﬁned QoSs, TaxiTilburg has distributed the

QoS value of maximum response time to each step

contained in TaxiOrdering-CSBA process. The

QoS requirement of minimum throughput 100 req/s

remains same for all steps, as shown in Figure 1.

2.1 Conﬁguring the CSBA

In order to deploy the TaxiOrdering-CSBA on the

cloud, it is necessary to satisfy all the functional

and QoS requirements of the TaxiOrdering-CSBA.

We follow the Blueprint Approach to conﬁgure the

TaxiOrdering-CSBA, so that all of its functional and

QoS reuqirements can be correctly fulﬁlled. The con-

cept “Blueprint” has deﬁned in (Nguyen et al., 2012a)

as “an uniform abstract description of a cloud ser-

vice, i.e. SaaS, PaaS, or IaaS, that facilitates the

CSBA developers with the selection, customization

and composition of cross-layered cloud services”.

Depending on the abstraction layer of cloud services,

there are three different types of blueprints SaaS

blueprint,PaaS Blueprint, and IaaS blueprint. Fig-

ure 2 illustrates the conﬁguration of TaxiOrdering-

CSBA using the blueprint approach. There is a SaaS

blueprint describing the TaxiOrdering-CSBA with

its offering and requirements. The blueprint compo-

sition approach (Nguyen et al., 2012b) subsequently

queries the marketplace repository to retrieve appro-

priate source blueprints whose offerings can fulﬁll the

requirements of the TaxiOrdering-CSBA blueprint.

The newly retrieved source blueprints may also con-

tain requirements, e.g. the FleetMgt-SaaS blueprint.

Hence, this querying and matchmaking task has to be

executed iteratively until the entire conﬁguration of

the TaxiOrdering-CSBA no longer contains any fur-

ther requirement.

The matchmaking between an offering and a re-

quirement does not only take into account the func-

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

362

Figure 2: Blueprint Conﬁguration for the Taxi Ordering CSBA.

tional matchmaking, but also the QoS matchmak-

ing, i.e. whether the QoS properties speciﬁed in

the << PolicyPro f ile >> of the requirement can

be satisﬁed by the QoS properties speciﬁed in the

<< PolicyPro f ile >> of the offering. For in-

stance in Figure 2, the two blueprints MapA-SaaS and

MapB-SaaS are selected to fulﬁll the requirement Map

Service, since their QoS properties regarding the

maximum response time and minimum throughput

satisfy the QoS properties speciﬁed for the require-

ment Map Service. Furthermore on the PaaS/IaaS

level, matchmaking is also based on the resource pro-

visioning speciﬁcation speciﬁed in the so-called <<

ResourceUtilizationPro f ile >> , e.g. in Figure 2 the

FleetMgt-SaaS blueprint has some resource provi-

sioning properties speciﬁed for its requirement JEE

Application Server regarding the required CPU

speed, memory size and network bandwidth, and

these properties can be satisﬁed by the resource pro-

visioning properties of the JEE-Linux-PaaS/IaaS

blueprint.

It is worth noting in Figure 2 that there could

be alternative matchmaking results for fulﬁlling a

requirement, e.g. for fulﬁlling the requirement

Map Service of the TaxiOrdering-CSBA blueprint,

and for fulﬁlling the requirement SQL Database of

the FleetMgt-SaaS blueprint. The QoS proper-

ties of the alternative matchmaking results are dif-

ferent, which implies that there might exist alterna-

tive conﬁgurations for the TaxiOrdering-CSBA that

could trigger a reconﬁguration process in case there

are some changes in the QoS requirements of the

TaxiOrdering-CSBA.

The next step after conﬁguring an CSBA is to

select among the alternatives the optimum blueprint

conﬁguration that will be deployed on the physical

cloud infrastructure. The selection strategy might de-

pend on a variety of criteria such as the cost, licens-

ing issues, or some private business constraints. For

brevity reason we do not discuss the criteria for se-

lecting a blueprint conﬁguration in this paper. In Fig-

ure 2, a conﬁguration has been chosen that involves

the MapA-SaaS blueprint to fulﬁll the requirement Map

Service of the TaxiOrdering-CSBA blueprint, and

the MySQL-PaaS blueprint to fulﬁll the requirement

SQL Database of the FleetMgt-SaaS blueprint.

2.2 SLA Speciﬁcation

Each cloud service provider involved in the

TaxiOrdering-CSBA conﬁguration in Fig.2 promises

to satisfy the stipulated Qualities of Services(QoS)

through a Service Level Agreement (SLA) with his

consumer. Hence, as soon as a blueprint conﬁgura-

tion is ﬁnalized, SLAs are generated among all the

involved cloud service providers. On the SaaS layer,

the SLAs mainly contain the promised maximum

response time of handling a request and the minimum

throughput (in terms of number of request per sec-

onds). On the PaaS layer, the PaaS providers mainly

specify in their SLAs the number of instances of their

offerings that can be provided to a single user, and

the resource capacity of their offerings including for

instance the CPU speed (in GHz), memory (in GiB),

networkBandwidth (in Gbit/s), and storage capacity

(in TB). Table 1 summarizes the SLA speciﬁcations

of all the cloud service offerings in the scenario.

PAEAN4CLOUD-AFrameworkforMonitoringandManagingtheSLAViolationofCloudService-basedApplications

363

Table 1: SLA speciﬁcation of Cloud Services.

Cloud Ser-

vice

SLA speciﬁcation for consumers

TaxiOrdering-

CSBA

(responseTime(s) ≤

15)&(throughput(req/s) ≥

100)

MaMapA-

SaaS

(responseTime(s) ≤

3)&(throughput(req/s) ≥ 100)

MapB-SaaS (responseTime(s) ≤

2)&(throughput(req/s) ≥ 120)

FleetMgt-

SaaS

(numberO f Instance ≤

4)&(responseTime(s) ≤

6)&(throughput(req/s) ≥ 50)

MySQL-PaaS (numberO f Instance ≤

4)&(capacity(T B) = 3)

PostgreSQL-

PaaS

(numberO f Instance ≤

3)&(capacity(T B) = 2)

JEE-Linux-

PaaS

(numberO f Instance ≤ 3)&(2 ≤

CPUSpeed(Ghz) ≤ 4)&(2 ≤

memory(GiB) ≤ 4)&(2 ≤

networkBandwidth(Gbit/s ≤ 3)

2.3 Deploying the CSBA

In the next phase, a deployment architecture has to be

developed based on the selected optimum blueprint

conﬁguration. The purpose of this deployment archi-

tecture is to serve as a cookbook for cloud adminis-

trator to deploy and maintain the CSBA on the cloud

infrastructure. In this architecture, the blueprints will

be transformed into a set of concrete, multi-layered

cloud service instances and network links that collab-

oratively form the deployment topology of the CSBA.

Figure 3 illustrates the deployment architecture for

the TaxiOrdering-CSBA, in which:

• Two instances of the MySQL-PaaS should be de-

ployed

• Two instances of the FleetMgt-SaaS blueprint

should be deployed on two instances of the

JEE-Linux-PaaS/IaaS.

• A network link should be deployed to con-

Figure 3: Deployment Architecture of the Taxi Ordering

CSBA.

nect the two MySQL-PaaS instances with the two

JEE-Linux-PaaS/IaaS instances.

• One instance of the MapA-SaaS should be de-

ployed

• A network link should be deployed to con-

nect the two FleetMgt-SaaS instances with the

Map-SaaS instance and with all the prospective

TaxiOrdering-CSBA instances.

Maintaining the QoS levels that have been speciﬁed in

the SLAs is indispensable for all the service providers

providing platform service, software services, and

physical resource services that are used for building

the TaxiOrdering-CSBA application that will under-

pin the process. At runtime, a framework is required

for monitoring the execution of TaxiOrdering-CSBA

process steps, detecting the occurrence of violations

or potential violations of QoS constraints, and pre-

venting these violations. PAEAN4CLOUD is pro-

posed for addressing these requirements as an efﬁ-

cient solution is missing.

3 PATTERNS OF SERVICE

LEVEL AGREEMENT

VIOLATION

In this section, we describe the Patterns of SLA Vi-

olation (PSLAV) that occur in workstreams while a

CSBA is running. Additionally, the formal seman-

tics of these patterns is provided in a lightweight style

using First Order Logic (FOL). The key purpose of

discovering and formalizing these patterns is to make

the PAEAN4CLOUD aware of SLA violations and

enable it for detecting SLA violations automatically.

In addition, the patterns enable PAEAN4CLOUD de-

tecting and preventing SLA violations proactively and

efﬁciently. It is worth noting that, the violations re-

ported in this paper have discovered through a study

on the cloud SLA samples provided in various litera-

ture e.g. (Wu and Buyya, 2010), (Emeakaroha et al.,

2012a), and (DeveloperWorks, 2010).

Before deﬁning the PSLAVs, the concepts SLA

and violation of SLA are deﬁned.

Deﬁnition 1. Let ‘Σ’ be the SLA that contains a list

of quality constraints ‘Q

’, security constraints ‘S

’,

privacy constraints ‘P

’, and regulatory constraints

‘R

’ such that,

Σ := (Q

∧ S

∧ P

∧ R

)

Since CSBA relies on third party cloud service

providers, an SLA involves a ‘consumer’ and one to

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

364

many ‘providers’. For example, a client “X” buys in-

frastructure services from Amazon

, platform service

from google

, and software service from SalesForce

. These providers must satisfy the obligations they

promise to the client “X”.

Deﬁnition 2. A violation ‘Γ’ indicates either a cloud

service consumer or a provider fails to satisfy one or

more constraints contained in the agreement.

The SLA violation patterns are classiﬁed into QoS

constraint violation patterns, security constraint vio-

lation patterns, privacy constraint violation patterns,

and regulatory constraint violation patterns. The term

‘constraint’ refers to obligations related to QoS, pri-

vacy, regulatory, and security which are stipulated and

must be satisﬁed by the involved service providers.

These patterns are described in the following. No-

tably, this paper covers the well-understood SLA vio-

lation patterns only.

• QoS Constraint Violation Patterns. Quality

constraints violation is denoted by ‘Γ

’. In rela-

tion to QoS

, the following violation patterns are

observed.

– Reliability Violation Pattern. ∀CSBA, ∃Γ

(Availability(X

)) → ¬satisﬁed, where X

de-

notes any cloud service. If availability of a

service is not at agreed level then quality con-

straint is violated and the service is not reliable

any longer.

– Throughput Violation. ∀(CSBA), ∃Γ

(T hroughput(X

)) → ¬satisﬁed. In this pat-

tern, throughput of infrastructure, platform, and

software services are not met by providers.

– Response Time Violation. ∀(CSBA), ∃Γ

)) → ¬satisﬁed. In this pattern, service

providers fail to satisfy response time threshold

promised to consumers.

– Processing Time Violation. ∀(CSBA), ∃Γ

if (T

)) → ¬satisﬁed. In this pattern,

providers fail to meet the processing time

threshold.

– Delay Time Violation. ∀(CSBA), ∃Γ

)) → ¬satisﬁed. If the maximum delay

threshold is not satisﬁed then it results quality

constraint violation.

http://aws.amazon.com/

https://developers.google.com/appengine/

http://www.salesforce.com/eu/?ir=1

Most of the QoS constraints listed in this paper have

adapted from (DeveloperWorks, 2010)

• Security Constraint Violation Patterns. ‘Γ

’

represents security constraints violation. The se-

curity constraint violation patterns are listed be-

low.

– Data Durability Constraint Violation.

∀(CSBA), ∃Γ

if (D

)) → ¬satisﬁed

where, D

∈ P

. D

, P

and D

represent

database service, platform service, and data

durability respectively. The data durabil-

ity violation happens in database services.

The violation happens if a database service

provider fails to persist data of CSBA users.

For database service, durability is an important

issue.

– Breaching Data Conﬁdentiality. ∀(CSBA), ∃Γ

if (D

)) → ¬satisﬁed, where D

represents

data conﬁdentiality. If conﬁdentiality of a data

is breached then it is treated as data conﬁden-

tiality violation.

– Breaching Data Integrity. ∀(CSBA), ∃Γ

)) → ¬satisﬁed, where, D

denotes data

integrity constraint. Data integrity refers to

consistent and accurate data. Data integrity vi-

olation happens if a database service provider

fails to maintain desired level of data consis-

tency and accuracy.

• Privacy Constraint Violation Patterns.

∀(CSBA), ∃Γ

if (P

)) → ¬satisﬁed, where P

denotes the privacy constraint and ‘Γ

’ privacy

constraints. In this violation, the providers fails

to isolate client’s data.

• Regulatory Policy Violation Patterns. ‘Γ

’ de-

notes the violation of regulatory policies related to

cloud services. The list below shows the patterns

of the regulatory policy violations.

– Data Retention Policy Violation. ∀(CSBA), ∃Γ

if (D

)) → ¬satisﬁed, where ‘D

’ repre-

sents data retention policy. In this violation,

providers fail to comply with the data retention

policies.

– Data Deletion Policy Violation. ∀(CSBA), ∃Γ

if (D

)) → ¬satisﬁed, where ‘D

’ is data

deletion policy. If a data service provider fails

to comply with the data deletion policies then it

results violation.

4 PAEAN4CLOUD FRAMEWORK

In this section, the PAEAN4CLOUD framework is

described. This architecture of PAEAN4CLOUD

framework is shown in Fig. 4.

PAEAN4CLOUD-AFrameworkforMonitoringandManagingtheSLAViolationofCloudService-basedApplications

365

Figure 4: The Architecture of PAEAN4CLOUD.

The architecture comprises the front-end man-

agement console and Back-end management compo-

nents. The console assists end-users in managing and

monitoring SLA violations and the back-end man-

agement components automate the management and

monitoring tasks.

The console contains four buttons that cater for

performing management tasks. The management

console relies on SOAP/RPC protocol to communi-

cate with the back-end components that essentially

perform management tasks.

The back-end consists of CSBA conﬁguration

manager, CSBA operation manager, SLA monitor,

SLA violation manager, and a repository. These com-

ponents are described brieﬂy in the following,

• CSBA Conﬁguration Manager. This component is

used for (re-)conﬁguring the cloud services that

are incorporated in CSBAs. The conﬁguration

manager contains blueprints of CSBAs. An user

carries out the modiﬁcation (if necessary) and the

conﬁguration manager that in essence is a com-

ponent automates these changes. The special pur-

pose of this component is reconﬁguring CSBA on

the ﬂy at runtime for preventing SLA violations.

• CSBA Operation Manager. CSBA operation man-

ager is an application management component

that manages operations performed at runtime by

CSBAs.

• Information Repository. While an instance is run-

ning, several operations are performed. The oper-

ation logs are archived in information repository

so that the history of the operations can be used

by other components. The repository stores moni-

tring information as well.

• SLA Monitor. This component observes the run-

ning instances. The roles of the SLA monitor are

as follows:

– watching operation cycles

– storing monitoring information in the reposi-

tory

– detecting violations of SLA

– reporting violations to the SLA violation man-

ager

In this paper, we develop an algorithm (presented

in 5) for detecting the SLA violations. The SLA

monitor relies on this algorithm. The proposed al-

gorithm is designed using the SLA violation pat-

terns deﬁned in section 3.

• SLA violation manager: The primary role of the

SLA violation manager is preventing violations.

The violation manager communicates with SLA

monitor that detects violation and sends report to

violation manager that acts to prevent the viola-

tion. In addition, it communicates with repos-

itory and fetch necessary information. A com-

ponent called performance analyzer is integrated

with SLA violation manager. The performance

analyzer carries out analysis on the history of

the instances, predicts the potential violations.

Based on this prediction, the violation manager

takes necessary actions in particular, reconﬁgure

CSBAs to resist the potential violations proac-

tively. The next section describes reconﬁguration

of CSBA.

5 DETECTING SLA VIOLATION

AND RECONFIGURING CSBA

The SLA monitor of PAEAN4CLOUD relies on the

algorithms proposed in this paper for automated rea-

soning with CSBAs. These algorithms are presented

and discussed in this section. Additionally, the recon-

ﬁguration of CSBA is discussed here.

5.1 Detecting SLA Violation

The violation detection algorithms are the key contri-

butions of this paper. Algorithm 5.1 and 5.2 are de-

signed for automated reasoning with CSBA to detect

SLA violations. It is worth noting that privacy and

regulatory policy violations out of the scope.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

366

In this section, the detection of violations is dis-

cussed using the TaxiOrdering-CSBA scenario (de-

scribed in section 2). The TaxiOrdering-CSBA is con-

ﬁgured by integrating a business process service, soft-

ware services, platform services, and infrastructure

service that are provided by different vendors. The

conﬁguration of CSBA is discussed in Section 2.1.

The central focus of TaxiOrdering-CSBA scenario

is the SLA between the client TaxiTilburg and the

cloud service providers include BestHosting, Tele-

comProvider A and B, Auto Inc., and MapProvider A

and B. As TaxiTilburg is yet another service provider

for the end-users, the quality of the services promised

by the service providers is critical to TaxiTilburg. Be-

sides, the data security is always crucial for the client

TaxiTilburg.

Upon receiving a request placed by the customer

‘X’, a process instance is created. For this instance,

the process execution starts with activity Allocate Taxi

). Then, the SLA monitor is called and software

services are invoked if they are available. If a required

software service is not available, the monitor detects

the unavailability and reports it to the SLA manager.

For S

, the expected values for the QoS parameters

responsetime is 6 seconds and expected throughput is

100 requests per second. However, the actual value

that is taken for response time is 8 seconds which is

greater than the expected value. SLA monitor detects

this violation of quality constraints and reports it to

SLA Manager (See section 4 for detailed description

of the SLA manager). SLA manager prevents the vi-

olation of response time of Taxi Ordering Process.

The response time violation of Taxi Ordering Pro-

cess results in end-client dissatisfaction that inﬂu-

ences the customer in choosing another taxi service

provider. In order to avoid such consequence, the

SLA manager acts proactively based on history of

completed activities.

Furthermore, for each process instance that is

completed successfully, the data is saved in the

database permanently. The DatabaseProviderA

grantees data security in particular, the durability of

the data and consistency of the database to TaxiTil-

burg. The SLA monitor can detect if data is lost or

the database is inconsistent. Algorithm 5.2 is used for

automated reasoning with TaxiOrdering-CSBA. Af-

ter data of an end-client (the client who ordered for

a taxi) is stored in the TaxiOrdering database, the ap-

plication manager of TaxiOrdering-CSBA access the

database remotely for retrieving detail of a customer.

The application manager executes query and retrieve

the detail of the client. If complete detail is not found

in the database then the SLA monitor reports this as a

violation of security constraint, to the SLA manager.

Algorithm 5.1: Quality Constraint Violation Detection (CSBA)

Input:

i. X

that includes the cloud services such that,

, S

, P

, I

) v X

ii. QoS parameters P

QoS

contained in SLA.

Output: Detect and Report the violation of the QoS constraints

Global Variables:

λ ← cloud service based application(CSBA)

← cloud services, B

← business process services

← software services,P

← platform services

← infrastructure services, Monitor ← SLA monitor

SLA

← SLA Manager, R ← information repository

← quality constraints, T

← response time

← processing time, D

← delay time

Availability ← Service Availability,A ← Process Activity

T hroughput ← the performance rate of services

← Process Instance, EValue ← Expected Value

AValue ← Actual Value, ERate ← Expected Throughput

ARate ← Actual Throughput,H ← Processing History

procedure (Initialize)











for each inbound request ‘R

’ to λ

if (λ 6= ∅

then



Call Monitor and invoke B

;

else Cancel ‘R

’;

if B

6= ∅

then











if (B

.Availability = “Yes”)

then Instantiate B

(Comment: a process instance B

is created

in this step).

else Report Γ

to M

SLA

and Store H in R;

else Cancel ‘R

’ and Terminate ‘B

’;



for each B

execute (A

∈ B

);











for each A

(Comment: Assume that ‘A’ is an operational

activity

if A 6= ∅

then



invoke (S

and P

and I

v X

);

else Cancel ‘R

’ and Terminate ‘B

’;

if ((S

. Availability = “yes”) and

. Availability = “yes”)

and (I

. Availability = “yes”))

then







(Compute AValue (T

, D

for X

)

and ARate (Throughput for X

)

and T

for A);

else



Report Γ

to M

SLA

and

Store H in R;

if (AValue (T

, D

) > EValue (T

, D

)&&

ARate (Throughput) > ERate (T hroughput))&&

AValue(T

) > AValue(T

) for A)

then



Report Γ

to M

SLA

and

Store H in R;

else



Execute Next A;











for all A

v B

repeat

Check SLA Violation

until Complete the execution of B

;

Additionally, the application manager checks con-

sistency of the TaxiOrdering database either period-

PAEAN4CLOUD-AFrameworkforMonitoringandManagingtheSLAViolationofCloudService-basedApplications

367

Algorithm 5.2: (SecurityConstraintViolationDetection)

Input:

i. S

, D

∈ P

ii. Security parameters ‘P

Security

’contained in SLA.

Output: Detect and Report the violation of

security constraints

Global Variables:

← Software Services

← Platform Services

← Database Services

Monitor ← SLA Monitor

SLA

← SLA Manager

procedure (Initialize)

/ ∗ Durability Violation Detection ∗ /











for each Query to D

if (D

6= ∅)

then Call Monitor and

Run SELECT D

FROM D

;

else Cancel Query;



if Query (D

) → D

Not Found

then Report Γ

to M

SLA

and Store H in R;

/ ∗ Consistency Violation Detection ∗ /











for each Database Checking ‘ChkDB’ to D

if (D

6= ∅)

then Call Monitor and Run DBCC CHECKDB

/* CHECKDB command includes CHECKALLOC

CHECKTABLE, and CHECKCATALOG

commands */

else Cancel ChkDB;



if ChkDB (D

) → ¬ consistent D

then Report Γ

to M

SLA

and Store H in R;

ically or when a database transaction is happened.

For any consistency checking request placed by the

application manager, SLA monitor is called. The

application manager access databases and run query

such as, an SQL statement ’DBCC CHECKDB’ on

TaxiOrdering database for checking consistency. If

SLA monitor detects inconsistency in TaxiOrdering

database, then it reports a violation to SLA man-

ager. It is worth noting that in this example only SQL

commands are used for query database and checking

consistency because the TaxiOrdering is a mySQL

database. The proposed solution supports executing

other commands as well since it supports integrat-

ing other database services. In essence, the query

statements and consistency checking depends on the

database service integrated with CSBAs.

The SLA manager calls the conﬁguration manager

- depending on the violation pattern - for reconﬁgur-

ing the CSBAs. In the next section, the strategies for

reconﬁguring CSBAs are discussed.

5.2 Reconﬁguring the Service-based

Cloud Application

After being triggered by the SLA Manager, the Con-

ﬁguration and Deployment Manager is responsible

for making an informed decision on the preventive

reconﬁguration strategies and actions for the BPaaS

based on the violation patterns that have been detected

in the previous BPaaS instances. The aim is to en-

able future BPaaS instances to meet the expected SLA

with their clients. Figure 5 illustrates the decision tree

inside the Conﬁguration and Deployment Manager, in

which each SLA Violation pattern detected in the pre-

vious section 5 is tackled by speciﬁc reconﬁguration

strategies, which lead to speciﬁc reconﬁguration ac-

tions. In the following, each strategy and action is

explained in detail:

• RS1- Find alternative SaaS: This strategy can be

used when a constituent SaaS of a BPaaS is not

available for invocation (Availability Constraint

Violation) or its QoS (response time and through-

put) performance is decreasing. The idea is to ﬁnd

an alternative substitution for this SaaS. This strat-

egy leads to the reconﬁguration action RA1- Dy-

namic SaaS Binding, which dynamically binds all

the upcoming BPaaS instances to the new SaaS.

• RS2- Scale up SaaS: This strategy can be used

when the response time constraint of a constituent

SaaS is violated (ResponseTime Constraint Vi-

olation). The idea is to prevent this violation

for the future BPaaS instances by resizing the

infrastructure resources of the running SaaS in-

stances, including resizing and rebooting their

Virtual Machines with more computing resources

(RA2-Resizing and Rebooting VM) and reconﬁg-

uring their network links with less latency (RA3-

Reconﬁguring Network Link).

• RS3- Scale out SaaS: This strategy can be used

when the throughput constraint of a constituent

SaaS is violated (Throughput Constraint Viola-

tion). The idea is to prevent this violation for

the future BPaaS instances by deploying new in-

stances of this SaaS (RA4- Deploying new In-

stances) and reconﬁguring the network link of all

the SaaS instances with larger bandwidth (RA4-

Reconﬁguring Network Link).

• RS4- Find alternative data service provider: This

strategy can be used when a violation in data

security and conﬁdentiality is detected by the

SLA Manager (Data Security Constraint Viola-

tion). The idea is to switch to a new Data ser-

vice provider that provides better security mech-

anism and guarantee. This strategy leads to the

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

368

Figure 5: Reconﬁguration Strategies and Actions for each SLA Violation Pattern.

process of migrating data from the old to the new

provider (RA5- Migrating Data), and reconﬁgur-

ing the Data Access mechanism (RA6- Migrating

Data)

In case several violation patterns are detected, mul-

tiple reconﬁguration strategies could be combined to

perform preventive actions. For instance, in case both

the response time and throughput constraint of a SaaS

are violated, one could follow both RS2 and RS3 to

resize the current SaaS instances with more resource

and to deploy new instances of the SaaS.

In our running example in section 2, the

TaxiOrdering-BPaaS is conﬁgured using the blueprint

approach that results into a blueprint conﬁguration

in Figure 2. Based on the blueprint conﬁguration,

a deployment conﬁguration has been developed in

Figure 3, which serves as a cookbook for cloud

administrator to actually deploy and maintain the

TaxiOrdering-BPaaS, so that all the SLA constraints

between the TaxiOrdering-BPaaS with its clients can

be satisﬁed. Nevertheless, at peak time period (e.g.

new year’s eve), the number of instances of the

TaxiOrdering-BPaaS may increase dramatically and

hence lead to several SLA violations. The previous

Section 5 points out the four sample violation cases

that may occur to the TaxiOrdering-BPaaS.

• V1: Response time of the step (S2-Allocate Taxi)

increases, i.e. the actual response time is 8 s

whilst the expected response time is only 6s. This

is due to the response time constraint violation of

the FleetMgt-SaaS.

• V2: Throughput of the step (S2-Allocate Taxi) de-

creases, i.e. the actual throughput is only 8 req/s

whilst the expected throughput is 10 req/s. This

is due to the throughput constraint violation of the

FleetMgt-SaaS.

• V3: Step (S3-Calculate Route) cannot be exe-

cuted. This is due to the availability constraint

violation of the MapA-SaaS.

• V4: Data security is violated. This is due to the

data security constraint violation of the MySQL-

PaaS.

With help of the reconﬁguration decision tree, the

Conﬁguration and Deployment Manager is able to

perform preventive actions for the future instances of

the TaxiOrdering-BPaaS. Table 2 explains which re-

conﬁguration strategy and action are performed for

which violation cases in our running example. Please

note that the details of how to perform a reconﬁgura-

tion action strongly depends on the blueprint conﬁgu-

ration of the TaxiOrdering-BPaaS introduced in Sec-

tion 2.1 that provides different alternative conﬁgura-

tions. In this paper, we do not discuss the approaches

of selecting a particular conﬁguration.

Figure 6: The deployment architecture of the reconifgured

TaxiOrdering-BPaaS.

Performing the reconﬁguration actions will re-

sult in a different deployment conﬁguration of the

TaxiOrdering-BPaaS. Figure 6 illustrates this adapted

deployment conﬁguration of the TaxiOrdering-BPaaS

• 3 instances of the FleetMMapB-SaaS is deployed

on 3 instances of the Linux-JEE-PaaS/IaaS, each

PAEAN4CLOUD-AFrameworkforMonitoringandManagingtheSLAViolationofCloudService-basedApplications

369

Table 2: Reconﬁguration Strategies and Actions for the sample TaxiOrdering-BPaaS.

Cloud Service SLA Violation Reconﬁguration

Strategy &

Action

Details

FleetMgt-

SaaS

V1: Response Time

Constraint

RS2 =⇒ RA2 Resizing the VM with CPUSpeed(Ghz)=3, mem-

ory(GiB)=4.

FleetMgt-

SaaS

V2: Throughput

Constraint

RS3 =⇒ RA3

& RA4

Deploying another instance of the stack FleetMgt-

SaaS + JEE-Linux-PaaS/IaaS. Reconﬁguring the

network link of all three JEE-Linux-PaaS/IaaS in-

stances with networkBandwidth(Gbit/s) = 3

MapA-SaaS V3: Availability

Constraint

RS1 =⇒ RA1 Dynamically rebind to the new MapB-SaaS in-

stance.

MySQL-PaaS V4: Data Security

Constraint

RS4 =⇒ RA5

& RA6

Migrate all the data of the FleetMgt-SaaS to 2 new

instances of PostgreSQL-PaaS. reconﬁguring the

data access layer of the FleetMgt-SaaS.

with 3Ghz CPU speed, 3 GiB memeory and 3 Gbit

network link

• 3 instances of the PostgreSQL databases are used

by the FleetMgt-SaaS instances to store data.

• A MapB-SaaS instance used to performed the

“Step 3- Calculate Route”, instead of the MapA-

SaaS instance.

6 RELATED WORKS

This section describes the related works in the area

of monitoring and management the SLA violation of

the CSBA. A number of remarkable works related to

monitoring and management SLAs of the service ori-

ented and Grid applications have been presented in

many literature e.g. (Comuzzi et al., 2009), (Fu and

Huang, 2006), (Koller and Schubert, 2007), (Boni-

face et al., 2007), (Wood et al., 2009). However, a

very little works are found in the area of monitoring

and managing SLAs of the cloud service based sys-

tem. From the conceptual point of view, monitoring

SLA in the area of cloud, grid and conventional ser-

vice oriented domains are the same, yet the methods

of monitoring SLAs of the systems serving these do-

mains differ. Therefore, since this paper is focused

on detecting the violation of the SLAs within cloud

environment, the related works focusing on monitor-

ing SLA for detecting violation and reconﬁguration

of cloud services is discussed in this section.

In (Emeakaroha et al., 2012b), a framework called

DeSVi is proposed to detect SLA violation in cloud

infrastructure. The goal of this framework is similar

to PAEAN4CLOUD. The framework is proposed for

monitor the resources and component perform case-

bases reasoning for detecting the violation by utiliz-

ing the notion of knowledge database. Additionally,

the framework relies on the service level objective.

DeSVi contains a application deployment component

that facilitates deploying application automatically.

Hammad (Hammadi and Hussain, 2012) proposes

framework for monitoring QoS. It comprises two

modules include reputation assessment module and

transactional risk assessment module. It assists in

assessing performance based on QOSs observed and

also assists in making decision whether or not a cloud

service customer should migrate to another provider.

SageShift (Sukwong et al., 2012) consists of a Vir-

tual Machine(VM) admission control - Sage, and a

hypervisor - shift. The key focus of the SageShift

is preventing SLA violations. SageShift assess the

feasibility of SLA based on the incoming requests

and prevent SLA violations by adjusting the required

amount of resources dynamically and determining the

sequence of VM execution. Unfortunately, the poten-

tial SLA violations with respect to software service

and platform service cannot be traced as SageShift

oversights these service issues.

(Chandrasekar et al., 2012) proposes a QoS mon-

itor that reads data and a offers a solution that is built

upon the Markov Chain

to establish trust between

service consumer and provider.

A holistic approach called OPTIMIS was pro-

posed by (Ferrer et al., 2012) to optimize entire ser-

vice life cycle including monitoring services. The

authors describe various aspects of service monitor-

ing and managing SLAs between service provider and

consumer. They stress on a list issues that need to be

improved for optimizing the performance of current

solutions for monitoring the cloud services. However,

the authors do not offer any optimizing method. Es-

sentially, SLA monitoring is rather a small part of the

www.math.rutgers.edu/courses/338/coursenotes/

chapter5.pdf

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

370

OPTIMIS approach.

Most of the SLA monitoring approaches discussed

in the above focus on the QoS aspect of services.

Nonetheless, PAEAN4CLOUD is able to detect the

QoS as well as security constraint violations in the

cloud environment. To the best of our knowledge, ex-

isting SLA monitoring solutions do not address the

security constraint violations. The SLA monitor of

the PAEAN4CLOUD relies on the category-based

violation detection approach that enhance the capa-

bility of the monitoring system for identifying vio-

lations efﬁciently. Additionally, the category-based

violation detection approach assists in deciding the

most suitable reconﬁguration strategy for avoiding

the violation of SLAs. None of the SLA monitor-

ing approaches discussed in the above deals with the

category-based violation detection of cloud services.

7 CONCLUSION AND FUTURE

WORKS

In this paper, we have highlighted the challenges

of monitoring and predicting of SLA violations in

cloud service based applications. Thus, we moti-

vated emerging requirements for the monitoring, de-

tection, and conﬁguring of SLA violation in a real

world scenario. We argued that the speciﬁc nature

of cloud service based applications using a mixture of

SaaS, PaaS and IaaS solutions - possibly from var-

ious providers, makes classic approaches incapable

of meeting these requirements. Consequently, we

proposed a PAEAN4CLOUD, a generic framework

monitoring, detecting, and conﬁguring SLA viola-

tions. The framework relies on components and al-

gorithms for automated reasoning with CSBA for de-

tecting SLA. Currently we are exploring the idea of

root cause analysis for preventing SLA violations in

such as way that monitoring can play a pivotal role to

predict violations of the QoS requirements as stipu-

lated in the SLA and to suggest (manually or automat-

ically) some adjustment to enforce the running appli-

cation to comply with the agreed-on SLA. The adjust-

ment could be (1) to change the service infrastructure

in such way, that the application will be processed and

respect the SLA. Another possibility is to (2) apply

self-scaling (up/out) techniques to enable/enforce the

application to comply with the SLA of the application

as a whole.

REFERENCES

Boniface, M. J., Phillips, S., Perez, A. S.-M., and Surridge,

M. (2007). Dynamic service provisioning using gria

slas. In NFPSLA-SOC’07. Event Dates: 17th Septem-

ber 2007.

Chandrasekar, A., Chandrasekar, K., Mahadevan, M., and

Varalakshmi, P. (2012).

Comuzzi, M., Kotsokalis, C., Spanoudakis, G., and

Yahyapour, R. (2009). Establishing and monitoring

slas in complex service based systems. In ICWS, pages

783–790.

DeveloperWorks (2010). Review and summary of cloud ser-

vice level agreement.

Emeakaroha, V. C., Ferreto, T. C., Netto, M. A. S., Brandic,

I., and Rose, C. A. F. D. (2012a). Casvid: Application

level monitoring for sla violation detection in clouds.

In COMPSAC, pages 499–508.

Emeakaroha, V. C., Netto, M. A. S., Calheiros, R. N.,

Brandic, I., Buyya, R., and Rose, C. A. F. D. (2012b).

Towards autonomic detection of sla violations in

cloud infrastructures. Future Generation Comp. Syst.,

28(7):1017–1029.

European Comission: Information & Communication Tech-

nologies Unit (2010). 4CaaSt: Building the PaaS

Cloud of the Future. Project Objectives Document.

Ferrer, A. J., Hernndez, F., Tordsson, J., Elmroth, E., Ali-

Eldin, A., Zsigri, C., Sirvent, R., Guitart, J., Badia,

R. M., Djemame, K., Ziegler, W., Dimitrakos, T., Nair,

S. K., Kousiouris, G., Konstanteli, K., Varvarigou, T.,

Hudzia, B., Kipp, A., Wesner, S., Corrales, M., Forg,

N., Sharif, T., and Sheridan, C. (2012). Optimis: A

holistic approach to cloud service provisioning. Fu-

ture Generation Computer Systems, 28(1):66 – 77.

Fu, W. and Huang, Q. (2006). Grideye: A service-oriented

grid monitoring system with improved forecasting al-

gorithm. In GCC Workshops, pages 5–12.

Hammadi, A. M. and Hussain, O. (2012). A framework

for sla assurance in cloud computing. In AINA Work-

shops, pages 393–398.

Koller, B. and Schubert, L. (2007). Towards autonomous sla

management using a proxy-like approach. Multiagent

and Grid Systems, 3(3):313–325.

Nguyen, D. K., Lelli, F., Papazoglou, M. P., and van den

Heuvel, W.-J. (2012a). Blueprinting approach in sup-

port of cloud computing. Future Internet, 4(1):322–

346.

Nguyen, D. K., Lelli, F., Papazoglou, M. P., and van den

Heuvel, W.-J. (2012b). Issue in automatic combina-

tion of cloud services. In ISPA, pages 487–493.

Sukwong, O., Sangpetch, A., and Kim, H. S. (2012).

Sageshift: Managing slas for highly consolidated

cloud. In INFOCOM, pages 208–216.

Wood, T., Shenoy, P. J., Venkataramani, A., and Yousif,

M. S. (2009). Sandpiper: Black-box and gray-box re-

source management for virtual machines. Computer

Networks, 53(17):2923–2938.

Wu, L. and Buyya, R. (2010). Service level agreement (sla)

in utility computing systems. CoRR, abs/1010.2881.

PAEAN4CLOUD-AFrameworkforMonitoringandManagingtheSLAViolationofCloudService-basedApplications

371