COMPUTING SCIENCE Mapping WSLA on Reward Constructs in Möbius R. Yassin Kassab, A. van Moorsel. TECHNICAL REPORT SERIES No. CS-TR-1106 June, 2008

TECHNICAL REPORT SERIES No. CS-TR-1106 June, 2008 Mapping WSLA on Reward Constructs in Möbius Rouaa Yassin Kassab, Aad van Moorsel Abstract This paper provides an outline for generating Möbius reward constructs and a partial Stochastic Activity Network model from an existing Web Service Level Agreement (WSLA) document of a web service system. This is done by parsing the WSLA document to group its ‘Service Level Agreement parameter elements’ with their corresponding ‘metric elements’ using the Document Object Model parser. These groups then are represented by matching Stochastic Activity Network representations and reward C++ statements that can be integrated in the Möbius framework. Using this approach, service providers can visualize their system performance and predict SLA values by solving the produced model. © 2008 University of Newcastle upon Tyne. Printed and published by the University of Newcastle upon Tyne, Computing Science, Claremont Tower, Claremont Road, Newcastle upon Tyne, NE1 7RU, England.

Bibliographical details YASSIN KASSAB, R., VAN MOORSEL, A. Mapping WSLA on Reward Constructs in Möbius [By] R. Yassin Kassab, A. van Moorsel. Newcastle upon Tyne: University of Newcastle upon Tyne: Computing Science, 2008. (University of Newcastle upon Tyne, Computing Science, Technical Report Series, No. CS-TR-1106) Added entries UNIVERSITY OF NEWCASTLE UPON TYNE Computing Science. Technical Report Series. CS-TR-1106 Abstract This paper provides an outline for generating Möbius reward constructs and a partial Stochastic Activity Network model from an existing Web Service Level Agreement (WSLA) document of a web service system. This is done by parsing the WSLA document to group its ‘Service Level Agreement parameter elements’ with their corresponding ‘metric elements’ using the Document Object Model parser. These groups then are represented by matching Stochastic Activity Network representations and reward C++ statements that can be integrated in the Möbius framework. Using this approach, service providers can visualize their system performance and predict SLA values by solving the produced model. About the author Rouaa Yassin Kassab works towards her PhD under supervision of Aad van Moorsel in the School of Computing Science, Newcastle University. Her research is in the area of business-driven system management based on quantitative models. Aad van Moorsel joined the University of Newcastle in 2004. He worked in industry from 1996 until 2003, first as a researcher at Bell Labs/Lucent Technologies in Murray Hill and then as a research manager at Hewlett-Packard Labs in Palo Alto, both in the United States. Aad got his PhD in computer science from Universiteit Twente in The Netherlands (1993) and has a Masters in mathematics from Universiteit Leiden, also in The Netherlands. After finishing his PhD he was a postdoc at the University of Illinois at Urbana-Champaign, Illinois, USA, for two years. Aad has worked in a variety of areas, from performance modelling to systems management, web services and grid computing. In his last position in industry, he was responsible for HP's research in web and grid services, and worked on the software strategy of the company. His research agenda is in the area of self-managing systems, with a focus on the enterprise. The goal is to establish objective, quantitative methods to improve IT-related decision making, eventually fully automated. This involves mathematical modelling and algorithms as well as service-oriented software implementations. DTI, EPSRC and EU-funded collaborations are ongoing with Hewlett-Packard, Merrill-Lynch, Warwick, Bath, UCL, various universities throughout Europe, and the Business School in Newcastle. Suggested keywords SLAPARAMETER, MEASUREMENTDIRECTIVE, REWARDS

Mapping WSLA on Reward Constructs in Möbius

Rouaa Yassin Kassab Aad van Moorsel Rouaa.yassin-kassab@ncl.ac.uk Aad.vanmoorsel@ncl.ac.uk

School of Computing Science, University of Newcastle upon Tyne, UK

Abstract

This paper provides an outline for generating Möbius reward constructs and a partial Stochastic Activity Network model from an existing Web Service Level Agreement (WSLA) document of a web service system. This is done by parsing the WSLA document to group its ‘Service Level Agreement parameter elements’ with their corresponding ‘metric elements’ using the Document Object Model parser. These groups then are represented by matching Stochastic Activity Network representations and reward C++ statements that can be integrated in the Möbius framework. Using this approach, service providers can visualize their system performance and predict SLA values by solving the produced model.

