Using SLA Context to Ensure Quality of Service for Composite Services Dmytro Dyachuk, Ralph Deters Department of Computer Science University of Saskatchewan
[email protected],
[email protected]
Abstract— As service-orientation is establishing itself as the dominant design and integration paradigm for large heterogeneous and open systems, the lines between wired and wireless consumers and providers begin to blur. Due to the availability of toolkits and standards it is now fairly easy to build nomadic service consumers that provide users transparent access to enterprise services. However, since nomadic consumers are typically characterized by limited computational resources, they are very dependent on reliable service providers. Unlike their more resource rich wired counterparts, that can in case of a provider slowdown or failure simply rebind to an alternative provider, the nomadic consumers lack the bandwidth to execute to do so in sufficient time. This leads to the question of how to ensure QoS for providers of nomadic consumers. Especially for composite services that aggregate other services this is still an open question. This paper presents an approach for ensuring QoS for nomadic applications that consume composite services. Using transparent proxies that are control the access to each service provider the scheduling of requests and therefore the enforcement of QoS becomes possible.
I. INTRODUCTION Within the context of service-orientation, services (atomic & composite) focus primarily on exposing functionality. However some pervasive applications such as navigation control, health monitoring, and traffic control are real-time systems that impose strict nonfunctional requirements. For instance, a car navigation application [fig. 1] can rely on a navigation service that is a mash-up of a Geographic Information System (GIS) service, meteorological data service and of course a city traffic report service. A sudden delay in the city traffic report service would introduce additional latency in the navigation service response possibly rendering it useless by failing to provide accurate information [fig. 1].
Fig 1. Behaviour of real-time nomadic applications.
To overcome this, it is necessary to establish a contract between consumer and provider that defines the functional and non-functional requirements. The last should include description of the obligations from a service side in terms of performance, availability, reliability etc. A Service Layer Agreement (SLA)[1] approach for instance can be such a contract. Generally speaking SLA represents a QoS context of nomadic application. II. SLA AWARE WORKFLOW SCHEDULING (SLAAWS) SLA Aware Workflow Scheduling (SLAAWS) method is developed to overcome the problem of irrational resource utilization in case of complex workflow topologies. More optimal resource work is archived by considering the context of each component request. The context includes the topology of a workflow, current loads on component services and QoS constraints for each composite request. SLAAWS assumes that the orchestration of services in a Composite Web Service is defined by means of a workflow language e.g. BPEL4WS[[2], WS-CDL[3]. Despite syntactical differences within different sequential workflow languages, they all support basic workflow patterns[4]. Consequently their topologies can be abstracted to obtain task interdependencies graphs. This paper focuses on the basic and most widely used patterns namely sequence, parallel split and synchronization [5]. The first step of SLAAWS consists in parsing a workflow and transforming it into a directed acyclic graph G=(V,E) that describes its task interdependencies. V represents the requests for component services and E represents the dependencies. The task i is preceding the task j if the request j depends on the response to the request i. The succeeding is opposite to the relation the preceding. For the second step an average time required for processing each request i can be noted as pi. Now the Critical Path Method can be applied in order to estimate the workflow completion time and to determine its critical components. The CPM [6] is based on the rule that the earliest start time for a request is equal to the latest completion time of its predecessors. Component’s “criticality” reflects the significance of its impact on the overall processing time. The critical elements form the Critical Path [6]. The most important property of the critical path is that its processing time is equal to the overall CWS request processing time. An implication of this property is that delays in processing
times of non critical elements will not affect the overall performance. Therefore the non critical requests can be postponed for a certain time meanwhile giving ability for more critical requests to be processed faster. Nevertheless for each noncritical request there is still an upper bound on the maximum time is can be hold. Failure to start processing a request within a specified time would result in the overall CWS processing lag. The threshold value or so called latest start time(LST) is a “due” for starting processing the requests. The time between the current and the latest start time can also referred by slack time. In order to determine the latest start time for each request in the composition we have to combine the results obtained from CPM with QoS constraints defined in corresponding SLA. This paper focuses primarily on response time as the component of QoS. However according to Little’s law[7] response time can be expressed through throughput and vice versa. Therefore it is assumed that a SLA restricts the maximum response time of a workflow and that a failure to deliver the response from the CWS with the specified time frame will result in a penalization. For solving this problem, a method similar to the backward CPM method [6] is used. The method allows finding the LST for component requests in a workflow with the constraint on composite request processing time. If it is assumed that the maximum response time is noted as RSLA, the estimated completion time is Cmax then LST can be assigned after performing the following steps: Step 1. LSTi = RSLA-kpi, , where k = RSLA x/Cmax. The main purpose of the constant k is to indicate how much faster the composite request can be processed in compare to the SLA obligation. Scaling up the average processing times by k would allow scaling up the overall response time to RSLA. As the result the total CWS slack time equal to RSLA -Cmax time is distributed among all the component requests proportionally to their mean processing times. The goal of this technique is to compensate possible variations in the CWS processing time due to potential service load fluctuations. Step 2. Inductively for each request j LSTj=min (LSTm-kpj), where m є {all successors of j} After the LSTs were determined they have to be translated into priorities of the requests for the component services. The priority of a request depends on the time left till the request can be processed and its price and penalty. After empirical studies trying various functional dependencies we discovered that the one of the most feasible (optimal) ways to express the priority is:
(t − LST ) /(Pr ice + Penalty) 2 t ≤ LST , P= 2 (t − LST )(Pr ice + Penalty) , t > LST where t is the current time, and t-LST indicates how much time a request can still spend waiting. After executing component requests with the specified priorities, the average processing time p for each type of CWS and each type of SLA are recorded. Later this data will be used by CPM. Therefore values are to be periodically updated in order to reflect the current loads on services. However between two sequential updates they can be assumed to be constant III.
EXPERIMENTS.
The experiments are conducted using a model [8] within the Anylogic [9] simulation model that accurately captures the behavior of Axis Web Services under various loads A. Static Priority Scheduling In order to evaluate the outcomes of applying SLAAWS we compare it to Static Priority Scheduling (SPS). SPS is an “orthodox” scheduling policy which is employed in cases when the priority of a request can be estimated a priori [10]. Hence the SLA contains the information describing the “importance” of the requests SPS can be employed. The price of a service invocation and penalty for its failure can determine the “weight” of the component requests. However there is no a straight way of breaking QoS constraints of composite service requests into QoS requirement for its sub-components. Therefore in the current work it is assumed that the priority is linearly proportional to a price and a penalty of a call. Thus a higher price results in a higher priority. And among the requests with equal invocation price the one with the highest penalty is dominating over the others. Generally speaking the maximum response time constraints for SLA are in inverse proportion to the price/penalty. Therefore for such cases the SPS functionally is identical to Earliest Deadline First (EDF) scheduling without preemption [10, 11]. B. SLA This paper focuses on the SLA model so called “per invocation” pay. It is assumed that each successful invocation of a service results in charging the service consumer a constant amount of certain currency. As the primary agreement constraint the maximum response time is used. The service response time is defined as the time between sending a service request and receiving a corresponding service response. A failure to deliver a result within a predefined time frame is penalized. The penalization model is built upon a “per invocation” billing model. An instantiation of such agreement is presented on figure four. The numbers assigned to series points indicate SLA contracts.
priorities to more expensive requests. And SLAAWS can give priority to cheaper ones if the ratio of their remaining time to price exceeds the ratio of more expensive requests, meanwhile most likely they have already timed out. However it is important to note, that this effect is completely eliminated by using time outs.
350 300
price
1
penalty
Value,$
250 200 150
2
100
1
3
50
2
4
3
1
2
3
5 5
4
0 4
5
6 6 6
7 7 7
8 8 8
9 9
10 10
1800000
9 10
1600000
SPS w/o timeouts
1400000
SLAAW S w/o timeouts
Max time, s
Fig 2.QoS differentiation according invocation price and penalty
SPS
1200000
SLAAW S
1000000
C. One service case All the incoming requests are distinguished according their SLA [fig 4]. The sizes of service requests are exponentially distributed with the average value 0.1 s. which implies that each request requires in average 0.1 s of 100% resources time in order to be processed. We assume that each type of contracting clients is creating an equal share of the total load. As for describing the requests arrival a Poisson process is chosen [12]. Each experiment set is executed for 2 hours 42 minutes (10,000 seconds). Within the experiment the service compositions are gradually exposed to an increasing load. Cumulative Penalty (CuP) representing the sum of all penalties charged for agreements violations is chosen as the main metrics. The first observation is the superlinear CuP dependency from the overall request rate, e.g an increase of the load from 8 to 9 req/s causes a 328% jump of CuP [fig. 3]. The performance of SPS and SLAAWS is depicted on figure 3. The policies exhibit similar behaviour within average load (
