vieslaf framework: enabling adaptive and versatile sla-management

VieSLAF Framework: Enabling Adaptive

and Versatile SLA-Management

Ivona Brandic, Dejan Music, Philipp Leitner, and Schahram Dustdar

Distributed Systems Group, Institute of Information SystemsVienna University of Technology, Vienna, Austria

{ivona,dejan,leitner,dustdar}@infosys.tuwien.ac.at

Abstract. Novel computing paradigms like Grid and Cloud computingdemand guarantees on non-functional requirements such as applicationexecution time or price. Such requirements are usually negotiated follow-ing a specific Quality of Service (QoS) model and are expressed using Ser-vice Level Agreements (SLAs). Currently available QoS models assumeeither that service provider and consumer have matching SLA templatesand common understanding of the negotiated terms or provide publictemplates, which can be downloaded and utilized by the end users. Onthe one hand, matching SLA templates represent an unrealistic assump-tion in systems where service consumer and provider meet dynamicallyand on demand. On the other hand, handling of public templates seemsto be a rather challenging issue, especially if the templates do not re-flect users’ needs. In this paper we present VieSLAF, a novel frameworkfor the specification and management of SLA mappings. Using VieSLAFusers may specify, manage, and apply SLA mapping bridging the gap be-tween non-matching SLA templates. Moreover, based on the predefinedlearning functions and considering accumulated SLA mappings, domainspecific public SLA templates can be derived reflecting users’ needs.

1 Introduction

Nowadays, well established and traditional resource sharing models are shiftedtowards novel market-oriented models revolutionizing existing Grid and HighPerformance Computing (HPC) concepts [8]. In market-oriented resource shar-ing models users discover resources on demand and pay for the usage of thespecific resources. In turn they expect that besides requested functional require-ments, non-functional requirements of the application execution are also fulfilled[1,19,12]. Non-functional requirements comprise application execution time, re-liability, availability, and similar issues. Non-functional requirements are termedas Quality of Service (QoS) and are expressed and negotiated by means of Ser-vice Level Agreements (SLAs). SLA templates represent empty SLA documentsi.e., SLA documents, with all required elements like parties, SLA parameters,metrics, and objectives, but without QoS values [9].

A large body of work deals with SLA based QoS negotiation and integra-tion of QoS concepts into Grid management tools [10,17]. However, most of the

J. Altmann, R. Buyya, and O.F. Rana (Eds.): GECON 2009, LNCS 5745, pp. 60–73, 2009.c© Springer-Verlag Berlin Heidelberg 2009

VieSLAF Framework: Enabling Adaptive and Versatile SLA-Management 61

existing work relies either on inflexible QoS models assuming that the communi-cation partners have matching SLA templates or provide public SLA templates,which can be downloaded and utilized on the users’ system. On the one hand,matching SLA templates limit QoS negotiation only between partners whereQoS relationship is already established off-line, or to partners who belong to aparticular Grid portal [1]. On the other hand, publicly available SLA templatesusually do not reflect users’ needs. Thus, in order to increase QoS versatility,flexible QoS models are necessary where negotiation is possible even betweenservices which do not have matching SLA templates. The problems with non-matching templates can be exemplified on a very simple example with differingterms of contract on both sides. The term price may be defined as usage priceor service price, etc., leading to inconsistencies during the negotiation process.Another example of not matching templates are SLA templates which slightlydiffer in their structure.

In this paper we approach the gap between existing QoS methods and novelcomputing paradigms like Cloud Computing by proposing VieSLAF, a frame-work for the management of SLA mappings. Thereby, mappings are defined byXSLT1 documents where inconsistent parts of one document are mapped to an-other document e.g, from the consumer’s template to the provider’s template.Moreover, based on SLA mappings and deployed taxonomies we eliminate seman-tic inconsistencies between consumer’s and provider’s templates. The purpose ofthe submitted SLA mappings is twofold: (1) using VieSLAF users may discoverservices on demand, define mappings to available templates, if necessary andfinally start the negotiation with selected services. Therefore, the negotiation isnot only limited to services belonging to a special portal or where a relation-ship is already established off-line; (2) based on VieSLAF ’s predefined learningfunctions and accumulated SLA mappings we facilitate user driven definition ofpublic SLA templates.

Based on a case study the presented SLA mapping architecture has beensuccessfully used to manage SLA mappings in context of a Grid workflow man-agement tool [4] and adaptable Cloud services [6]. Additionally to [4,6] where wepresented the general approach for SLA mappings, in this paper we present (1)the VieSLAF architecture in detail with modules for the measurement of SLAparameters, (2) implementation details of the VieSLAF framework; and (3) firstexperimental results.

