Towards Data-Aware QoS-Driven Adaptation for Service Orchestrations - - PowerPoint PPT Presentation

Towards Data-Aware QoS-Driven Adaptation for Service Orchestrations

Dragan Ivanovi´ c1, Manuel Carro1, Manuel Hermenegildo1,2

1Universidad Polit´

ecnica de Madrid

2IMDEA Software Institute Madrid

ICWS 2010 Miami, FL, US July 7, 2010

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 1 / 19

Components Impacting Orchestration QoS

Services can be used as components within a service composition to achieve more complex tasks. At least two groups of factors affecting composition QoS:

◮ Variations from the environment (detected by monitoring): ⋆ Bandwidth, current load and throughput, network status. ⋆ Behavior of external services (e.g., meeting deadlines?). ⋆ Usually not under designer control. ◮ The structure of the composition: ⋆ What it does with incoming requests? ⋆ Which other services it invokes and how? ⋆ Partially under designer control, known in advance.

We focus on the latter aspect, and We indicate how it can be combined with the former to improve results of e.g. adaptation.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 2 / 19

Computation Cost Analysis and Services

We propose applying static analysis of computation cost to service

• rchestrations:

◮ Traditionally: number of steps, worst-case execution time (WCET). ◮ Generalized resources: counting and measuring events ⋆ Number of iterations, number of partner service invocations, number of

exchanged messages, network traffic (number of bytes sent/received).

Infer upper and lower bounds (safe approximations) for computational cost / resource usage.

◮ Not based on probabilities / empirical measurements. ◮ Always a guaranteed upper or lower bound. ◮ Hopefully, the exact cost (the bounds coincide).

Data Awareness: bounds expressed as functions of input data. We leverage on existing analysis tools.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 3 / 19

An Example: Car Part Reservation

Client Provider Maker 1 Maker K Request Cancel P a r t r e q . OK / not OK Part req. Cancel OK / not OK

Car part provider serves client (an assembly line) by reserving a number of car parts of different types from different makers. The protocol requires reserving one car part type at a time. If a maker answers with “not OK,” the provider sends “Cancel” messages for all reserved parts and moves to the next maker. Total time depends (among other things) on number of parts (in the input message) and characteristics of individual makers. Time-oriented adaptation: try first maker which gives the lowest time for a given situation.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 4 / 19

Computation Cost of Service Networks

A B1 B2 TA(n) = 2n + 3 + nS(n) TB1(n) = n + 1 TB2(n) = 0.1n + 7

b i n d i n g t

• B1

? binding to B2?

20 40 60 80 100 120 140 4 5 6 7 8 9 10 QoS / Computational Cost Input data size (for a given metric) QoS / Comp Cost for A+B1 QoS / Comp Cost for A+B2

Input message abstracted as the number of parts n. Time TA for provider (A) depends

• n n and the time S(n) of the

chosen maker (B1 or B2). Structural part 2n + 3 in TA does not depend on the choice of maker. The graph shows the QoS / computation cost for two possible bindings:

TA with B1(n) = 2n + 3 + n(n + 1) = n2 + 3n + 3 TA with B2(n) = 2n + 3 + n(0.1n + 7) = 0.1n2 + 9n + 3

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 5 / 19

Computation Cost of Service Networks (cont.)

Computation cost information for B1 and B2 can be made available together with other service-related information (e.g., WSDL extensions):

◮ Cost expressed as function of some metrics of input data. ◮ Relationships between the size of input and output data (when they

exist). A should in turn publish synthesized information (for reuse in other compositions involving A). Such abstract descriptions of computation cost do not compromise privacy

• f implementation details.

◮ They act as higher-level contracts on composition behavior.

Providers that publish the computation cost information would enjoy an advantage in an open service ecosystem.

◮ Customers can make better decisions on which services to bind to. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 6 / 19

Approximating Actual Behavior With Upper and Lower Bounds

Automatic analysis often can only determine safe upper and lower bounds. Exact cost function somewhere in between.

20 40 60 80 100 120 140 4 5 6 7 8 9 10 QoS / Computational Cost Input data size (for a given metric) Upper bound QoS / Comp Cost for A+B1 Lower bound QoS / Comp Cost for A+B1 Upper bound QoS / Comp Cost for A+B2 Lower bound QoS / Comp Cost for A+B2

