CloudMPL: A Domain Speciﬁc Language for Describing Management

Policies for an Autonomic Cloud Infrastructure

Marwah M. Alansari

, Andre Almeida

, Nelly Bencomo

and Behzad Bordbar

School of Computer Science, University of Birmingham, Birmingham, U.K.

Federal Institute of Science of Education, Science and Technology, Parnamirim, Brazil

School of Computer Science, Aston University, Birmingham, U.K.

Keywords:

Management Policies, Rule Language, Domain Speciﬁc Language, Autonomic Architecture, Cloud Infras-

tucture.

Abstract:

To beneﬁt from the advantages that Cloud Computing brings to the IT industry, management policies must be

implemented as a part of the operation of the Cloud. Among others, for example, the speciﬁcation of policies

can be used for the management of energy to reduce the cost of running the IT system or also for security

policies while handling privacy issues of users. As cloud platforms are large, manual enforcement of policies

is not scalable. Hence, autonomic approaches for management policies have recently received a considerable

attention. These approaches allow speciﬁcation of rules that are executed via rule-engines. The process of

rules creation starts by the interpretation of the policies drafted by high-rank managers. Then, technical IT

staff translate such policies to operational activities to implement them. Such process can start from a textual

declarative description and after numerous steps terminates in a set of rules to be executed on a rule engine. To

simplify the steps and to bridge the considerable gap between the declarative policies and executable rules, we

propose a domain-speciﬁc language called CloudMPL. We also design a method of automated transformation

of the rules captured in CloudMPL to the popular rule-engine Drools. As the policies are changed over time,

code generation will reduce the time required for the implementation of the policies. In addition, using a

declarative language for writing the speciﬁcations is expected to make the authoring of rules easier. We

demonstrate the use of the CloudMPL language into a running example extracted from a management energy

consumption case study.

1 INTRODUCTION

Management of Cloud infrastructure supported by au-

tonomic techniques has recently received a consider-

able attention (Beloglazov and Buyya, 2010; Mi et al.,

2010; Maurer et al., 2013; Borgetto et al., 2012). Sev-

eral existing autonomic techniques make a use of rule-

based systems (Mi et al., 2010; Maurer et al., 2013;

Borgetto et al., 2012; Alansari and Bordbar, 2013).

The rule-based systems operate by using a set of state-

ments in a form of ”if < condition > then < action >

” which are known as rules executed by a rule-engine.

Rule-based frameworks have been used to automati-

cally trigger the live-migration of virtual machine by

using different types of constraints rules. The con-

straints rules are formulated as management policies

(Borgetto et al., 2012)(Alansari and Bordbar, 2013).

In (Alansari and Bordbar, 2013), the authors pro-

pose an architectural framework for automatically ex-

ecuting management policies on Cloud infrastructure.

The rule engine is integrated to work with Cloud

management system to control the migration of run-

ning virtual machines among hosting nodes. Pol-

icy Rule Engine and Cloud Manager are communi-

cated through sensors and actuators. The sensor is

directly interlinked with Cloud APIs for management

of virtual machines that are responsible for request-

ing monitoring parameters such as Estimated Energy

Consumption and Current Resource Usage. Whilst

the actuator uses action APIs that directly launch the

management actions, such as virtual machine migra-

tion action (Alansari and Bordbar, 2013).

There are three steps deﬁned for designing suit-

able policies which can be executed into the auto-

nomic framework proposed in (Alansari and Bord-

bar, 2013) or similar frameworks as in (Maurer et al.,

2013). These steps are Policy Authoring, Policy Im-

plementation and Policy Deployment and Execution

451

M. Alansari M., Almeida A., Bencomo N. and Bordbar B..

CloudMPL: A Domain Speciﬁc Language for Describing Management Policies for an Autonomic Cloud Infrastructure.

DOI: 10.5220/0005446004510462

In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 451-462

ISBN: 978-989-758-104-5

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

Figure 1: The steps for designing and publishing management policies.

(see Figure 1). Cloud-domain experts and rule de-

velopers are the roles which are involved during the

design process of the management policies. Cloud-

domain experts write the policies in simple plain En-

glish sentences “if/then ”. Rule developers encode the

described policies using a rule language and generat-

ing executable management policies as well as Cloud-

infrastructure domain model (Alansari and Bordbar,

2014).

Management policies are updated regularly be-

cause of alteration in the technical environment,

changes in the regulations, modiﬁcations of SLAs and

changes in business requirements. While going thor-

ough this process, there is a semantic gap between

Policy Authoring and Implementation levels. This

gap can be bridged by using a combination of Do-

main Speciﬁc Language (DSL) for authoring of the

rules and automated code generation for producing

rules which are executed in the rule-engine. The Do-

main Speciﬁc Language (DSL) supplies expressive

representations, textual notions and high-level spec-

iﬁcation to describe policies written using plain En-

glish. Such a language helps the domain experts, who

may have little knowledge about formulating rules, to

avoid the complexity of writing management policies.

On the other hand, Code generation is used to convert

the policies captured in the DSL to be an input for

executable Rule Languages such as Drools.

This paper makes two contributions. Firstly,

we propose Cloud Management Policy Language

(CloudMPL), a domain speciﬁc language to support