The main contributions of this paper are: (1) description of the scenariosfor the definition of SLA mapping documents; (2) definition of the VieSLAFarchitecture used for the semi-automatic management of SLA mappings (3)demonstration of learning functions, which can be used to obtain realistic publictemplates and (4) evaluation of the VieSLAF architecture using an experimentaltestbed.

The rest of this paper is organized as follows: Section 2 presents the relatedwork. In Section 3 we present our SLA mapping approach. In particular wediscuss the management of SLA mappings, SLA transformations, and an example

1 XSL Transformations (XSLT) Version 1.0, http://www.w3.org/TR/xslt.html

62 I. Brandic et al.

SLA mapping document. Section 4 presents the VieSLAF architecture includingthe used semantic model, methods for SLA mappings and transformations, usedregistries and features for the SLA monitoring and adaptation of SLA templates.In Section 5 we discuss our first experimental results. Section 6 concludes thispaper and describes the future work.

2 Related Work

Currently, a large body of work exists in the area of Grid service negotiationand SLA-based QoS. Most of the related work can be classified into the follow-ing three categories: (1) adaptive SLA mechanisms based on OWL, DAML-Sand other semantic technologies [17,10,23]; (2) SLA based QoS systems, whichconsider varying service requirements but do not consider non matching SLAtemplates [1,20]; and (3) systems relying on the principles of autonomic com-puting [3,14,15].

Work presented in [18] discusses the incorporation of SLA-based resourcebrokering into existing Grid systems. Oldham et al. describe a framework forsemantic matching of SLAs based on WSDL-S and OWL [17]. Dobson at al.present a unified quality of service (QoS) ontology applicable to the main sce-narios identified such as QoS-based Web services selection, QoS monitoring andQoS adaptation [10]. Zhou et al. survey the current research on QoS and ser-vice discovery, including ontologies such as OWL-S and DAML-S. Thereafter,an ontology is proposed, DAML-QoS, which provides detailed QoS informationin a DAML format [23]. Hung et al. propose an independent declarative XMLlanguage called WS-Negotiation for Web services providers and requestors. WS-Negotiation contains three parts: negotiation message, which describes the for-mat for messages exchanged among negotiation parties, negotiation protocol,which describes the mechanism and rules that negotiation parties should fol-low, and negotiation decision making, which is an internal and private decisionprocess based on a cost-benefit model or other strategies [13].

Work presented in [1] extends the service abstraction in the Open Grid Ser-vices Architecture (OGSA) for QoS properties focusing on the application layer.Thereby, a given service may indicate the QoS properties it can offer or it maysearch for other services based on specified QoS properties.

Quan et al. discuss the process of mapping a light communication workflowwithin an SLA context with different kinds of sub-jobs and resources [16]. Danet al. present a framework for providing customers of Web services differenti-ated levels of service through the use of automated management and SLAs [9].Ardagana et al. present an autonomic grid architectures with mechanisms todynamically re-configure service center infrastructures, which is basically ex-ploited to fulfill varying QoS requirements [3]. Koller et al. discuss autonomousQoS management using a proxy-like approach. The implementation is based onWS-Agreement [21]. Thereby, SLAs can be exploited to define certain QoS pa-rameters that a service has to maintain during its interaction with a specificcustomer [14]. Konig at al. investigate the trust issue in electronic negotiations,


dealing with how to trust a potential transaction partner and how to choosesuch partners based on their past behavior [15].

However, to the best of our knowledge none of the discussed approaches dealswith user-driven and semi-automatic definition of SLA mappings enabling nego-tiations between inconsistent SLA templates. Moreover, none of the presentedapproaches facilitates user driven definition of publicly available SLA templates.

3 The SLA Mapping Approach

In the presented approach each SLA template has to be published into a registrywhere negotiation partners i.e., provider and consumer, can find each other. Themanagement of SLA mappings and published services is presented in Section 3.1.The transformations between remote and local SLA templates are discussed in Sec-tion 3.2. Finally, an example SLA mapping document is presented in Section 3.3.

3.1 Management of SLA Mappings

Figure 1(a) depicts the architecture for the management of SLA mappings andparticipating parties. The registry comprises different SLA templates wherebyeach of them represents a specific application domain e.g., SLA templates forthe medical, telco or life science domain. Thus, each service provider may assignhis/her service to a particular template (see step 1 in Figure 1(a)) and afterwardsassign SLA mappings, if necessary (see step 2). Each template a may have nservices assigned. Available templates can be browsed using an appropriate GUI.

