A Constraint-Based Approach to Quality Assurance in Service - - PowerPoint PPT Presentation

A Constraint-Based Approach to Quality Assurance in Service Choreographies

Dragan Ivanovi´ c,1 Manuel Carro,1,2 Manuel Hermenegildo1,2

1Universidad Politécnica de Madrid, 2IMDEA Software Institute Madrid

ICSOC 2012, Shanghai, China, 14 November 2012

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 1 / 20

Background: Quality of Service [Compositions]

Quality of Service (QoS) critical for Web service usability:

◮ Different users ⇒ different goals ⇒ different QoS requirements. ◮ Service Level Agreements (SLAs): contracts between service

users and providers on QoS levels.

Service compositions:

◮ Coordinate individual, specialized services. ◮ Implement higher-level, cross-boundary tasks. ◮ Exposed as services ( SOA compositionality).

Several types of QoS-related activities:

QoS negotiation: what SLAs are “reasonable”? QoS prediction: knowing that SLA will be violated ahead of time. QoS assurance: design-time choices and runtime mechanisms for ensuring SLA levels / avoiding violations.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 2 / 20

QoS Prediction for Service Orchestrations

Orchestrations are compositions with centralized control flow (≈ workflows, processes) ⇒ a simpler case. In our previous work ( ICSOC-11 , PESOS-12 ), we proposed and evaluated an approach for constraint-based QoS prediction for service orchestrations:

◮ runtime, continous, per-instance prediction; ◮ based on constraint modeling; ◮ applicable to execution time, availability and other QoS;

with some nice properties:

◮ minimal assumptions about component QoS ranges; ◮ high level of accuracy, good lead times; ◮ very efficient: small prediction overhead.

Other QoS prediction techniques for orchestrations, based on data mining, runtime verification, model checking, time series analysis, etc.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 3 / 20

Motivation

Extend QoS analysis for orchestrations → choreographies.

◮ Centralized control → multiple participants ⇒ multiple engines. ◮ Request-reply messaging → complex message patterns ◮ Stateless interaction → stateful ⇒ data driven ◮ End-to-End SLAs → multi-participant QoS contstraints

⇒ significant updates to the constraint-based (+ other) approaches for orchestrations.

Build a constraint-based framework for choreographies to:

1

Automatically derive choreography QoS model for a class of input requests ⇒ SLA offerings

2

Predict choreography SLA violations at runtime based on the model ⇒ triggering events

3

Check SLA compliance of choreography participants for classes of input requests ⇒ dynamic selection (binding)

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 4 / 20

An example choreography

☞ a0 + a1 Get bud- get line a2 Send spec. list a3 + a4

• Receive

alternatives a5 × a6 ¬forced forced Choose best a7 Choose cheapest a8 × Send choice a9 Receive P .O. a10 Start purchase a11 a12 Get spec. list a13 a14

• Generate

alterna- tives a15 × a16 count>1 count=1 Send alter- natives a17 Receive choice a18 Automatic choice a19 × Put choice into P .O. a20 Send P .O. a21 Participant A Participant B

Participants: A - procurement process, B - agent Size of A’s specification list → # of B’s iterations (kB) → # of A’s iterations (kA) (+ forced flag) → A’s QoS Clearly, A’s data → B’s QoS → A’s QoS.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 5 / 20

Complex stateful interactions

User A B request list of specs alternatives choice foreach spec foreach spec >1 alternative purchase order response

User-to-A: request-reply A-to-B:

◮ stateful interaction ◮ nested messages ◮ multiple messages

Still 1:1 in both directions, but other patterns possible: generalized message streams:

◮ multiple sends, ◮ multiple replies

in a single conversation.

(Another point of view with slightly different angle: session types.)

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 6 / 20

QoS Component Model

A

req

response (1) request (1)

agent

purchase

• rder (1)

list of specs (1)

check

alternatives (N) choice (N)

B

client

purchase

• rder (1)

list of specs (1)

approval

choice (M) alternatives (M) M = N

Choreography participants → components with channels:

◮ A: req, agent, check ◮ B: client, approval

Every channel c has two message directions (in/out), described with: 〈 ¯ Nin/out(c), ¯ qin/out(c), ∆¯ qin/out(c)〉

Number of messages exchanged QoS for the first message QoS increment for subsequent messages intervals of possible values