Cloud-domain experts to specify policies. CloudMPL

is a textual language with a speciﬁcation partially in-

spired by the RELAX Language(Whittle et al., 2010).

Secondly, we design a set of mapping rules used

for automatic transformation from CloudMPL to rule

languages based on Object Patterns such as Drools

(JBossCommunity, 2011) and JRules (IBM-ILOG,

2007). The objective is to built a foundation for the

automatic generation of a management policy from

Policy Authoring to Implementation levels and hence

bridge the gap described above.

The paper is organised as follows. Section 2

has an overview about rule-based systems and do-

main speciﬁc languages used in Cloud environment.

CloudMPL language and its speciﬁcation are dis-

cussed in Section 3. The speciﬁcation of management

policies in an executable rule language is explained in

Section 4. Section 5 includes the designed mapping

rules from CloudMPL to Drools. Section 6 contains

a demonstration of CloudMPL in XText for authoring

migration policies in energy management case study.

Finally, the conclusion is presented in Section 7.

2 BACKGROUND AND RELATED

WORK

This section introduces concepts about rule engines

and domain-speciﬁc languages.

2.1 Rule Engine and Rules

Policies can be executed via a rule-based engine such

as Drools(JBossCommunity, 2011) and ILOG JRules

(IBM-ILOG, 2007). Both Drools and JRules en-

gines are based on the enhanced version of the RETE-

Algorithm for supporting Object Oriented Pattern.

RETE-Algorithm was introduced by Charles Forgy; it

is one of the efﬁcient implementation rules inference

engines. The algorithm represents rules as an acyclic

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

452

graph to form a RETE-network and provides a pattern

matching process (Forgy, 1982).

The architecture of the rule engine is shown

in Figure 2. Both Drools and JRules rule engines

include Rule-Base and Working Memory. Rule Base

is a long-term memory in which rules are stored.

Working Memory is a type of short-term memory,

which contains Facts that need to be evaluated by

the inference engine. Facts are object models that

contain attributes that illustrate domain data for an

application. Agenda is the place where a rule that

has become active is stored for later in order to ﬁre

satisﬁed rules. The agenda uses resolving conﬂicting

methodology for ordering the execution of active

rules (Forgy, 1982). In order to execute policies in

a rule-based engine, policies have to be written in a

form of rule-sets. A rule-set consists of a number of

conditions followed with a set of sequential actions

in which the rule-set is expressed in the following

format:

when (condition statements) then (action state-

ments)

Figure 3 illustrates a sample of a constraint-based

policy encoded in Drools Language. The function of

this rule-set is to allow migration from Host1 to either

Host2 or Host3. The action will be invoked which re-

quests to migrate a virtual machine from Host1 when

the conditions are satisﬁed.

2.2 Domain Speciﬁc Languages DSLs

Domain-speciﬁc languages (DSLs) are languages

which are designed to be used in a speciﬁc application

domain. DSLs languages provide a special feature

in terms of the expressiveness and simplicity com-

pared with general-purpose programming languages

(Mernik et al., 2005). Using DSLs have several ad-

vantages. They can speed up the development time

since the language is designed to be used for speciﬁc

environment. In addition, the language can assist to

reduce the number of domain and programming ex-

pertise which are required (Mernik et al., 2005). Fur-

thermore, the domain-language is an extendible and

Figure 2: The architecture of OO-RETE engine.

Figure 3: A sample of a constraint management policy ex-

pressed in Drools Language.

a machine readable which allows to build auto-code

generation tools in order to reduce the development

time (Mernik et al., 2005). To accomplish these fea-

tures provided by DSLs, designing such languages re-

quires the experience in both domain-knowledge and

language development. In our research, we focus

on domain-speciﬁc languages designed for Cloud-

platform.

2.2.1 DSLs used in Cloud Computing

There are extensive research for proposing many

DSLs for automating the deployment of applications

into Cloud-environment. One of these languages is

Crawl which is apart of Cloud Crawler environment

proposed for automating the execution of applications

performance test in IaaS used by Cloud application

developers (Cunha et al., 2013). Crawl is a declarative

and an extensible domain-speciﬁc language (DSL)

to provide a high-level speciﬁcation that captures all

the technical important information for executing ap-

plication performance tests(Cunha et al., 2013). In-

stances of these information are the conﬁguration pa-

rameters and the quantity of the resources allocated to

application components(Cunha et al., 2013). The lan-

guage’s textual notion is described via YAML. Fur-

thermore, the language allows using XML and JSON

to deﬁne new speciﬁcation of test scenarios(Cunha

et al., 2013).

Neptune is also another domain speciﬁc language

(DSL) designed to automate the conﬁguration and de-

ployment HPC applications executed in Cloud(Bunch

et al., 2011). The objective of Nuptune is to pro-

vide portability and ﬂexibility to the developers of

HPC(Bunch et al., 2011). Neptune is a meta-

programming extension of the Ruby programming

language with a ﬂexibility to run large number of

ruby’s libraries which are designed to communicate

with Cloud- infrastructure(Bunch et al., 2011). Nep-

tune programmes allow users to write Ruby scripting

code and also Nuptune programs can also be used

in Ruby programs using neptune keyword. The pro-

grammes of Nuptune is composed of one or more