Service consumers may search for the services using meta-data and searchterms (step 3). After finding appropriate services each service consumer maydefine mappings to the associated template (step 4). Thereafter, the negotiationbetween service consumer and service provider may start as described in the nextsection. SLA mappings should be defined in a dynamic way. Thus, SLA templatescan be updated frequently to reflect the actual SLAs used by service providesand consumers based on predefined adaptation rules (step 5). The adaptabilityfunctionality facilitates the generation of user driven public SLA templates.

- Service 1

- Service 2

- Service 3

- ...

- Service n

Service Registry

- Service 1

- Service 2

- Service 3

- ...

- Service n

Template a:

- Service 1

- Service 2

- Service 3

- ...

- Service n

ServiceConsumer

ServiceProvider

3. <

<se

arch

ser

vice

s>>

4. <

<as

sign

map

ping

s>>

1. <

<as

sign

ser

vice

s to

cat

egor

y>>

2. <

<as

sign

map

ping

s>>

5. <<template adaptation>>

(a)

localWSLAtemplate

Rulefromlocal toremote

XSL-Transfor-mations

+remoteWSLATemplate

XSL-Transfor-mations

Rulefromremoteto local

+

(b)

Fig. 1. Management of SLA-Mappings (a) QoS basic scenario (b)


Currently, SLA mappings are defined on an XML level, where users defineXSL transformations. A UML based GUI for the management of SLA-mappingsis under development [4].

3.2 SLA-Mappings Transformations

Figure 1(b) depicts a scenario for defining XSL transformations. As the SLAspecification language we use Web Service Level Agreements (WSLA)s [22]. Wealso developed first bootstrapping strategies for communication across differentSLA specification languages [5].

WSLA templates are publicly available and published in a searchable reg-istry. Each participant may download already published WSLA templates andcompare it in a semi-automated or automated way with the local template. Ifthere are any inconsistencies discovered, the service consumer may write rules(XSL transformation) from his/her local WSLA template to the remote tem-plate. The rules can also be written by using appropriate visualization tools, forexample using a GUI as depicted in Figure 3. Thereafter, the rules are storedin the database and can be applied during the runtime to the remote WSLAtemplate. Since during the negotiation process transformations are done in twodirections, the transformations from the remote WSLA template to the localWSLA template are necessary as well.

As depicted in Figure 1(b), a service consumer is generating a WSLA. The lo-cally generated WSLA plus the rules defining transformations from local WSLAto remote WSLA deliver a WSLA which is compliant to the remote WSLA. Inthe second case the remote WSLA template has to be translated into the lo-cal one. In that case the remote WSLA plus the rules defining transformationsfrom the remote to local WSLA deliver a WSLA which is compliant to the localWSLA. Thus, the negotiation may be done between non-matching WSLAs inboth directions: from service consumer to service provider and vice versa.

The service provider can define rules for XSL transformations in the same wayas depicted in Figure 1(b) from the publicly published WSLA templates to thelocal WSLA templates. Thus, both parties, provider and consumer, may matchon a publicly available WSLA template.

3.3 SLA-Mappings Document (SMD)

Figure 2 shows a sample rule for XSL transformations where price defined inEuros is transformed to an equivalent price in US Dollars. Please note that forthe case of simplicity we use a relatively simple example. Using XSLT morecomplicated mappings can also be defined. Explanation of this is out of scope ofthis paper.

As shown in Figure 2, the Euro metric is mapped to the Dollar metric. In thisexample we define the mapping rule returning Dollars by using the Times functionof WSLA Specification (see line 5). The Times function multiplies two operands:the first operand is the Dollar amount as selected in line 12, the second operand


1. ...2. <xsl:template ...>3. <xsl:element name="Function" ...>4. <xsl:attribute name="type">5. <xsl:text>Times</xsl:text>6. </xsl:attribute>7. <xsl:attribute name="resultType">8. <xsl:text>double</xsl:text>9. </xsl:attribute>10. <xsl:element name="Operand" ...>11. <xsl:copy>12. <xsl:copy-of select="@*|node()"/>13. </xsl:copy>14. </xsl:element>15. <xsl:element name="Operand" ...>16. <xsl:element name="FloatScalar" ...>17. <xsl:text>1.27559</xsl:text>18. </xsl:element>19. </xsl:element>20. </xsl:element>21.</xsl:template>22. ...