E.g.:

◮ 0 ≤ Nin(check) ≤ 8 ◮ 20ms ≤ Tin(check) ≤ 60ms ◮ 15ms ≤ ∆Tin(check) ≤ 30ms

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 7 / 20

QoS Analysis Steps

1 Obtain participant continuations

◮ Describing what remains to be done for each participant. ◮ At the start: whole participant processes (special case).

(Precision increases as the execution progresses.)

2 Derive participant QoS constraint models

◮ Structurally, from participant continuations. ◮ Choose a cumulative QoS metrics (e.g., execution time).

3 Integrate and jointly solve the participant models.

◮ Against the specified SLA objectives (requirements). ◮ Obtain (intervals of) possible QoS values for each

participant.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 8 / 20

Obtaining participant continuations

Use specific (non-graphical) language for continuations.

◮ Used to derive constraint model structurally. ◮ A degree of abstraction.

Obtaining continuations:

◮ By external observation:

• Needs participant process definitions, plus
• process / engine state, plus
• lifecycle / execution events.

May fall out of sync if information is incomplete

• r if the process is dynamically changed/adapted

◮ Directly from the execution engine:

• Always implicitly present in the interpreter state.
• The engine may be “doctored” to provide it explicitly.
• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 9 / 20

T wo cumulative QoS metrics

Running time T: How much

time will the rest of the composition take?

Straightforward, physical meaning. 0 ≤ T ≤ +∞ Availability λ: What is the

probability of all invoked components being available?

Transform: p = e−λ, λ = − lnp 0 ≤ p ≤ 1, 0 ≤ λ ≤ +∞ SLA objective: T + ∆Tsince start ≤ Tmax SLA objective: e−λ ≥ pmin ≡ λ ≤ λmax Both are cumulative (add up from one activity to another) and monotonic (non-negative values).

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 10 / 20

Deriving participant QoS models

CSP built structurally by decomposing the continuation into individual constructs:

sequences • parallel flows • service invocations conditionals • loops

◮ QoS metrics of complex structures conservatively built from

components’ → logically sound if components’ are sound.

◮ Metrics for the continuation = metrics for the participant.

For the case of the execution time:

◮ Each activity i annotated with:

• start time T+

i

• finish time T− ≥ T+

◮ Duration ∆Ti = T−

i − T+ i

depends on the activity type.

◮ If activity i follows j: T+

i = T− j

◮ If i receives a message: T+

i = max

• T−

j , Tin(c)

• (all variables represent intervals)
• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 11 / 20

Some QoS Derivation Examples (Time)

Simple activity / stateless invocation:

activity i ∆Ti = K (known range K)

AND-parallel split/join:

activity i activity j

+ +

max(∆T1, ∆T2) ≤ ∆T ≤ ∆T1 + ∆T2 (implementation dependent)

Multiple receive-send in a loop:

• i: rcv. from c

j: send to c

. . .

Tout(c) = T−

j

∆Tout(c) = max

• T−

j − T+ i , ∆Tin(c)

• (Responses cannot be sent at a rate

higher than that of the incoming requests)

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 12 / 20

Constraints for a Fragment of Participant A

a4

• Receive

alternatives

a5 × a6

¬forced forced Choose best

a7

Choose cheapest

a8 ×

Send choice

a9

T+

6 = T+ 7 = T+ 8 = T− 5

(forced = 0 ∧ T−

6 = T− 7 = T6 + ∆Tbest)∨

(forced = 1 ∧ T−

6 = T− 8 = T8 + texpr)

T+

5 = max

• T+

4 , Tin(check)

• T−

5 = T+ 5 + trecv

T+

9 = T− 8

T−

9 = T+ 8 + tsend

= Tout(check) kA = Nin(check)

• kA = 0 ∧ T−

4 = T+ 5

• ∨
• kA > 0 ∧ T−

4 = T− 9 + (kA − 1) × L

• L = max
• T−

9 − T+ 5 , ∆Tin(check)

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 13 / 20

Analysis of types with size constraints

Participant behavior generally dependent on data.

◮ Loop iterations (e.g., kA, kB). ◮ Branch conditions (e.g., forced flag).

Data size is often a useful abstraction. ⇒ Assign a type with size constraints to each message.