invocations for jobs to be processed in Cloud ser-

CloudMPL:ADomainSpecificLanguageforDescribingManagementPoliciesforanAutonomicCloudInfrastructure

453

vices(Bunch et al., 2011). The language is inte-

grated to run into AppScale which is an open-source

Cloud environment that uses Google App Engine

APIs(Bunch et al., 2011).

Pim4Cloud DSL is a Platform Independent Model

for Cloud-based application which is designed using

a component-based approach(Brandtzæg et al., 2012).

A Cloud application- designer models the application

by using Pim4Cloud DSL. Meanwhile, at the other

side the available resources for the modelled appli-

cation are speciﬁed by Cloud provider (Brandtzæg

et al., 2012). The Pim4Cloud has an interpreter

which is used to match the assigned resources to

application requirement. Pim4Cloud DSL is imple-

mented in to Scala which includes different set of

codes for modelling different topology for Cloud ap-

plications (Brandtzæg et al., 2012). The syntax of

the Pim4Cloud DSL starts by deﬁning the application

as an abstract class which can factorise the shared

entities. Each application topology can extend the

abstract class. Pim4Cloud DSL platform supports

a static analysis for the modelled application and

also allow the deployment of Cloud-component to be

reused (Brandtzæg et al., 2012).

3 CloudMPL LANGUAGE

CloudMPL can be applied instead of using Plain

English sentences for writing the management pol-

icy at early stage. CloudMPL is a textual language

that speciﬁcally is designed to be used by Cloud

domain-experts to describe management policies be-

fore interpreting them to an executable rule language.

CloudMPL is enriched with domain vocabularies and

expressive operators for expressing conditions and ac-

tions parts which are partially inspired by the RE-

LAX Language(Whittle et al., 2010). CloudMPL is

targeting to author management policies which will

be executed in Infrastucture-as-a-Service(IaaS) Cloud

model.

When Cloud-domain experts specify policies, ba-

sically they are concerned about if some speciﬁc con-

ditions are met, based on resources that compose

a Cloud infrastructure, and actions that might be

taken upon these conditions. Therefore, CloudMPL

is designed to focus on the speciﬁcation of Cloud-

related resources and policies. The speciﬁcation of

CloudMPL includes a domain-vocabulary, a meta-

model, a set of operators, which are extracted from

RELAX language to describe various types of condi-

tions might be found in a management policy, and a

grammar for using the language.

3.1 CloudMPL Meta-model

Figure 4 presents the meta-model for CloudMPL lan-

guage. In the meta-model described in Figure 4, a

Resource is an element that can be managed and/or

monitored which could be a host, a virtual machine,

a cluster or any kind of resource that can described

in term of Properties. Those Properties should rep-

resent any kind of information that can be monitored

or used to describe a Resource. Every property has a

Type that can be either a built-in type, such as Num-

ber or String, or could be a Resource created by the

user. Each Policy is composed of several conditions,

detailed in terms of constraints. Constraints are three

different types which are:

1. Time, when an expert is interested in time related

events.

2. Location, which is an optional element, is to

check if a given resource is in a speciﬁc location.

3. Ordinal where raw values or a status of a given

property related to a resource are checked.

In this level of abstraction, an Action invocation is

an equivalent to a method call of any high-level pro-

gramming language. The actions deﬁnition is similar

to a method signature description, embedded into a

ActionManager, which will be equivalent to an inter-

face of a high-level programming language. To fully

implement the important actions, it would require for

the experts a deep knowledge on programming skills

as well as speciﬁc-language information.

Table 1 gives the set of CloudMPL elements,

organised into Statement, Time, Location and Con-

straint. The statements deﬁne the blocks of the lan-

guage in terms of the main elements for expressing

the policies. The Time and Location operators deﬁne

conditions for time and location. The Constraint con-

ditions can be applied to ordinals or status informa-

tion for basic comparison.

3.2 CloudMPL Syntax

The syntax of CloudMPL expressions are deﬁned

by the grammar in Figure 5. Manageable resources

are described by the Create Resource statement, de-

ﬁned by an ID and their respective properties. The

ActionManager requires an ID and at least one ac-

tion(method) to be deﬁned. Policies are identiﬁed

by an ID and composed of CloudMPL operators. As

showed in Table 1 CloudMPL has Location, Time and

Constraint operators, that can be combined using log-

ical operator such as AND,OR,NOT and parenthesis.

If the speciﬁed conditions are satisﬁed an action that

belong to an ActionManager should be invoked.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

454

Figure 4: CloudMPL meta-model.

<CLOUDMPL> ::= <RESOURCE> {<RESOURCE>}

{<ACTIONMANAGER>}

{<CREATE RESOURCE>}

<POLICY> {<POLICY>}

<RESOURCE> ::= DEFINE RESOURCE <ID> AS

<PROPERTY> {<PROPERTY>}

<ACTIONMANAGER> ::= DEFINE ACTIONMANAGER <ID>

<ACTION> {<ACTION>}

<ACTION> ::= ACTION <ID><PARAMETERLIST>

<POLICY> ::= POLICY <ID>

IF <CONDITIONS>

THEN <ACTION INVOCATION>

{<ACTION INVOCATION>)}

Figure 5: A simpliﬁed EBNF grammar for CloudMPL.