Assumption: different instances of the same event type contribute equally to the overall computation cost. Safe cost bounds are combined with current environment parameters from monitoring (e.g., network speed) to produce QoS bounds. QoS ≈ cost ⊗ environment not strictly safe, but:

◮ More informed than data-unaware, single point predictions, static

bounds, or averages.

◮ Can be used to predict future behavior of a composition. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 7 / 19

Benefits of the Upper/Lower Bounds Approach

QoS Input data measure QoS Input data measure QoS Input data measure QoS Input data measure Insensitive to Input Data Sensitive to Input Data Focus: Average Case

Good for aggregate measures. Usually simpler to calculate. Not very informative for individual running instances.

Focus: Upper/ Lower Bounds

Can be combined with the average case approach. More difficult to calculate. Useful for monitoring / adapting individual running instances.

General idea: More information ⇒ more precision

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 8 / 19

Benefits of the Computation Cost Approach

Statistical, data-mining based approach: structure and environmental factors contribute to QoS variability:

QoS Enviroment factors Structural factors

◮ Hard to separate structural & environmental variations. ◮ Whole range of input data may not be represented / sampled. ◮ Runs may not be representative. ◮ Results reflect historic variations in the environment.

Computation cost approach: safe approximations of structural contributions.

Enviroment factors Structural factor bounds QoS

◮ Structural and environmental factors separately composed into QoS. ◮ Entire input data range accounted for. ◮ Results are safe and hold for all possible runs. ◮ Results reflect current variations in the environment. ◮ Challenge: avoid loss of precision (minimize over- or under-approximation). Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 9 / 19

Overview of the Analysis Process

BPEL WSDL Intermediate language Logic program Analysis results T r a n s l a t i

• n

T r a n s l a t i

• n

Translation Analysis Feedback Feedback

Service / orchestration descriptions represented in intermediate language. Intermediate representation translated into (annotated) logic program.

◮ Independence from initial language. ◮ Can capture just the relevant characteristics of the orchestration.

Logic program analyzed for generalized resource consumption. Analysis results useful to drive adaptation, predictive monitoring, matchmaking, and other mechanisms that can be driven by QoS.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 10 / 19

Current Restrictions on Input Orchestrations

(Working around them)

Orchestrations must follow receive-reply interaction pattern:

◮ All processing between reception of the initiating message and

dispatching of (final) response.

◮ Applicable to processes that accept one among several possible input

messages.

◮ Future work: relax restriction by using fragmentation to

identify/separate reply-response service sections.

Orchestration must have no stateful callbacks:

◮ I.e., no correlation sets / WS-Addressing. ◮ Practical problem: current analyzers lose precision when passing

• paque objects containing state.

◮ Future work: improve translation and analysis itself. Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 11 / 19

BPEL-Style Orchestration Definitions

Intermediate language (partially) reflects BPEL: Data Types: XML-style data structures with basic (string, boolean, number) and complex types (structures, lists, optionality). Expression language: XPath restricted to child/attribute navigation that can be resolved statically. Basic arithmetic/logical/string operations. Basic constructs: assignment, sequence, branching, and looping. Partner invocation: invoke follows the synchronous pattern. The moment of reply reception is not accounted for. Scopes and fault handlers: usual lexical scoping and exception processing. Parallel flows: using logical link dependencies.

Compensation Handlers

We currently do not support BPEL-style compensation handlers that operate on past snapshots of scope/loop iteration variables. Without snapshots, compensations can be inlined at the place of invocation.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 12 / 19

Translation of Basic Constructs into LP

Service: Translated into a logic predicate expressing a mapping from the input message to a reply or a fault. Invocation: Translated into a predicate call. Returns a reply or a fault. Assignment: Passes the expression value to subsequent predicate calls. Branching: Mutually exclusive clauses for the then and else parts. Looping: Recursive predicate with the base case that corresponds to the loop exit condition. Scopes: Sub-predicates for scope body and each defined fault handler. Flows: Statically serialized according to logical link dependencies.

Concrete Semantics and Resource Consumption

Resulting logic program does not necessarily mimic exactly the operational semantics of, e.g., BPEL processes. Reflecting just the necessary semantics for resource analyzers to infer costs with minimal precision loss.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 13 / 19