Fig. 2. Example XSL Transformation

is the Dollar/Euro quote (1.27559) as specified in line 17. The dollar/euro quotecan be retrieved by a Web service and is usually not hard coded.

With similar mapping rules users can map simple syntax values (values ofsome attributes etc.), but they can even define complex semantic mappings withconsiderable logic. Thus, even syntactically and semantically different SLA tem-plates can be translated into each other.

4 VieSLAF Framework

In this section we present the architecture used for the semi-automated manage-ment of SLA mappings and generation of public SLA templates. We discuss asample architectural case study exemplifying the usage of VieSLAF. Thereafter,we describe each VieSLAF ’s core component in detail.

4.1 VieSLAF Architecture

The VieSLAF framework enables application developers to efficiently developadaptable service-oriented applications simplifying the handling with numerousWeb service specifications. The framework facilitates management of QoS modelsas for example management of meta-negotiations and SLA mappings [7]. Basedon the VieSLAF framework service providers may easily manage QoS modelsand SLA templates and frequently check whether selected services satisfy de-veloper’s needs e.g., specified QoS-parameters in SLAs. Furthermore, we discussbasic ideas about the adaptation of SLA templates needed for the generation ofrealistic public SLA templates.


Adaptationrules for SLA

templates

Remote

SLA

template

Meta Negotiaiton Middleware (MNM)Meta Negotiaiton

Middleware (MNM)Meta Negotiaiton

Middleware (MNM) SLA Mapping

MiddlewareSLA Mapping Middleware

Sample Serviceprovider specific

middleware

Client,consumer specific

middleware

WSDL

(2)

API......

Remote

SLA

template

Data Model

Local SLA

template

Local SLA

template

Remote

SLA

template

(4)

Trans-

formation

rules:

XSLT,

XPath

Trans-

formation

rules:

XSLT,

XPath

Trans-

formation

Rules:

XSLT,

XPath

Trans-

formation

Rules:

XSLT,

XPath

Sevice 1Thread1_param1Thread2_param2

Threadn_paramn...

Sevice 2

Thread1_param1Thread2_param2

Threadn_paramn...

(8)

(1)

Cloud of measurement services

meta

negotiatio

n document

meta

negotiatio

n document

Remote

SLA

template

(1)

Knowledge Base

Adaptation

Monitoring

Sample Consumer

Sample Provider

Registry

DB

DB

(3)

(6)

(9)

(5)

(7)

Fig. 3. VieSLAF Architecture

We describe the VieSLAF components based on Figure 3. As shown in step(1) in Figure 3 users may access the registry using a GUI, browse through exist-ing templates using the SLA mapping middleware. In the next step (2) serviceproviders specify SLA mappings using the SLA mapping middleware and submitthem to the registry. Thereafter, in step (3) service consumers may define theirown SLA mappings to the remote templates and submit them to the registry.SLA mapping middleware on both sides (provider’s and consumer’s) facilitatesthe management of SLA mappings. Submitted SLA mappings are parsed andmapped to a predefined data model (step 4). Thereafter, service negotiation maystart (step 5). During the negotiation SLA mappings and XSLT transformationsare applied (step 6). After the negotiation, the invocation of the service methodsmay start (step 7). SLA parameters are monitored using the monitoring service(step 8). Based on the submitted SLA mapping publicly available SLA templatesare adapted reflecting the majority of local SLA templates (step 9).

4.2 VieSLAF Components

As shown in Figure 3 the major VieSLAF components are the knowledge base,components for monitoring and adaptation and the SLA middleware used byservice provider and consumer.

Knowledge Base. As shown in Figure 3 the knowledge base is responsiblefor storing SLA templates and SLA mapping documents. For storing of SLAtemplate documents we implemented registries representing searchable repos-itories. Currently we have implemented a MS-SQL 2008 database with a Web


service front end that provides the interface for the management of SLA map-pings. To handle scalability issues we intend to host the registries using a cloudof databases hosted on a service provider such as Google App Engine [11] orAmazon EC2 [2]. SLA templates are stored in a canonical form enabling com-parison of XML documents. The registry methods are implemented as WindowsCommunication Foundation (WCF) services and can be accessed only with ap-propriate access rights. The database is manipulated based on the role-model.We define three roles: service consumer, service provider and registry adminis-trator. Service consumers are able to search suitable services for the selectedservice categories e.g., by using the method findServices. Service consumers mayalso create SLA-mappings using the method createAttributeMapping. Serviceproviders may publish their services and bind it to a specific template categoryusing the method createService.