The following steps are required for applying

CloudMPL:

• Step 01: Modelling the resources that are going

to be managed and used to describe the policies.

• Step 02: Deﬁnition of the possible actions used

in case a policy condition is true. The Actions are

created by deﬁning an ActionManager element.

• Step 03: Writing the policies using the operators

and the syntax for the CloudMPL language. Each

policy should be identiﬁed by a valid ID.

In order to illustrate the usage of CloudMPL,

consider the following policy:

• Policy1: if the violation percentage rate is less

than 20% in Host1 and the energy consumption

is above than 2000 kwph in Host1 then it is neces-

sary to migrate the contents of Host1 to Host3 or

Host2

1 DEFINE RESOURCE H ost AS

2 BEGIN

3 V i o l a t i o n _ Percentage AS N u mber

4 E n e r g y _ Consumption AS N umber

5 END

6 DEFINE ACTIONMANAGER M a n ager AS

7 BEGIN

8 ACTION M i g r a t e _ A lternative_Host Host o rigin ,

9 Hos t a l t e r n ativeA , Hos t al t e r n a tiveB

10 END

11 CREATE hos t1 , ho st2 , ho s t3 AS H ost

12 POLICY p o l icy1

13 IF (( h o st1 . V i o l a t i o n _ P e r c e n t a g e FEW_AS 2 0)

AN D ( h ost1 . E n e r g y _ C o n s u mption M A NY_A S

200 0 ) ) TH EN

14 Mana g e r . M i g r a t e _ A l t e r native_Host h ost1 ,

ho st2 , ho s t3

Figure 6: CloudMPL representation for the given policy.

Using CloudMPL grammar deﬁned in Figure 5,

Figure 6 presents Policy written in CloudMPL.

First it is necessary to create a resource called

Host (lines 1 to 5) which describes a computer host

in a private Cloud infrastructure. Considering the

given policy the manager is interested in monitoring

the energy consumption and the rate of violation(error

rate). As stated in the policy deﬁnition the action

that needs to be done if the conditions are met is to

migrate contents of Host1 to Host2 or Host3. This

action in CloudMPL is embedded in an ActionMan-

ager, called Manager, which has a single method

Migrate Alternative Host (lines 6 to 10). Consider-

ing that the policy requires the usage of three host,

it is necessary to create them (line 11). Finally the

policy itself (lines 12 to 14) is deﬁned in terms of

the resources and properties, using Constraint oper-

ators. The CloudMPL language was implemented us-

ing XText(Xtext, 2014) and the current implementa-

tion is available for download at http://www.dimap.

ufrn.br/splmonitoring/adaptmcloud/index.php

CloudMPL:ADomainSpecificLanguageforDescribingManagementPoliciesforanAutonomicCloudInfrastructure

455

Table 1: CloudMPL Operators and Elements for Describing

Management Policies.

CloudMPL Operators & State-

ments

Description

Statements:

DEFINE RESOURCE id AS

BEGIN

property AS type

END

Declares a Resource, by spec-

ifying its ID and properties

DEFINE ACTIONMANAGER id

BEGIN

ACTION id,parameters

END

Declares an ActionManager if

a set of actions. Each action is

declared with a ID and a set of

parameters

CREATE id as resource Creates a Resource with the

given ID

POLICY id

IF conditions THEN actions

Declares a policy with the

given ID and starts the policy

conditions deﬁnition, followed

by a action(s) call(s).

Time Operators:

resource.time AFTER threshold Checks if the property of Time

type is after the given thresh-

old

resource.time BEFORE threshold Checks if the property of Time

type is before the given thresh-

old

resource.time BETWEEN

threshold

Checks if the property of Time

type is in the speciﬁed interval.

Location Operator:

resource.location IN location Checks if a given Resource is

in the speciﬁed location.

Constraint Operators:

resource.property FEW AS value Checks if the ordinal repre-

sentation for a property is less

than a given value

resource.property MANY AS

value

Checks if the ordinal represen-

tation for a property is greater

than a given value

resource.property IS status Checks if the a given property

is within one of the following

status: HIGH, NORMAL or

LOW

4 THE SPECIFICATION OF

MANAGEMENT POLICIES IN

RULE LANGUAGE

Management policies expressed in CloudMPL can be

directly mapped to executable management policies

by designing mapping rules between two languages.

To produce such policies, any CloudMPL policy is

encoded as a special form of production rules (more

information about the productions rules can be found

in (REWERSE, 2012)). These production rules fol-

Table 2: The syntax for conditional expressions for a man-

agement policy.

Expression <property:> <operator:> <value expr:>

Constraints-1: monitorable prams Comparison DataTerm

Constraints-2: monitorable pram

status

Level Speciﬁ-

cation

DataTerm

SelectTargetHost: id or name TargetHost Se-

lection

DataTerm

TargetHost

Location:

location Location DataTerm

TargetHostTime: current time status Time ObjectTerm

low a deﬁned speciﬁcation for formulating both con-

dition and action parts in Rule Language which can be

applied to either Drools(JBossCommunity, 2011) or

JRules (IBM-ILOG, 2007). In this work, we brieﬂy

discuss the speciﬁcation for formulating conditions

and action parts for a policy in an executable rule