1. Introduction The rapidly increasing popularity of the service provider paradigm raises the necessity to define clear relationships between service providers and their potential customers regarding the offered Quality of Service (QoS) (like response time, availability, etc) [1,2]. Service Level Agreements (SLA) set the rules of this relationship and specify additional information such as the penalties that should be paid in case of the contract breaching [3]. To specify the different service levels, specification languages such as Web Service Level Agreement language (WSLA) [4] have been developed. WSLA is based on XML [5] and is used to describe SLA parameters of a web service and the way to compute their values [6]. If SLAs are not met, the provider typically pays a penalty [7]. Therefore, it is of interest to model and predict if systems meet SLAs.

As far as we know, there is no special modelling tool that provides a model for a system given its SLA. Therefore in this paper, we develop a way to create this model from a given WSLA document using the Möbius framework components [8]. This is done by using the Document Object Model parser (XML DOM) [9] to examine the WSLA document and group each SLA parameter with the elements that compute its value. It is worth mentioning that we have found that it is not possible to map SLA elements to the Möbius reward constructs only. This is caused by dependence between WSLA elements and the inability to store a set of the reward values generated over an interval of time. Therefore, we represent each element in the parameter group

1

with either a set of Stochastic Activity Network (SAN) primitives or a set of C++ statements of the Möbius reward model function, or a combination of these two.

This paper is organized as follows. In Section 2, we provide the background of the WSLA language and the Möbius modelling tool. The problem we address is then described in Section 3. A solution is proposed and discussed using a running example in Section 4. Finally, the conclusion is drawn and future work is pointed out. 2. Background

2.1. WSLA Language

The primary role of the WSLA language is to formalize service level agreements in order

to automate the configuration of the service provision system and the QoS monitoring system [4]. To achieve this, the WSLA specification contains three important constructs:

- Parties: describes the players that are involved in the SLA contract. - Service Definition: contains a comprehensive definition of SLA parameters and how to

use metrics to compute their values. Each metric will be measured from a source by identifying a measurement directive. In the case of a composite metric, its value will be accumulated using a function (that takes other metrics or constants as its operands). We are particularly interested in this part because it contains the SLA parameter descriptions.

- Obligations: includes Service Level Objectives which are the agreed values of SLA parameters in a specified duration, and what action should be taken in the case of contract violation.

WSLA language rules are designed to be thin. However, to cover the complexity of real

systems, WSLA allows one to create new types which express domain specific SLA concepts [4]. In this paper, we limit our attention to the WSLA core, which provide the most important requirements for the system providers, and its standard extensions functions and measurement directives. We do not consider constructs that could be extended according to the domain specific needs (like using different measurement directives and functions depending on Web Service Definition Language defined operation) [4]. Furthermore, in the WSLA Metric definition, we depend on measurement directive and functions to compute the metric values. We ignore both the measurement directive variable element and the MetricURI element which define the location from which metric value can be taken directly. 2.2. Möbius

The Möbius tool is used in modelling the performance of a wide range of computing systems [8]. It is a framework that comprises multiple modelling formalisms (SAN, Bucket and Balls, PEPA, Fault tree) and multiple solution methods (simulation, numerical solvers), and many of its methods are independent and can be used in combination with each other [8]. To measure the performance attributes of a given system using Möbius, we should [8]:

2

- Build an atomic model that depicts all the relevant system states (using tokens in the simple or extended places). State changes occur by actions (timed or instantaneous activities) which fire according to a distribution rate (deterministic, exponential, etc). Input/Output Gates can also be defined to represent the enabling predicate of an activity or the marking change of a place.

- Create the composite model if necessary (when the atomic model is a part of a larger model).

- Define the rewards from which metrics will be computed. There are two kinds of rewards; rate rewards represent the time spent in each state (place) and impulse rewards count activity completions. Each reward variable has a reward function that computes its value, and time type that specifies when the reward function should be evaluated.

- Solve the model by using either simulation or numerical solvers. 3. Problem Description

