A Constraint-Based Approach to Quality Assurance in Service Choreographies c, 1 Manuel Carro, 1 , 2 Dragan Ivanovi´ Manuel Hermenegildo 1 , 2 1 Universidad Politécnica de Madrid, 2 IMDEA 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: Automatically derive choreography QoS model 1 for a class of input requests ⇒ SLA offerings Predict choreography SLA violations at runtime 2 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 a 2 a 7 a 4 ¬ forced Get bud- Choose Participant A get line a 5 best a 9 a 10 a 11 a 0 a 1 a 6 Start Receive Send Receive + + × × ☞ alternatives a 8 choice P .O. purchase a 3 Send spec. Choose cheapest list forced � a 14 count>1 Send alter- Receive Participant B a 15 natives choice a 20 a 16 a 12 Generate a 17 a 18 Get spec. Put choice Send × × alterna- list into P .O. P .O. a 19 tives a 13 a 21 Automatic choice count=1 � Participants: A - procurement process, B - agent Size of A’s specification list → # of B’s iterations ( k B ) → # of A’s iterations ( k A ) (+ 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-to-A: request-reply User A B A-to-B: request ◮ stateful interaction list of specs ◮ nested messages ◮ multiple messages foreach spec foreach spec >1 alternative Still 1:1 in both directions, alternatives but other patterns possible: choice generalized message streams: purchase order ◮ multiple sends, response ◮ 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 Choreography participants → req components with channels: request response (1) (1) ◮ A: req , agent , check check ◮ B: client , approval alternatives ( N ) A Every channel c has two message choice ( N ) directions (in/out), described with: list of purchase 〈 ¯ N in / out ( c ) , ¯ q in / out ( c ) , ∆¯ q in / out ( c ) 〉 specs (1) order (1) agent QoS for QoS increment Number of M = N messages the first for subsequent client message messages exchanged purchase list of order (1) specs (1) intervals of possible values choice ( M ) B E.g.: ◮ 0 ≤ N in ( check ) ≤ 8 alternatives ( M ) ◮ 20ms ≤ T in ( check ) ≤ 60ms approval ◮ 15ms ≤ ∆ T in ( 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 or 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 Availability λ : What is the time will the rest of the probability of all invoked composition take? components being available? Straightforward, Transform: physical meaning. p = e − λ , λ = − ln p 0 ≤ T ≤ + ∞ 0 ≤ p ≤ 1 , 0 ≤ λ ≤ + ∞ SLA objective: SLA objective: e − λ ≥ p min ≡ λ ≤ λ max T + ∆ T since start ≤ T 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 ∆ T i = T − i − T + depends on the activity type. i ◮ If activity i follows j : T + i = T − j ◮ If i receives a message: T + � T − � i = max j , T in ( 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: ∆ T i = K activity i (known range K ) AND-parallel split/join: activity i max (∆ T 1 , ∆ T 2 ) ≤ ∆ T ≤ ∆ T 1 + ∆ T 2 + + (implementation dependent) activity j Multiple receive-send in a loop: T out ( c ) = T − i : rcv. from c j � � T − j − T + . ∆ T out ( c ) = max i , ∆ T in ( c ) . . (Responses cannot be sent at a rate higher than that of the incoming j : send to c requests) � D. Ivanovi´ c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 12 / 20
Constraints for a Fragment of Participant A a 7 ¬ forced Choose a 4 best a 5 a 9 a 6 Receive Send × × alternatives a 8 choice Choose cheapest forced � T + 6 = T + 7 = T + 8 = T − T + 9 = T − T + T + � � 5 5 = max 4 , T in ( check ) 8 ( forced = 0 ∧ T − 6 = T − 9 = T + 7 = T 6 + ∆ T best ) ∨ T − 8 + t send 5 = T + T − 5 + t recv ( forced = 1 ∧ T − 6 = T − 8 = T 8 + t expr ) = T out ( check ) k A = N in ( check ) 4 = T + � k A = 0 ∧ T − � � k A > 0 ∧ T − 4 = T − � ∨ 9 + ( k A − 1 ) × L 5 9 − T + � T − � L = max 5 , ∆ T in ( check ) D. Ivanovi´ c et al. (UPM, IMDEA) Constraint-Based QoS Assurance ICSOC 2012, Shanghai 13 / 20
Recommend
More recommend
