Optimal service selection policies for dynamic service composition - PowerPoint PPT Presentation

Optimal service selection policies for dynamic service composition Miroslav Živković University of Amsterdam (UvA) System and Network Engineering Group m.zivkovic@uva.nl Joost Bosman, Hans van den Berg, Rob van der Mei, Erik Meeuwissen, Rudesindo Núñez-Queija

• M. Živković , J. Bosman, H. van den Berg, R. van der Mei, H. Meeuwissen, R. Núñez-Queija: Run-time Revenue Maximization for Composite Web Services with Response Time Commitments (AINA 2012) • M. Živković, H. van den Berg: Revenue Optimization of Service Compositions using Conditional Request Retries (IJWSR 2013)

Service Composition problem Given abstract workflow select concrete services to execute it Services implementing task 1 Services implementing task 2 Service B Service K t: p: t: p: Service A t: p: Task 2 Task 4 Task 1 Task 3 Service α t: p: Service Y Service X Service β t: p: t: p: t: p: Services implementing task 4 Services implementing task 3

Service composition • We focus on orchestration • At design time (multi-objective problem) – Choices made upfront; non-dominated, Pareto-optimal solutions – Inflexible; impossible to modify on-the-fly • At execution time: – Composition choices are made on-the-fly, flexible

What if performance worsens? • Runtime service selection • Runtime service substitution

Runtime service selection: Model request 1 composition: CS2(1) CS1(2)-CS2(2)-CS3(1)- CS4(1) CS1(1) response CS4(1) 1 CS2(2) request 1 CS1(2) CS3(1) request 2 CS2(3) CS4(2) response 2 CS1(3) request 2 composition CS2(4) Runtime service selection • Sequential workflow • Composition may be adapted during execution (per request/task) • Use of elapsed time info

The orchestrator • knows the workflow • selects appropriate services • makes appropriate Service Level Agreements (SLAs) with 3 rd party providers and its clients • has no impact to or control of 3 rd party domains • End-to-end SLA • response time deadline ( 𝜀 𝑞 ) • Reward when response time ≤ 𝜀 𝑞 , penalty otherwise • Single service SLA – Execution cost, response time distribution

Optimized dynamic decisions • Given CS2(1) i=1 i=2 i=3 i=4 CS1(1) – Position in workflow CS4(1) CS2(2) ? CS1(2) CS3(1) – Remaining time until deadline CS2(3) CS4(2) CS1(3) – Response time distributions CS2(4) Δ – Costs, reward and penalty • Decision – what service alternative to select based on the elapsed time? • Goal – Optimize expected revenue • Solution Apply Dynamic Programming

Lookup Table Policy { Abstract service at position 1 Concrete service alternative 4 { Abstract service at position 2 Concrete service alternative 3 { Abstract service at position 3 Concrete service alternative 2 { Abstract service at position 4 Concrete service alternative 1 0 5 10 15 D p Overall deadline t (time budget) • Simple solution • Calculate lookup table off-line • Apply lookup table on-line (no computing)

Example workflow, 4 tasks 50 DP Dynamic Static SW 40 E[Revenue] 30 A B C D E F G 20 10 0 a b c d e f g h i j k l m n o p q r s t u v w x a b c d e f g h i j k l m n o p q r s t u v w x Position 1 4 4 4 4 2 1 3 3 2 3 3 1 4 4 2 1 2 1 2 3 3 1 2 1 Position 2 2 3 3 1 4 4 4 4 3 2 1 3 2 1 4 4 1 2 3 2 1 3 1 2 Position 3 3 2 1 3 3 3 2 1 4 4 4 4 1 2 1 2 4 4 1 1 2 2 3 3 Position 4 1 1 2 2 1 2 1 2 1 1 2 2 3 3 3 3 3 3 4 4 4 4 4 4

Issue 1: sequential workflow CS2(2) f 4,1 ; c 4,1 f 2,1 ; c 2,1 K CS1(2) CS2(1) p 4 CS4(1) CS1(1) WS3 p 5 f 1,1 ; CS3(1) CS5(1) f 3,1 ; c 3,1 f 6,1 ; c 1,1 f 5,1 ;c 5,1 c 6,1 CS3(2) CS5(2) CS3(3) CS1(1) AWS 6 AWS 2,3 AWS 4,5

Issue 2 - availability request 1 composition: CS2(1) CS1(2)-CS2(2)-CS3(1)-CS4(1) CS1(1) response 1 CS4(1) CS2(2) request 1 B C D A CS1(2) CS3(1) request 2 CS2(3) CS4(2) response 2 CS1(3) request 2 composition CS2(4)

Runtime service substitution: Model 2 𝐷𝑇 1 3 𝐷𝑇 1 4 𝐷𝑇 1 response 2 θ 2 request 1 𝐷𝑇 2 θ ' 1 𝐷𝑇 1 retry retry D C request 2 B 4 3 A 𝐷𝑇 2 𝐷𝑇 2 response 1 2 𝐷𝑇 3 • For an orchestrated service, at each decision point (A, B, C, D) • a) which service should be selected? • b) when is it optimal to perform substitution • c) which service should be selected for a retry, same or some other? • with the goal to maximize end-to-end expected revenue for given deadline

Response-time: when does a substitution make sense? • Heavy-tailed response time distributions • Expectation paradox : “the longer we have waited, the longer we should expect to wait” • Bimodal/Multimodal distributions • Substitute by any given service • This does not involve the costs

Optimal solution • Use dynamic programming to calculate the policy: • Compare the expected revenues with and without retry • Formulae for case when single retry per each task is allowed • Task i, service j, deadline 𝜀 , retry moment 𝜄 , response time distribution f, F, revenue W • term 1: execution cost; term 2 – no retry needed; term 3 – retry made

Runtime service substitution - conclusions • For larger values of deadlines, policies with or without retries are close • Perform substitution for the last tasks – Cost plays a role: the more you pay the less substitutions you should perform

Issue 3 – time invariant PDF: Closed loop control • For each alternative response time distribution: keep last n samples • Calculate empirical distribution(s) • Apply DP on empirical distributions Challenges 1. We do not prefer updating the policy after each realization 2. When a certain alternative is never selected we don’t observe changes Solutions 1. Apply statistical test to see weather an empirical distribution has changed significantly 2. If a service is not used for (specified) time interval send a probe request (and pay corresponding cost); • Tradeoff: short interval (good + expensive) vs. large interval

Thank you!