In Figure 1, we graphically depict the problem we tackle. It indicates a web service with an SLA specified by a Web Service Level Agreement document. Independently, this web service is modelled using Stochastic Activity Networks in the Möbius framework. Rewards are defined on this model using the reward structures in Möbius.

Let us assume that we only have the WSLA document for a given service. The objective of our work is to automatically generate a complete reward definition in Möbius and the part of the SAN model (places and activities) that will be needed to accomplish the reward description. Black arrows in Figure 1 indicate the problem we address.

It is important to note that it is not possible to model SLA parameters into Möbius just using rewards. We therefore also map WSLA partly on a SAN, essentially to model additional reward constructs. This is for two reasons:

1- Möbius does not accept to use the value of a reward variable (that is generated by

solving the model) as an input to another reward variable in the same model. This means that reward variables in the same model in Möbius cannot depend on each other. However, in WSLA, the value of SLA parameter depends on the value of a metric that may depend on another metric and so on. To work around this, we use a SAN model, which represents a part of the required metric, to be used in the computation of SLA parameters.

2- There is no ability to store a set of reward values during a period of time in Möbius. However, in the computation of most SLAs, WSLA depends on a set of metric values that is taken through a defined period of time or series of events. Therefore, we use extended places in SAN, allowing us to store values according to the firing of an activity.

In WSLA, as we mentioned before, an SLA parameter depend on metrics to compute its

value [4]. These metrics could be either resource metrics, which use a measurement directive to measure its value, or composite metrics, which depend on the value of other resource metrics through a specified function [4]. Therefore, we first provide the mapping for resource metrics.

3

Web Service Computing

System

WSLA document contain the service description (SLA)

Rewards defined in Möbius Reward

Editor

Service Model using Möbius SAN editor (Places, activities)

Figure 1: problem description

Every SLA should at least depend on a metric that uses the measurement directive. That is because if SLA parameter depends on only one metric, it should be a resource metric. To illustrate this further, see the example in Figure 2, which was taken from the IBM WSLA language specification [4]. It specifies an SLA which reflects the rate of an operation invocation. The value of this SLA is derived by computing the difference between the last two measures of the invocation values which are taken on an hourly basis.

<Schedule name="hourlyschedule"> <Period> <Start>2001-11-30T14:00:00.000-05:00</Start> <End>2001-12-31T14:00:00.000-05:00</End> </Period> <Interval> <Minutes>60</Minutes> </Interval> </Schedule> <SLAParameter name="TransactionRate" type="float" unit="transactions/hour"> <Metric>Transactions</Metric> <Communication> <Source>ACMEProvider</Source> <Pull>ZAuditing</Pull> <Push>ZAuditing</Push> </Communication> </SLAParameter> <Metric name="Transactions" type="long" unit="transactions"> <Source>ACMEProvider</Source> <Function xsi:type="Minus" resultType="double"> <Operand> <Function xsi:type="TSSelect" resultType="long"> <Operand> <Metric>SumTransactionTimeSeries</Metric> </Operand> <Element>0</Element> </Function> </Operand> <Operand> <Function xsi:type="TSSelect" resultType="long"> <Operand> <Metric>SumTransactionTimeSeries</Metric> </Operand>

4

<Element>-1</Element> </Function> </Operand> </Function> </Metric> <Metric name="SumTransactionTimeSeries" type="TS" unit="transactions"> <Source>ACMEProvider</Source> <Function xsi:type="TSConstructor" resultType="TS"> <Schedule>hourlyschedule</Schedule> <Metric>SumTransactions</Metric> <Window>2</Window> </Function> </Metric> <Metric name="SumTransactions" type="long" unit="tansactions"> <Source>ACMEProvider</Source> <MeasurementDirective xsi:type="InvocationCount" resultType="long"/> </Metric>

Figure 2: WSLA example

This example computes the value of the SLA parameter TransactionRate depending on the use of the resource metric SumTransactions, and the composite metrics SumTransactionTimeSeries and Transactions. The value of the metric SumTransactions should be produced first by using the measurement directive InvocationCount. The result then will be input to the function TSConstructor to compute the value of the SumTransactionTimeSeries metric. After that, the last two values of the previous metric will be derived by the use of two copies of the function TSSelect in the third metric Transactions. Finally, these values are used as the operands of the function Minus in the same metric to produce its final value. This will be used then to generate the value of the SLA parameter. 4. Solution The following steps establish the mapping from WSLA on Möbius rewards:

1. We start by grouping each SLA parameter that appears in the WSLA document with the metrics that compute its value.

2. For each group, we work from the metric that contains the measurement directive element up to the SLA parameter element (passing through metrics that use function elements to compute their values).

3. After mapping each SLA element, Measurement directive element and function element to its corresponding representation in Möbius, we will represent this in a new XML based document that can be input into Möbius.

We implemented the first step in the above approach using the Document Object Model

parser (XML DOM). The third step is beyond the scope of this paper and is future work. Here we will focus only on the second step because it is the most sophisticated phase in mapping from

5

WSLA to Möbius. For that we try to find and explain the representations for WSLA function and measurements directive elements through the running example of Figure 2 in Section 4.1 and 4.2. See the Appendix of this paper for the complete and generic solution for all WSLA elements.

4.1 Measurement Directive

A measurement Directive element is used when the value of a Metric should be measured directly from a resource by probing or instrumentation of the system [8]. There are seven types of measurement directives in the WSLA specification. We represent each of them (See Table 1 in the Appendix) through a set of places and SAN primitives in the Möbius Atomic model editor. This place then will be used as the basis to build the functions on.

Referring to Figure 2 with the WSLA example, we see that the value of the SLA parameter InvocationRate is computed using three Metrics SumTransactions, SumTransactionTimeSeries and Transactions. The first one will take the reading of the current operation’s invocation value to be stored by the second metric in an hourly schedule. The last metric then will subtract the last two values to obtain the transaction rate. Note that there is only one measurement directive InvocationCount and it is used by the last metric SumTransitions. We map this in Möbius as depicted in Figure 3, using the following SAN primitives:

- InvocationCount simple place: stores the number of operation invocations in the modelled system as the number of tokens in this place.

- Timed_Activity1: connects to the place to increase its marking according to an invocation rate.

- Input_gate1: controls the enabling of the activity and limits its firing times to not go to infinity. This is necessary in order to be able to solve the model.

Figure 3: The representation of InvocationCount element in Möbius

By the use of this representation, we could have continuous readings of the value of the

operation invocations. Thus, we could substitute the work of the SumTransition metric in WSLA example.

4.2 Functions

Function elements are used for a Metric if the Metric value is derived from the value of other metrics or constants [8]. There are eighteen types of functions used in WSLA document. Some of them will be mapped to the Möbius Atomic model editor, while the others are mapped to the reward function.

6

4.2.1 Functions that are mapped to the Atomic model editor

In WSLA, there are two functions (TSConstructor and QConstructor) which will be mapped to SAN primitives. Those functions are used to store a number of values, which are taken from another metric or function through a specific period of time, to be used by other metrics. See Table 2 in the Appendix for full details.

Recalling the example again, and moving to the next Metric, we see that the value of the SumTransition metric is used by the composite metric SumTransitionTimeSeries which use the TSConstructor function. This function will be mapped as follows (See Figure 4):

- SumTransactionTimeSeries extended place: It stores an array of values that are taken

from the metric that is specified in the <Metric> element in the TSConstructor function (the SumTransaction metric that is represented by the InvocationCount place in our example). The number of elements in the array is equal to 2, which is the value of the <window> element in the TSConstructor function.

- SumTransaction activity: The role of this activity is to specify the times that a new value will be added to the SumTransactionTimeSeries extended place. This is done by using a deterministic firing rate equal to the value that was given in the Interval element of the Schedule element in the TSConstructor function (60 minutes in our example).

- Output_Gate1: This is used to store each incoming value from the SumTransactions Metric in the corresponding array element in the SumTransactionTimeSeries extended place. The index of the array will start from 0 to its maximum value (array size minus one), returning the index to zero when the number of values reaches the array index maximum value.

Figure 4: The representation of TSConstructor in Möbius

Here, we could store a series of a particular size for the readings copies that was taken

from the SumTransition metric according to a predefined schedule of time. So, we could replace the use of the SumTransactionTimeSeries metric.