Sample Provider and Sample Consumer. A sample provider and a sampleconsumer are shown in the lower part of Figure 3. Basically, a service con-sumer/provider consists of a client/service based middleware, SLA mappingmiddleware facilitating the access to registries, and a GUI used for browsingremote templates.

SLA Mapping Middleware. As already mentioned SLA mapping middleware isbased on different WCF services. For the sake of brevity, in the following we dis-cuss just a few of them. The RegistryAdministrationService provides methods forthe manipulation of the database where administrator rights are required e.g.,creation of template categories. Another example represents the WSLAMap-pingService, which is used for the management of SLA mappings by serviceconsumer and service provider. WSLAQueryingService is used to query the SLAmapping database. The database can be queried based on template categories,SLA attributes and similar attributes. Other implemented WCF service are, forexample, services for SLA parsing, XSL transformations, and SLA validation.

Service consumers may search for appropriate services through WSLAQuery-ingService and define appropriate SLA-mappings by using the method createAt-tributeMapping. Each query request is checked at runtime, if the service consumerhas also specified any SLA-mappings for SLAElements and SLAAttributes spec-ified in category’s SLA-Template. SLA transformations are applied before therequests of the service consumers can be completely checked. The rules necessaryfor the transformations of attributes and elements can be found in the databaseand can be applied using the consumer’s WSLA-Template. Thereafter, the con-sumer’s template is completely translated into a category’s WSLA-Template.Transformations are done by WSLATransformator implemented with the .NET3.5 technology and using LINQ2.

Monitoring Service. As depicted in Figure 3, we implemented a lightweightconcept for the monitoring of SLA parameters for all services published in a

2 Language Integrated Query.


specific template category. The aim of the monitoring service is to frequentlycheck the status of the SLA parameters of an SLA agreement and deliver theinformation to the service consumer and/or provider. Furthermore, the monitor-ing service monitors values of SLA parameters as specified in the SLA-Templateof the published services. Monitoring starts after publishing a service in a cate-gory and is provided through the whole lifetime of the service. The monitoringservice is implemented as an internal registry service, similar to other servicesfor parsing, transformation, and validation, that we have already explained inprevious sections. In the following we describe how the monitoring process canbe started i.e., all the steps necessary to setup monitoring.

After the publishing of the service and SLA mappings, SLAs are parsed andit is identified which SLA parameters have to be monitored and how. We distin-guish between periodically measured SLA parameters and the parameters whichare measured on request. The values of the periodically measured parametersare stored in the so-called parameter-pool. The monitoring service provides twomethods: a knock-in method for starting the monitoring and a method for re-ceiving the measured SLA parameters from the measurement pool. Whenever auser requests monitoring information of the particular SLA (i) SLAs parametersare requested from the parameter-pool in case of periodically measured parame-ters or (ii) SLA parameters are immediately measured as defined in the parsedand validated SLAs in case of on-request parameters.

Adaptation Service. Remote SLA templates should not be defined in a staticway, they should reflect provider’s and consumer’s needs. Thus, we implementeda first prototype of an internal registry’s adaptation service, which can be used byconsumers and providers as shown in Figure 3 in order to derive realistic publicSLA templates. Users can specify SLAParameters which should be added intoSLA-Template or choose some SLAParameters which they do not need and wantto delete.

Each ParameterWish (add/delete) is saved as an XML chunk that containsall SLAParameters with metrics which should be added/deleted from a specificSLA-Template. Registry administrators have to configure a learning capabilityproperty for each template category. The property defines how many requests fora specific ParameterWish have to be defined in order to add/delete Parameter-Wish to/from an SLA-Template. Whenever a new ParameterWish is accepteda new revision category of an SLA template is generated. All services and con-sumers who voted for that specific wish are automatically re-published to thenew revision. Also all SLA mappings are automatically assigned to the new tem-plate revision. Old SLA mappings of the consumers and services are deleted andalso all old background threads used for calculation for old SLA template areaborted. The newly generated SLA template is thereafter parsed and new back-ground monitoring threads are created and started for each service. Thus, basedon the presented adaptation approach public templates can be derived in a userdriven way reflecting the majority of local templates.


5 Evaluation

In this section we evaluate the VieSLAF framework. In Section 5.1 we measurethe overhead produced by SLA mappings compared to Web service invocationwithout mappings. We describe the experimental testbed and the setup used.Thereafter, we discuss the experimental results. In Section 5.2 we discuss stresstests with the varying number of concurrently invoked SLA mappings. In Section5.3 we present results with the varying number of SLA mappings per single Webservice invocation.