Example Computation Cost Analysis Results

Analysis of a simple scenario:

Client Provider Maker Request Cancel part req. OK / not OK ◮ n number of parts to reserve. ◮ not OK is treated as a fault by the provider. ◮ two analysis variants: without fault handling (ideal case) and with fault

handling (general case).

With fault handling Without fault handling Resource lower bound upper bound lower bound upper bound

• No. of simple activities

2 7n 5n + 2 5n + 2 Single reservations n n n Cancellations n − 1

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 14 / 19

A Simulation Experiment in Adaptation

Client P1 UB1(m) P2 UB2(m) PN UBN(m) Tier 1 . . . S1 ub1(n) S2 ub2(n) SN ubN(n) Tier 2 . . .

50 100 150 200 250 10 20 30 40 50 ub_1(x) ub_2(x) ub_3(x) ub_4(x) ub_5(x) ub_6(x) ub_7(x) ub_8(x) ub_9(x) ub_10(x) ub_11(x) ub_12(x) lub(x)

Client chooses provider Pj from first tier of services, passing the input argument m = 0..50. Chosen provider chooses M = 5 times a part maker (the second tier) with the input n = m. Plot depicts family of upper bound functions for structural cost for the first and the second tier. Structural cost models number of messages exchanged (without messages between the tiers). Fault rate used to model service unavailability.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 15 / 19

A Simulation Experiment in Adaptation (contd.)

Client P1 UB1(m) P2 UB2(m) PN UBN(m) Tier 1 . . . S1 ub1(n) S2 ub2(n) SN ubN(n) Tier 2 . . .

50 100 150 200 250 10 20 30 40 50 ub_1(x) ub_2(x) ub_3(x) ub_4(x) ub_5(x) ub_6(x) ub_7(x) ub_8(x) ub_9(x) ub_10(x) ub_11(x) ub_12(x) lub(x)

Selection of first/second tier service done using:

◮ random choice; ◮ fixed preference (lowest cost for

n = 12); and

◮ data-aware cost minimization

Message passing times for the services simulated using the following two regimes:

(A) Random Gaussian choice with average 5ms for all services. (B) Varying average 4-8ms.

Effectiveness of policies compared w.r.t. total simulated time.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 16 / 19

Simulation Results

Case (A) for the fault rates pf = 0.001 and pf = 0.1:

1000 2000 3000 4000 5000 6000 5 10 15 20 25 30 35 40 45 50 Time [ms] random fixed data

sim_s1_pf001.data

1000 2000 3000 4000 5000 6000 5 10 15 20 25 30 35 40 45 50 Time [ms] random fixed data

sim_s1_pf100.data

Case (B) for fault rates pf = 0.001 and pf = 0.1:

1000 2000 3000 4000 5000 6000 5 10 15 20 25 30 35 40 45 50 Time [ms] random fixed data

sim_s2_pf001.data

1000 2000 3000 4000 5000 6000 5 10 15 20 25 30 35 40 45 50 Time [ms] random fixed data

sim_s2_pf100.data

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 17 / 19

Conclusions and Future Work

Data-aware computation cost functions can be used to drive QoS-aware adaptations. Developed a translation-based scheme which, from an orchestration represented in an intermediate language, generates a (logic) program that can be analyzed by existing tools.

◮ Analysis derives functions which are safe upper and lower bounds of the

• rchestration’s computational cost.

◮ These functions are used to build more precise QoS estimations as a

function of input data, which, in turn, can be used to drive adaptation. Simulation results indicate the usefulness of the approach in improving the efficiency of dynamic, run-time adaptation.

◮ In general, data-aware adaptation gave us better results than other

policies — even with very large variability in service availability. In the future, we plan to integrate the presented approach into service composition provision systems, collect empirical data and compare and combine with statistical / data mining approaches.

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 18 / 19

Towards Data-Aware QoS-Driven Adaptation for Service Orchestrations

Dragan Ivanovi´ c1, Manuel Carro1, Manuel Hermenegildo1,2

1Universidad Polit´

ecnica de Madrid

2IMDEA Software Institute Madrid

ICWS 2010 Miami, FL, US July 7, 2010

Ivanovi´ c et al. (UPM, IMDEA) Data-Aware QoS-Driven Adaptation 2010-07-07 19 / 19