After joining the previous two graphs that appear in Figure 3 and Figure 4, we will have the graph that is depicted in Figure 5.

Figure 5: The produced atomic model By using this SAN graph, we could obtain the value of the number of the operation

invocations according to an hourly schedule, and retain the last two.

7

4.2.2 Functions that are mapped to the reward function coding

The remaining functions will be represented in the reward function in Möbius reward model. Since C++ is used to write the code for different Möbius components (functions, etc.)[8], all the functions’ representation (See Table 3 in the Appendix) will be encoded in C++ as well.

As Möbius reward model has a time type through which its function will be computed, the <Interval> element of the <schedule> element for each of the WSLA functions (of this type) will be mapped into this time type.

In our example, the last thing to do is to subtract the last two values that are stored in the SumTransactionTimeSeries metric.

We see that the composite metric Transactions uses the function Minus , which has two operands. These operands are the last two values of SumTransactionTimeSeries metric (represented in the SumTransactionTimeSeries extended place) that was taken through the use of the TSSelect function. The TSSelect function will be used as a part of the reward function in order to be able to choose the element with a certain index that is specified in the <element> element in the TSSelect function. The Minus function will also be included in the reward function to compute the subtraction between the two values.

Return ((SumTransactionTimeSeries->Index (1) ->Mark ()) - (SumTransactionTimeSeries->Index (0) ->Mark ()));

A Return statement is used here identical to the Möbius reward encoding.

If we put the previous representation in the Möbius tool, the following code will state the parameter values and the coding for each primitive and for the reward function.

Place Names InvocationCount SumTransactionTimeSeries

Initial Markings 0 0

Timed Activity: SumTransaction Timed_Activity1 Distribution Parameters Value:60 Rate:1

Activation Predicate (none) (none) Reactivation Predicate (none) (none)

Input Gate: Input_Gate1 Predicate InvocationCount->Mark() < 100 Function ;

Output Gate: Output_Gate1

Function