language. The speciﬁcation includes the meta-model

for conditions, the classiﬁcation for operators used in

conditions and the types of actions used by a man-

agement policy. Both CloudMPL and rule language

speciﬁcation will be used for designing a translator

from CloudMPL to Drools or JRules in future.

4.1 Conditions Meta-model for a Policy

Conditions for a management policy can be expressed

through the meta-model presented in Figure 7 which

is inspired from URML meta-model (REWERSE,

2012). This meta-model is resulted from our classi-

ﬁcation for general rules used for management pur-

poses in Cloud.

In Figure 7, a single condition in a management

policy is a boolean expression which can be com-

posed with other conditions by using composition

operators. From URML rule meta-model (REW-

ERSE, 2012), we extracted some elements for mod-

elling various conditions. These elements are Term,

DataTerm, ObjectTerm, uml property, and Object

Variable (REWERSE, 2012).

In Figure 7, the conditional expression are clas-

siﬁed into ﬁve types. Each expression in the condi-

tion meta-model uses a property. The property are

extracted from Target Host that is running in a Cloud-

platform. In addition, each expression also has a

value expr which might be of the following types:

Data Term, Object Term, or uml property. Further-

more, suitable operators are grouped to match each

conditional expression type. The operators are pre-

sented in Figure 8. Thus, by using both Figure 7 and

Figure 8, each conditional expression and its syntax

are explained as follows:

1. ConstraintsExpr: a comparative condition used

to compare monitorable parameters against a

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

456

Figure 7: The meta-model for conditions of a management policy in Rule Language (Drools and JRules).

speciﬁed threshold value or to specify sta-

tus of monitorable parameters. Examples for

monitorable parameters are CPU Usage, Viola-

tion Percentage and Energy Consumption. Con-

straintsExpr has two different syntaxes, which are

presented in Table 2.

2. SelectTargetHostExpr: an identiﬁcation expres-

sion, which is used to select a targeted host. This

expression is necessary to be included in a man-

agement policy. The expression syntax is shown

in Table 2.

3. AssignVariableExpr: a selection expression,

which is to get values from some properties

and to assign them to an object variable. This

expression can be used in a management policy

for extracting variables which are required by

management APIs. The expression is optional

to be included in the policy. The syntax for the

expression is different from the syntax for other

expressions which is as follows:

< operator : Assignment$ >< property :

Ob jectVariable >< operator : Assignment :><

property : Ob jectTerm >

4. TargetHostLocationExpr: a location based ex-

pression, which is used to specify a geographi-

cal location of a target host. Since a physical

Cloud host can be located at any location around

the world, the policy meta-model should allow an

option for such a restriction. This expression is

an optional in the policy based on the require-

ment. The syntax for the expression is shown

in Table 2 where its Data Term can be either of

String type or GeoLocation which is Enumera-

tion type. An example for TargetHostLocation is

location == GeoLocation.Asia.

5. TargetHostTimeExpr: a time based expression

that speciﬁes the time status at a target host. Any

target host in Cloud-platform has some operations

to deal with time expression.

These operations are IsTimeBetween(<

Time Begin >, < Time End >), IsTime-

Less(< Time Literal >), and IsTime-

Above(< Time Literal >). The syntax for

the time based expression is presented in Table 2.

The following expression is a simple expression

for checking time status:

current time status== IsTimeBetween(16.00,23.00)

4.2 Policy Action Description

The action of a management policy in a rule language

is expressed as action expressions. These action

expressions can be either expressions for assigning

values or expression for invocation actions. To

simplify the transformation process for future, we

only use invocation actions expression from the

rule language which is denoted as InvocationAc-

tionExprin (REWERSE, 2012). In any management

Figure 8: The possible common rule language operators

families for expressing a management policy.

CloudMPL:ADomainSpecificLanguageforDescribingManagementPoliciesforanAutonomicCloudInfrastructure

457

Table 3: Operations used by Cloud Manager instance in a

management policy described in Drools.

< OperationName > < Parameters : Type >

Migrate Original: TargetHost

MigrateAlternativeHosts Original: TargetHost , Destina-

tion1:TargetHost, Destination2: TargetHost

MigrateToLocation Original: TargetHost , LocationName: String

ReportingNoMigration Original: TargetHost

Calculate Original:TargetHost

policy, the invocation action expressions include

calls for management APIs/Operations speciﬁed in

Cloud manager. The syntax used for expressing

InvocationActionExpr is:

CloudManager.Operation Name(parameters);

In this syntax, CloudManager represents the in-

stance of a Cloud manager which has a number of

management operations. Each deﬁned operations for

CloudManager instance has a number of parame-

ters which are necessary for migration of virtual ma-

chines, reporting information and calculating service

at the target host side in Cloud-platform. Table3

shows each deﬁned operation and its related param-

eters.

5 THE TRANSFORMATION

FROM CloudMPL TO DROOLS

After presenting CloudMPL language for express-

ing management policies at the description level and

the speciﬁcation for formulating such policies at

the implementation level, the transformation between

CloudMPL and Drools is proposed. The objective is

to build the foundation for automatically generating

an executable management policy from the descrip-

tion level.

The transformation process requires to have a con-

ceptual mapping from CloudMPL to Drools Lan-