Database

Windows Server 2008SP 1

S1 S10...

SLA Mapping Middelware

VieSLAFClient

Registry

Administrator Role

Registry administration

Service invocation

Mapping, Parsing

VieSLAF

Fig. 4. VieSLAF Testbed

5.1 Overhead Test

In order to test the VieSLAF framework we developed a testbed as shown inFigure 4. As a client machine we used an Acer Aspire Laptop, Intel Core 2 DuoT5600 1.83 GHz, 2 MB L2 Cache 1GB RAM. For hosting of 10 sample services,calculator services with 5 methods, we used a single core Xenon 3.2Ghz, 2MBL1 cache, 4GB RAM Sun blade machine. We use the same machine to hostVieSLAF s WCF services. The aim of our evaluation is to measure the overheadproduced using VieSLAF ’s WSLAQueryingService for search and SLA mappingsof the appropriate services.

We created 10 services (S1,..., S10) and 10 accounts for service providers.We also created the registry administrator’s role, which manages the creation oftemplate categories with the corresponding SLA templates. The SLA templaterepresents a remote calculator service with five methods: Add, Subtract, Multiply,Divide and Max. Both, the provider and the consumers define five SLAMappings,which have to be used during the runtime. We specify three simple, syntacticmappings where we only change the name of an element or attribute. The othertwo mappings consider also semantic mappings, where we map between struc-turally different SLA templates.

Table 1 shows the experimental results. The measured values represent thearithmetic mean of 20 service invocations. The overhead measured during theexperimental results includes the time needed for validation of WSLA documents(column Validation in Table 1), the time necessary to perform SLA-mappingsfrom the local consumers to the remote SLA templates (column Consumer Map-ping) and the time necessary to transform the remote SLA templates to the local


Table 1. SLA Mappings Overhead Compared to Simple Web Service Invocation (With-out SLA Mappings)

Service Search Time Total

SLA-Mapping Remaining Time

Validation Consumer Mapping Provider Mapping

Time in sec 0.046 0.183 0.151 1.009 1.389

Time [%] 3.32 13.17 10.87 72.64 100.00

providers (column Provider Mapping). Furthermore, we measured the remain-ing time necessary to perform a search. The remaining time includes the roundtrip time for a search including data transfer between the client and the serviceand vise versa. As shown in Table 1 the time necessary to handle SLA mappings(V alidation+ConsumerMapping+ProviderMapping) represents 0.38 secondsor 27, 36% of the overall search time.

Please note that the intention of the presented experimental results is theproof of concept of the SLA mapping approach. We did not test the scalabilityissues, since we intend to employ computing Clouds like Google App Engine [11]or Amazon EC2 [2] in order to cope with the scalability issues.

5.2 Stress Tests

In this Section we describe tests on how the VieSLAF middleware copes withthe multiple SLA mappings executed concurrently with differing complexity.Evaluation is done on an Acer Aspire Laptop, Intel Core 2 Duo T5600 1.83GHz, 2 MB L2 Cache, 1GB RAM. For the evaluation we have used two differentSLA mappings:

– Simple: Invocation of the simple SLA mappings, an example is translationof one attribute to another attribute e.g., usage price to price.

– Complex: Represents the invocation of the complex SLA mappings, as forexample semantic mappings considering two structurally different SLA tem-plates.

We tested VieSLAF with different versions of XSLT transformers, namely withXSLTCompiledTransform, .Net version 3.0 and with the obsolete XSLTTrans-form Class from .Net 1.1. Figure 5(a) shows the measurements with the XSLT-CompiledTransform Transformer and with the XSLTTransform Class. The xaxis depicts the number of SLA mappings performed concurrently i.e., numberof runs. The y axis depicts the measured time for the execution of SLA mappingsin seconds.

Considering the measurement results we can observe that the XSLTTransformClass is faster than the XSLTCompiledTransform Transformer from the newer.Net version. Complex mappings executed with the XSLTTransform Class al-most overlap with the simple mappings executed with the XSLTCompiledTrans-form. We can observe that in both cases, simple and complex mapping, the


0.01

0.1

1

10

5x 10x 15x 20x 25x 50x 100x 500x 1000x

Simple XSLTCompiledTransform ComplexXSLTCompiledTransform Simple XSLTTransform ComplexXSLTTransform

(a) (b)