if (I < 1) { I =I+1; //where I is a global variable SumTransactionTimeSeries->Index(I)->Mark()= InvocationCount->Mark(); } else { I=0; SumTransactionTimeSeries->Index(I)->Mark()= InvocationCount->Mark();}

8

Performance Variable Model: Invo_reward Child Model Name example

Top Level Model InformationModel Type SAN Model

Performance Variable : TransactionRate Affecting Models example

Reward Function (Reward is over all Available Models) return((example->SumTransactionTimeSeries->Index(1)->Mark()) - (example->SumTransactionTimeSeries->Index(0)->Mark())); Type Steady State

Estimate Mean Include Lower Bound on Interval Estimate Include Upper Bound on Interval Estimate Estimate out of Range Probabilities

Options

Confidence Level is Relative Initial Transient 0.0

Parameters Batch Size 1.0 Confidence Level 0.95

Simulator Statistics

ConfidenceConfidence Interval 0.1

5. Conclusion

This paper provided a mapping of SLA parameter elements in WSLA on Möbius reward and atomic models. It focused mainly on finding a representation in Möbius for WSLA function and measurement directive elements. In future work we implement this in Möbius. We are also developing generalisations of this approach to map WSLA to other reward structures than those used in Möbius. References: 1. Liu, Z., M.S. Squillante, and J.L. Wolf. On Maximizing Service-Level-Agreement Profits.

in Proceedings of the 3rd ACM conference on Electronic Commerce. 2001: ACM. 2. Marilly, E., Martinot, O., Betgé-Brezetz, S., and Delègue, G., Requirement for Service

Level Agreement Management. IP Operations and Management, 2002 IEEE Workshop 2002: p. 57-62.

3. Jin, L.J, V. Machiraju, and A. Sahai, Analysis on Service Level Agreement of Web Services, in HP Labs Technical Reports. 2002, HPLaboratories.

4. Ludwig, H., Keller, A., Dan, A., King, R.P., and Franck, R. Web Service Level Agreement (WSLA) Language Specification, Version 1.0. (January 2003), IBM Corporation

9

5. W3C, XML Schema Definition Language. 6. Keller, A. and H. Ludwig, The WSLA Framework: Specifying and Monitoring Service

Level Agreements for Web Services. Journal of Network and Systems Management, March 2003. 11(1): p. 57-81.

7. Wolter, K. and A.v. Moorsel, The Relationship between Quality of Service and Business Metrics: Monitoring, Notification and Optimization, in HP Labs Technical Reports. April, 2001, HP Laboratories.

8. Sanders, W.H., Möbius User Manual, Version 2.0 draft. 2006, University of Illinois 9. W3C. Document Object Model (DOM). http://www.w3.org/DOM.

10

Appendix 1- The Measurement Directive elements representation

This appendix provides a full description for the suggested way that will be used to move from WSLA measurement directive elements into Möbius. It is worth mentioning that some care need to be taken using the mapping suggestion that appears in the tables in the Appendix 1 and Appendix 2 since we have not yet applied all of them using Möbius framework.

Measurement

Directive Description as it is taken from WSLA

specification [4]

Suggested Way to map Depict it in Atomic Model

Counter

- Used to get a counter from the instrumentation of a service or managed resource. - It is a non-negative integer that may be incremented, but not decremented. Possible maximum

values are -1 (in case of a 32-bit

integer) or -1 (if a 64-bit integer is used).

322

642

- When the counter reaches its maximum, it wraps around and starts increasing from 0 [4].

- Create a place named Counter. - An activity is connected to this place to increase the place mark when it completes according to a specific rate. - The output gate (increase) increases the marking of the place by 1 if its marking is less than 4294967295; else it let the mark equal to 0. - An input gate is connected to the activity to controls the enabling of this activity. The input predicate of the input gate is: Counter->Mark() < 4294967295

Gauge

- Used to get a gauge from the instrumentation of a service or managed resource. - It is a non-negative integer that may increase or decrease, with a maximum

value of either -1 (in case of a 32-bit

322

- Create a place named Gauge. - An activity is connected to this place to increase or decrease the place mark when it completes according to a specific rate. - The output gate (increase) increases the marking of the place by 1 if its marking is less than 4294967295; else it let the marking stuck to

11

integer) or -1 (if a 64-bit integer is used).

642

- A gauge does not roll over to zero once its maximum value is reached. Rather, the gauge remains stuck at the maximum value [4].

4294967295. - The output gate (decrease) decreases the marking of the place by 1 if its marking is more than 0; else it let the marking stuck to 0. - An input gate is connected to the activity to controls the enabling of this activity. The input predicate of the input gate is: Gauge->Mark() < 4294967295

Invocation count

- used to read the invocation count of a system. - used to derive the throughput of a system by computing the increment from one measurement to the next [4].

- Create a place named InvocationCount which reflect the number of invocations in the modeled system. - An activity is connected to this place to increase its mark when it completes according to a specific rate. - An input gate is connected to the activity to controls the enabling of this activity. This to limit the firing numbers to not go to infinity.

Status

- used to measure the status of a service (alive or not) [4].

Status request

-Request the status of service object from a measurement interface. The metric assumes the value 0 if the service object is down and one if it is up [4].

- Create a place named Status which has only one token if the system is up, and zero token if the system is down. - We will not put an activity or input gate here because we assume that the marking of this place will be changed when a condition of some other places’ marking in the model becomes true (e.g. when the CPU mark becomes zero).

Table1: Measurement Directive elements representation

It should be noted that we could not find a good representation for both Response Time and Down Time elements because they provide a value that should be produced by solving the model. This will be left to the future work.

12

2- The Function elements representation

The representation of WSLA function elements will be represented by using two tables to distinguish between the two types of mapping. Table 2 will describe the function elements that could be mapped to Möbius Atomic model editor.

Function

Description as it is taken from WSLA

specification [4]

Suggested Way to map Depict it in Atomic Model

Time Series constructor

(TSConstructor)

- This function describes the construction of a time series which is the basic element for the application of average, maximum and similar functions on other metric or other function. - This function contains a Schedule element that defines the time span when the time series is constructed and the intervals at which new values are inserted [4].

- This function will not be included in the reward function in the reward model in Möbius. Instead, it will be mapped into the atomic model editor as a combination of an extended place, an output gate and an activity. - The role of the extended place is to store an array of values of the specified metrics (in the metric element of TSConstructor in WSLA document), where the array size will be equal to the value specified in the <window> element in the TSConstructor function in WSLA document. - The role of the output gate is to store each incoming value in the corresponding array element in the extended place, and then start the index from zero when the number of values reaches the array maximum values. - The role of the timed activity is to define the time through which a new element will be added to the extended place. This is done by using a deterministic firing rate to this activity

13

Table2: The functions that are mapped to the Möbius Atomic model editor

which is equal to the value that is defined in the Interval element in the schedule element in TSConstructor in WSLA document.

Queue Constructor

(QConstructor)

- Queues are time-ordered collections of measurements. - queue entries are not measured triggered by a schedule but are events that are pushed from the instrumentation to the measurement components [4].

- This function will be mapped into the atomic model editor as a combination of an extended place, an output gate and an activity. - The role of the extended place is to store an array of values of the specified metrics (in the metric element of QConstructor in WSLA document), where the number of elements in this array will be equal to the value in the <window> element in the QConstructor function in WSLA document. - The role of the output gate is to store each incoming value in the corresponding array element in the extended place, and then start the index from zero when it reaches its maximum. - The role of the timed activity is to define the time through which a new element will be added to the extended place. This is done by using a deterministic firing rate to this activity that will be left to the programmer since there is no <Schedule> element in QConstructor .

While Table 3 will explain the function elements that could be represented in the code of

the reward editor function in Möbius.

14

Function Description as it is taken from WSLA specification

Suggested Way to map

Time Series Select

(TSSelect)

- This element is used after using TSConstuctor element to select a particular index from the time series. - 0 represents the most recent element. Negative numbers refer to elements further in the past, e.g. -1 is the one before last value [4].

- This function will be used in the reward function in order to be able to select the array element value whose index is specified in the <element> element in TSSelect from the extended place that we are used in TSConstructor function. - we used extended_place1 -> Index(value) ->Mark() To access the element of index (value) in the extended place.

Size

-The Size function computes the number of elements of a time series or queue [4].

- This function value could be taking from the <window> element in the time series or queue.

Mean - It computes the arithmetic mean of the numeric values of a time series or queue (the average) [4].

- In the reward function, we can examine each value that is stored in the extended place (of time series or queue), compute its sum, and then divided it by its size.

Mode -The Mode function computes the value that occurs most often within a set of measurements [4].

- In the reward function, we could examine each value of the extended place to see which value occur the most.

Round/Truncate

- It rounds a floating point to the precision indicated by the Digits parameter./ cuts off a float after a specified digit [4].

- We can use ceil () or floor () function in the reward function.

Sum - It adds the numeric values of a time series or queue [4].

- In the reward function, we could examine each value of the extended place to computes their sum.

Max - It returns the highest value of a time series or queue of numeric metrics [4].

- In the reward function, we could examine each value of the extended place to see the highest value.

ValueOccurs

- This function counts the number of occurrences of a particular value in a time series or queue [4].

- In the reward function, we could examine each value of the extended place to see the number of occurrence of the specified value that appears in <value> element.

Arithmetic Functions - Arithmetic functions are available in their common meaning. The operands are either metrics or functions [4].

- It mapped directly to +,-,*, / in reward function in Möbius.

PercentageGreaterThanThreshold /

PercentageLessThanThreshold

- It returns the percentage of elements of a time series or queue whose value is greater/less than a given value [4].

- In the reward function, we could examine each value of the extended place to see the percentage of elements that their value is greater/less than a threshold.

15

NumberGreaterThanThreshold /

NumberLessThanThreshold

- It returns the number of elements of a time series or queue whose value is greater/less than a given value [4].

- In the reward function, we could examine each value of the extended place to see the number of elements that their value is greater/less than a threshold.

Span - It returns the number of sequential occurrences of a particular value in a time series or queue, backwards from the most recent entry. The result is of type long [4].

- In the reward function, we could examine each value of the extended place to see the number of sequential occurrence of the value specified in the <value> element.

Table3: The functions that are mapped to the Möbius reward model

It should be noted that we could not find a good representation of the function RateOfChange. This will be left for future work.

16