guage. Therefore, designing a set of mapping rules

from CloudMPL to Drools for both conditions and

actions parts is necessary. To design these mapping

rules, we used CloudMPL meta-model as well as its

syntax and Drools speciﬁcation mentioned in Section

4. Firstly, the mapping step starts by presenting the

Table 4: Mapping generic syntax and keywords for a policy

in CloudMPL to Drools.

CloudMPL Generic Syntax Drools Generic Syntax

POLICY < ID > → rule < ID >

IF → when

< CONDITIONS > < Host(Conditions) >

THEN

< ACT ION INV OCAT ION >

→ then < Actions >

{< ACT ION INV OCAT ION >} end

Table 5: Mapping CloudMPL conditions to Drools condi-

tions using Table 1 in Section 3 and Table 2 in Section 4.

CloudMPL Expression Drools Expression

<attribute:TIME> TargetHostTimeExpr

AFTER <value:threshold>

<attribute:TIME> TargetHostTimeExpr

BEFORE <value:threshold>

<attribute:TIME> BETWEEN TargetHostTimeExpr

< value: threshold a > TO

<value:threshold b>

IN <value:ID> SelectTargetHostExpr +

<value:location> TargetHostLocationExpr

<attribute:monitorable> FEW AS ConstraintsExpr-1

| MANY AS <value:threshold>

<attribute:monitorable>IS <value:status> ConstraintsExpr-2

mapping for the general syntax for a management pol-

icy and keywords in both CloudMPL and Drools.

Table4 shows the mapping of generic syntax and

special keywords from CloudMPL to Drools. It is no-

ticeable from the generic syntax in Table4 that any

statement between IF and THEN is mapped as Con-

ditions in Drools which it should be enclosed with

Target operator mentioned in Figure 8. Furthermore,

any statement after THEN is mapped as Actions in

Drools. The mapping of both conditions and actions

requires more explanation which will be appeared in

the following subsections.

5.1 Mapping Conditions

In CloudMPL, a condition block consists of one

or more condition. Therefore, any condition in

CloudMPL can be structured as an attribute, an op-

erator and a value. The attribute in CloudMPL is usu-

ally written before CloudMPL operator. Usually, the

value is after CloudMPL operator. Thus, the mapping

for conditions is shown in Table 5 which applies the

following mapping rules:

1. The dot operator < . > in CloudMPL is mapped

as ’==’ operator and <value:ID or Name> is

mapped as <value expr: DataTerm>.

2. After operator is mapped as ’==’ combined with

<ObjectTerm:IsTimeAbove> in Drools.

3. Before is mapped as ’==’ combined with

<ObjectTerm:IsTimeLess> in Drools.

4. BETWEEN,TO operator is mapped as ’==’ com-

bined with <ObjectTerm: IsTimeBetween>.

5. < value: threshold > is mapped as

<Time Literal> parameter for both IsTime-

Above and IsTimeLess in Drools.

6. < value: threshold a > and <value:threshold b>

are mapped as <Time Literal Begin> and

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

458

<Time Literal End> parameters for IsTimeBe-

tween in Drools.

7. <attribute:Time> is mapped as <property: cur-

rent time status>.

8. IN is mapped as ’==’ operator and

<value:location> is mapped as <value expr:

DataTerm> which can be either String or

Enumeration.

9. FEW AS or MANY AS are mapped as Comparison

operators.

10. <attribute:monitorable> is mapped as

<property: monitoriable parms> and <value:

threshold> is mapped as DataTerm.

11. IS operator is mapped as ’==’ operator and

<value:status> is mapped as <DataTerm:

Status>.

12. <attribute:monitorable> in IS expression is

mapped as <property: monitoriable Parms

status>.

13. AND and OR is mapped as && and || operators in

Drools receptively.

To elaborate the mapping of policy condition, we

provide a sample of conditions which are written in

both CloudMPL and Drools in Figure 9. These con-

ditions are for expressing a management policy ex-

tracted from Energy Management Running Exam-

ple presented in Section 6. In Figure 9, the ﬁrst

statement is CloudMPL expression for three condi-

tions, which are Violation Percentage FEW AS 20,

Energy Consumption MORE AS 2000, host1. These

conditions are composed in CloudMPL by AND op-

erator. The same ﬁgure also includes conditions ex-

pressed in Drools which map CloudMPL conditions.

In Figure 9, the arrows represent the types of the map-

ping rules that can be applied.

5.2 Mapping Actions

In CloudMPL, any action statement is mapped as a

call method for management operations in a policy

expressed in Drools. The mapping rules for actions

are:

Figure 9: Using mapping rules for mapping CloudMPL

condition block to Drools condition part for a policy.

Figure 10: Using mapping rules for mapping CloudMPL

action block to Drools action part for a policy.

1. Action < ID > in CloudMPL is mapped as the

Name of the operation in CloudManager (See Fig-

ure 10).

2. The parameters List, which includes a set of Pa-

rameter Expression, is mapped as the operation

parameters in CloudManager.

3. In CloudMPL, Parameter Expression consists of

< TypeID >. Type is mapped as either <

Ob jectTerm > or < getOb jectRe f > in Opera-

tion. Whilst ID is the mapped as the name of the

parameter.