τ := any | none (some unspecified value and no value) | bool(a..b) (Boolean between a and b, a, b ∈ {0, 1}) | number(a..b) (number between a ∈ R ∪ {−∞} and b ∈ R ∪ {+∞}) | string(a..b) (string of size between a ∈ N and b ∈ N ∪ {+∞}) | list(a..b, τ) (list of size between a ∈ N and b ∈ N ∪ {+∞}) | { x1 : τ, x2 : τ, ..., xn : τ } (record with named fields x1, ..., xn)

T ype analysis: an instance of abstract interpretation.

◮ T

ypes with size constraints form a complete lattice.

◮ Can be combined with computation cost analysis.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 14 / 20

Application: SLAs for Input Classes

Question: What SLA can be offered to an end user depending on the input data?

◮ End-to-End from the user perspective. ◮ Inputs characterized using types with size constraints. ◮ Absolute guarantees vs. confidence intervals.

Finding the answer:

◮ Build & solve the participant models at t = 0. ◮ Use the metrics intervals for the final activity.

Example:

◮ Execution time SLA: participant A → end user. ◮ Input abstracted as list(a, b, any) ◮ Input classes → neighboring intervals [ai, bi]N. ◮ Also: forced flag → bool(f, g). ◮ Time ranges for simple steps/stateless invokes:

→ confidence intervals 100%, 99%, 90%, ...

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 15 / 20

Application: Predicting SLA Violations

Question: How to predict SLA violation at runtime?

◮ SLA given/known in advance. ◮ Currently executing instance with known inputs.

Finding the answer:

◮ Continuously obtain continuations, build & solve the

• models. (Precision increases as less remains to be done.)

◮ Compare the resulting metrics intervals against SLA.

Example: potential failure zones painted grey

execution time 14 376 ms 27 057 ms 63 103 ms

Tmax

9 10 17 20 41 50 input data size

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 16 / 20

Producing a Prediction for an Orchestration

At each point of prediction: predictor builds and solves a constraint satisfaction problem (CSP) for QoS.

Build+ Solve CSP

SLA compli- ance SLA failure

✦ ✦ t0 ✦ ✦ t1 ✦ ✦ t2 · · · · · · · · · ✦ ✦ ti−1

✩

✦ ti ? ✦ ti+1 · · · · · · · · · satisfiable?

T ests satisfiability of the two cases: SLA compliance and failure.

◮ Initially (t0, t1, . . . , ti−1) both satisfiable: predictor undecided. ◮ At some point (ti) compliance ruled out ⇒ failure predicted

(and vice versa: can predict SLA compliance).

◮ How well and how early?

Depends on solver type and constraints shape.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 17 / 20

Application: Compliance and Adaptation

Question: How to detect the need to adapt participants to meet an SLA at runtime?

◮ SLA given/known in advance. ◮ Input known (runtime) or the input class known (statically).

Finding the answer:

◮ Build and solve participant models (continuously or at

checkpoints) against the given SLA.

◮ Detect when loop iteration counts/branch conditions leave

the “safe ranges.”

Example:

◮ Critical combinations of kA and kB

that indicate an SLA violation on the next call to A.

◮ kB=size of the input list. ◮ Both known to B: can restrict to

single-choice to avoid calling A. 16 17 18 19 13 14 15 16 kA kB T =25 508 ms T =25 608 ms T =25 708 ms T =25 808 ms

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 18 / 20

Conclusions

This work:

◮ Extends efficient, accurate constraint-based QoS prediction for

• rchestration → choreographies.

◮ Addresses multi-participant compositions using complex, stateful

messaging.

◮ The resulting framework useful for:

• Supporting SLA negotiation
• Runtime prediction of SLA violations
• QoS-driven compliance checking, binding & adaptation

Future work:

◮ Develop supporting tools and systems, integration with service

infrastructure (different engines, composition languages).

◮ Evaluate quality of prediction w.r.t.

incomplete/inacurrate/unsynchronized information on environment/component QoS.

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 19 / 20

A Constraint-Based Approach to Quality Assurance in Service Choreographies

Dragan Ivanovi´ c,1 Manuel Carro,1,2 Manuel Hermenegildo1,2

1Universidad Politécnica de Madrid, 2IMDEA Software Institute Madrid

ICSOC 2012, Shanghai, China, 14 November 2012

• D. Ivanovi´

c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 20 / 20