Fig. 5. Stress Tests with XSLTCompiledTransform Transformer and XSLTTransformClass (a) Measurements with varying number of SLA mappings per Web Service In-vocation (b)

performance starts to significantly decrease with the number of SLA mappings> 100. If the number of mappings < 100, the execution time is about or lessthan 1 second.

5.3 Multiple SLA Mapping Tests

In this section we discuss performance results measured during a Web service callwith varying numbers of SLA mappings per service. We measured 5, 10, 15 and20 SLA mappings per Web service call. In order to create a realistic testbed weused SLA mappings which depend on each other: e.g., attribute A is transformedto attribute B, B is transformed to C, C to D, and so on. Thus, we simulatethe worst case, where SLA mappings can not be performed concurrently, theyhave to be performed sequentially.

Evaluation is done on an Acer Aspire Laptop, Intel Core 2 Duo T5600 1.83GHz, 2 MB L2 Cache, 1GB RAM. Figure 5(b) shows measured results. The xaxis depicts the number of SLA mappings performed concurrently or sequentiallyconsidering attribute dependencies. The y axis depicts the measured time for theexecution of SLA mappings in milliseconds. We executed SLA mappings betweenthe remote template and the provider’s template (i.e., provider mappings asdescribed in Table 1) before the runtime, because these mappings are knownbefore consumer requests. Thus, only mappings between the consumer’s templateand the remote template are done during the runtime as indicated with the SLAMapping line. The line SLA Mapping + Client invocation comprises the timefor the invocation of a Web service method including SLA mapping time. TheSLA Mapping + Client invocation line does not comprise round-trip time, itcomprises only the request time.

We can conclude that even with the increasing number of SLA mappings andconsidering the worst case scenario with sequentially performed mappings theSLA mapping time represents about 20% of the overall execution time.


6 Conclusion and Future Work

In this paper we presented the VieSLAF framework used for the managementof SLA mappings. SLA mappings are necessary in service oriented Grids andcomputational Clouds where service consumer and provider usually do not havematching SLA templates. Thus, based on SLA mappings even those partnerswith slightly different templates may negotiate with each other and increasethe number of potential negotiation partners. We have demonstrated how Gridservice users (provider and consumer) may search for appropriate services, defineSLA mappings, if necessary, and finally start service negotiation and execution.Using VieSLAF users can even monitor SLA parameters during the executionof the service calls. Thereafter, we presented how the SLA mappings and thepredefined learning functions can be used to adapt SLA templates. Adaptabilityfunctions facilitate generation of user driven public SLA templates. Finally, wediscussed our first proof of concept based on the experimental results.

In the future we plan to extend our work on adaptable Cloud services andtest our approach with real life applications.

Acknowledgments

The work described in this paper was partially supported by the European Com-munity’s Seventh Framework Programme [FP7/2007-2013] under grant agree-ment 215483 (S-Cube) and by the Vienna Science and Technology Fund (WWTF)under grant agreement ICT08-018 Foundations of Self-governing ICT Infrastruc-tures (FoSII).

References

1. Al-Ali, R.J., Rana, O.F., Walker, D.W., Jha, S., Sohail, S.: G-qosm: Grid servicediscovery using qos properties. Computing and Informatics 21, 363–382 (2002)

2. Amazon Elastic Compute Cloud (Amazon EC2), http://aws.amazon.com/ec2/3. Ardagna, D., Giunta, G., Ingraffia, N., Mirandola, R., Pernici, B.: QoS-driven web

services selection in autonomic grid environments. In: Meersman, R., Tari, Z. (eds.)OTM 2006. LNCS, vol. 4276, pp. 1273–1289. Springer, Heidelberg (2006)

4. Brandic, I., Music, D., Dustdar, S., Venugopal, S., Buyya, R.: Advanced QoS Meth-ods for Grid Workflows Based on Meta-Negotiations and SLA-Mappings. In: The3rd Workshop on Workflows in Support of Large-Scale Science. In conjunction withSupercomputing 2008, Austin, TX, USA, November 17 (2008)

5. Brandic, I., Music, D., Dustdar, S.: Service Mediation and Negotiation Boot-strapping as First Achievements Towards Self-adaptable Grid and Cloud Services.In: Grids meet Autonomic Computing Workshop 2009 - GMAC 2009. In conjunc-tion with the 6th International Conference on Autonomic Computing and Com-munications Barcelona, Spain, June 15-19 (2009)