4. In CloudMPL , if Type is Host and it is the ﬁrst

parameter in the statement, then it is mapped as

the Original and its type is TargetHost in Drools.

5. In CloudMPL, if Type is Host and is not the ﬁrst

parameter, then it is mapped as either to Destina-

tion1 or Destination2 based on ordering parame-

ters in Drools.

Figure 10 illustrates applying the mapping rules

for action from CloudMPL to Drools. The ﬁgure in-

cludes an operation deﬁned in Table3. The operation

has three parameters which are Host1, Host2, Host3.

In Drools mapping, Action ID is mapped as Mi-

grate Alternative Host. Whilst the ﬁrst parameter is

mapped as $host1. Both Host2 and Host3 are mapped

as $host1.getHost2() and $host1.getHost3(), respec-

tively.

The previously mentioned mapping rules for both

conditions and actions parts will be used to design

an interpreter to automatically or semi-automatically

generate Drools codes for policies that would be ex-

ecuted into the architecture shown in Figure 1. The

Drools code generation will be a future step.

Figure 11: An UML class diagram for Cloud infrastructure

used in the case study.

CloudMPL:ADomainSpecificLanguageforDescribingManagementPoliciesforanAutonomicCloudInfrastructure

459

(a) CloudMPL Declarations (b) CloudMPL Expressions 1

Figure 12: A sample of CloudMPL (XText) for management policies used in the case study.

6 CloudMPL IN PRACTICE

CloudMPL is used as a language for expressing a

number of management policies extracted from Man-

agement Energy Consumption Case Study presented

in (Alansari and Bordbar, 2013). The Manage-

ment Energy Consumption Case Study implemented

in OpenNebula(Toraldo, 2012) which is a Cloud-

platform management system. In the case study, there

are a set of management policies which are enforced

in Drools rule-engine which periodically responses to

changes in three monitored parameters. The param-

eters are average CPU usage for running VMs, Vio-

lation Rate and Average Energy Consumption for pri-

vate hosts per hour. The engine automatically controls

the migration action for running virtual machines de-

ployed on three private physical hosts. The hosts runs

Ubuntu OS and KVM as virtualization environment.

The policies should trigger a migration action for run-

ning virtual machines and may switch off idle hosts.

The policies which are provided in the case study are

written in Drools Rule Language (Alansari and Bor-

dbar, 2013)). Figure 11 presents the UML model for

the Cloud-infrastructure for the used example.

In Figure 11, the Cloud infrastructure consists

of three main components, which are Host, VM

images and SLA classes. The Host class runs

a number of virtual machines and has a number

of monitorable attributes such as CPU Usage, En-

ergy Consumption,etc.). Furthermore, Host class has

a time and also a location attribute, which represents

the geographical location for the host. Each running

virtual machine in the model belongs to only one

Cloud consumer. Thus, each running VM instance

is associated with only one SLA and also has a life

cycle ( For more details about Figure 11 see (Alansari

and Bordbar, 2014)).

We took some management policies encoded

into Drools and we used CloudMPL to write them.

Both CloudMPL Declarations and CloudMPL Poli-

cies for the case study, which are implemented using

XText(Xtext, 2014), are shown in Figure 12.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

460

Looking at Figure 12, there are six policies ex-

pressed in CloudMPL which demonstrate the usage

of all operators suggested by the language. Policy 1 is

constraints and it requires to use monitorable param-

eters and uses the CloudMPL operators FEW AS and

MANY AS. Whilst policy 2, policy 3 and policy 4 are

composed of both time and constraints expressions.

Both policy 2 and policy 4 use the operator After

whereas policy 3 includes the ClodMPL time operator

Between / To. The constraints operator used in these

policies is IS. Policy 5 has only a single time expres-

sion which uses the CloudMPL time operator Before.

The ﬁnal policy, which is policy 6, contains a loca-

tion expression besides the time and constraints con-

ditions. The location condition uses the CloudMPL

operator IN.

6.1 The Interpretation of CloudMPL

Policies to Drools

We applied the mapping process introduced in Sec-

tion 5 to the policies of the case study. Using the

designed mapping rules explained in Section 5 and

the meta-model presented in Figure 11, Drools codes

are generated manually. The purpose is to test the

mapping rules. A sample of Drools code for policy

1, policy 3, policy 5 and policy 6 are shown in Figure

13 which are depicted into two groups. The impor-

tant Drools operators used in the conditions are high-

lighted in Blue.

Taking policy 3 as an example, this policy is

mapped as a combination of Time and Constraints 2

Expressions which are shown in management policies

conditions meta-model mentioned in Section 4. The

mapping for the condition part applies the rules num-

ber 1, 4, 6, 7,11, 12 and 13 explained in Mapping

Conditions at Section 5. On the other hand, all the

rules proposed for mapping the action part expressed

in Section 5 are applied. As a result, policy 3 will have

a rule code similar to what is illustrated in Figure 13.

This method is applied to all remaining CloudMPL

policies captured in Figure 12.

7 CONCLUSION

This paper aims at reducing the existing gap be-

tween the speciﬁcation of management policies for

Cloud and the implementation of policies via rule-

engines. We presented CloudMPL that is a domain-

speciﬁc language for specifying management poli-

cies for Cloud-environments. Furthermore, we de-