6. Brandic, I.: Towards Self-manageable Cloud Services. In: The Second IEEE Inter-national Workshop on Real-Time Service-Oriented Architecture and Applications(RTSOAA 2009). In conjunction with the 33rd Annual IEEE International Com-puter Software and Applications Conference, Seattle, Washington, USA, July 20-24(2009)

http://aws.amazon.com/ec2/


7. Brandic, I., Venugopal, S., Mattess, M., Buyya, R.: Towards a Meta-NegotiationArchitecture for SLA-Aware Grid Services. In: Workshop on Service-Oriented En-gineering and Optimizations 2008. In conjunction with International Conferenceon High Performance Computing 2008 (HiPC 2008), Bangalore, India, December17 - 20 (2008)

8. Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I.: Cloud Computingand Emerging IT Platforms: Vision, Hype, and Reality for Delivering Computingas the 5th Utility. Future Generation Computer Systems 25(6), 599–616 (2009)

9. Dan, A., Davis, D., Kearney, R., Keller, A., King, R., Kuebler, D., Ludwig,H., Polan, M., Spreitzer, M., Youssef, A.: Web services on demand: WSLA-drivenautomated management. IBM Systems Journal 43(1) (2004)

10. Dobson, G., Sanchez-Macian, A.: Towards Unified QoS/SLA Ontologies. In: Pro-ceedings of the 2006 IEEE Services Computing Workshops (SCW 2006), Chicago,Illinois, USA, September 18-22 (2006)

11. Google App Engine, http://code.google.com/appengine12. Foundations of Self-Governing ICT Infrastructures (FoSII) Project,

http://www.wwtf.at/projects/research_projects/details/index.php?

PKEY=972_DE_O

13. Hung, P.C.K., Haifei, L., Jun-Jang, J.: WS-Negotiation: an overview of researchissues. In: Proceedings of the 37th Annual Hawaii International Conference onSystem Sciences, Big Island, Hawaii, January 5-8 (2004)

14. Koller, B., Schubert, L.: Towards autonomous SLA management using a proxy-likeapproach. Multiagent Grid Syst. 3(3) (2007)

15. Konig, S., Hudert, S., Eymann, T., Paolucci, M.: Towards reputation enhanced elec-tronic negotiations for service oriented computing. In: Falcone, R., Barber, S.K.,Sabater-Mir, J., Singh, M.P. (eds.) Trust 2008. LNCS, vol. 5396, pp. 273–291.Springer, Heidelberg (2008)

16. Quan, D.M., Altmann, J.: Resource allocation algorithm for light communicationgrid-based workflows within an SLA context. International Journal of Parallel,Emergent and Distributed Systems (IJPEDS) 24(1), 31–48 (2009)

17. Oldham, N., Verma, K., Sheth, A.P., Hakimpour, F.: Semantic WS-agreementpartner selection. In: Proceedings of the 15th international conference on WorldWide Web, WWW 2006, Edinburgh, Scotland, UK, May 23-26 (2006)

18. Ouelhadj, D., Garibaldi, J.M., MacLaren, J., Sakellariou, R., Krishnakumar, K.T.:A multi-agent infrastructure and a service level agreement negotiation protocol forrobust scheduling in grid computing. In: Sloot, P.M.A., Hoekstra, A.G., Priol, T.,Reinefeld, A., Bubak, M. (eds.) EGC 2005. LNCS, vol. 3470, pp. 651–660. Springer,Heidelberg (2005)

19. Venugopal, S., Buyya, R., Winton, L.: A Grid Service Broker for Schedulinge-Science Applications on Global Data Grids. In: Concurrency and Computation:Practice and Experience, vol. 18(6), pp. 685–699. Wiley Press, New York (2006)

20. Walker, D.W., Huang, L., Rana, O.F., Huang, Y.: Dynamic service selection inworkflows using performance data. Scientific Programming 15(4), 235–247 (2007)

21. Web Services Agreement Specification (WS-Agreement),http://www.ogf.org/documents/GFD.107.pdf

22. Web Service Level Agreement (WSLA),http://www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf

23. Zhou, C., Chia, L.T., Lee, B.S.: Semantics in service discovery and QoS measure-ment. IT Professional 7(2), 29–34 (2005)

http://code.google.com/appengine

http://www.wwtf.at/projects/research_projects/details/index.php?PKEY=972_DE_O

http://www.wwtf.at/projects/research_projects/details/index.php?PKEY=972_DE_O

http://www.ogf.org/documents/GFD.107.pdf

http://www.research.ibm.com/wsla/WSLASpecV1-20030128.pdf

vieslaf framework: enabling adaptive and versatile sla-management

Documents