scribed a method of automating the creation of var-

ious CloudMPL expressions to an executable Rule

(a) Drools Rules ”Group 1”

(b) Drools Rules ”Group 2”

Figure 13: The generated Drools rules from CloudMPL

policies.

Language such as Drools. CloudMPL establishes a

set of operators that deal with several kinds of con-

straints, from ordinal, ranging trough time and lo-

cations constraints, that can be applied to a spe-

ciﬁc or a set of Cloud resources. In addition,

CloudMPL supports user-deﬁned actions to deal with

the consequences of conditions speciﬁed by the man-

agers of Cloud computing infrastructure. The us-

age of both CloudMPL and the automated approach,

which is based on designing mapping rules between

CloudMPL and Drools, is illustrated with the help of

an example related to management energy consump-

tion by migrating virtual machines.

It is also important to highlight that, even with-

out the transformation process fully implemented, the

suggesting method for automating policy creation as-

sists to cope with frequent changes in policies spec-

iﬁed at the description level. Using both CloudMPL

and the automated process for creation management

policies can decrease the amount of time that requires

to spend in implementing such policies. Due to the

closeness of CloudMPL to natural languages and its

declarative nature, it is easier for non-technical people

to make a use of the language for specifying policies.

As a future step, it is imperative to fully implement

the transformation process and also to build an inte-

grated environment that supporting the speciﬁcation,

translation and deployment of the policies.

CloudMPL:ADomainSpecificLanguageforDescribingManagementPoliciesforanAutonomicCloudInfrastructure

461

REFERENCES

Alansari, M. and Bordbar, B. (2014). Modelling and analy-

sis of migration policies for autonomic management

of energy consumption in cloud via petri-nets. In

Proceedings of the The International Conference on

Cloud and Autonomic Computing. IEEE.

Alansari, M. M. and Bordbar, B. (2013). An architectural

framework for enforcing energy management policies

in cloud. 2013 IEEE Sixth International Conference

on Cloud Computing, 0:717–724.

Beloglazov, A. and Buyya, R. (2010). Adaptive threshold-

based approach for energy-efﬁcient consolidation of

virtual machines in cloud data centers. In Proceedings

of the 8th International Workshop on Middleware for

Grids, Clouds and e-Science. ACM.

Borgetto, D., Maurer, M., Da-Costa, G., Pierson, J.-M.,

and Brandic, I. (2012). Energy-efﬁcient and sla-aware

management of iaas clouds. In Proceedings of the

3rd International Conference on Future Energy Sys-

tems: Where Energy, Computing and Communication

Meet, e-Energy ’12, pages 25:1–25:10, New York,

NY, USA. ACM.

Brandtzæg, E., Mohagheghi, P., and Mosser, S. (2012). To-

wards a domain-speciﬁc language to deploy applica-

tions in the clouds. In Cloud Computing 2012, The

Third International Conference on Cloud Computing,

GRIDs, and Virtualization, pages 213–218.

Bunch, C., Chohan, N., Krintz, C., and Shams, K. (2011).

Neptune: A domain speciﬁc language for deploy-

ing hpc software on cloud platforms. In Proceed-

ings of the 2Nd International Workshop on Scientiﬁc

Cloud Computing, ScienceCloud ’11, pages 59–68,

New York, NY, USA. ACM.

Cunha, M., Mendonca, N., and Sampaio, A. (2013). A

declarative environment for automatic performance

evaluation in iaas clouds. In Cloud Computing

(CLOUD), 2013 IEEE Sixth International Conference

on, pages 285–292.

Forgy, C. L. (1982). Rete : A fast algorithm for the many

patternimany object pattern match problem. Artiﬁcial

Intelligence, 19:17–37.

IBM-ILOG (2007). Ilog jrules techincal.

http://logic.stanford.edu/poem/externalpapers/iRules/

WP-JRules50Strengths.pdf.

JBossCommunity (2011). Drools tools reference guide.

Maurer, M., Brandic, I., and Sakellariou, R. (2013). Adap-

tive resource conﬁguration for cloud infrastructure

management. Future Generation Computer Systems,

29(2):472 – 487.

Mernik, M., Heering, J., and Sloane, A. M. (2005). When

and how to develop domain-speciﬁc languages. ACM

Comput. Surv., 37(4):316–344.

Mi, H., Wang, H., Yin, G., Zhou, Y., Shi, D., and Yuan, L.

(2010). Online self-reconﬁguration with performance

guarantee for energy-efﬁcient large-scale cloud com-

puting data centers. In IEEE International Conference

on Services Computing, pages 514–521. Ieee.

REWERSE (2012). Uml-based rule modeling language.

http://oxygen.informatik.tu-cottbus.de/rewerse-

i1/?q=URML.

Toraldo, G. (2012). OpenNebula 3 Cloud Computing.

PACKT Publishing, Birmingham B3.

Whittle, J., Sawyer, P., Bencomo, N., Cheng, B. H., and

Bruel, J.-M. (2010). Relax: a language to address

uncertainty in self-adaptive systems requirement. Re-

quirements Engineering, 15(2):177–196.

Xtext (2014). Xtext textual domain-speciﬁc language (dsl).

http://www.eclipse.org/Xtext/.

CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience

462