Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition
•Als PPTX, PDF herunterladen•
0 gefällt mir•496 views
SOSOA talk presented at ICWS 2011.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Andere mochten auch (15)
Ähnlich wie Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition
Ähnlich wie Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition (9)
Mehr von Achille Peternier
Mehr von Achille Peternier (7)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition
- 1. Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition Authors: Immanuel Trummer, Boi Faltings
- 2. Presentation Plan 1. Introduction to Quality-Driven Service Composition 2. Tradeoff between Composition Effort and Solution Quality 3. Algorithm for Automatically Tuning Composition Effort 4. Experimental Evaluation 5. Conclusion
- 3. INTRODUCTION TO QUALITY- DRIVEN SERVICE COMPOSITION
- 4. Problem of Quality-Driven Service Composition Transcoding Invocation-Cost: 0.15$ Video Response Time: 0.4 sec WS Candidates: - S1,1 Compression Merging WS - S1,2 WS … Candidates: Candidates: - S3,1 - S4,1 Translation - S3,2 - S4,2 Text WS … … Candidates: - S2,1 - S2,2 … Example: «Web Services Selection for Distributed Composition of Multimedia Content», Wagner & Kellerer, 2004
- 5. Problem of Quality-Driven Service Composition Transcoding Video WS Candidates: - S1,1 Compression Merging WS - S1,2 WS … Candidates: Candidates: - S3,1 - S4,1 Translation - S3,2 - S4,2 Text WS … … Candidates: - S2,1 Goal: - S2,2 … - Cost < x $ per invocation - Minimize response time Example: «Web Services Selection for Distributed Composition of Multimedia Content», Wagner & Kellerer, 2004
- 6. Process in Quality-Driven Service Composition Discovery Optimization Execution Composition Phase
- 7. TRADEOFF BETWEEN COMPOSITION EFFORT AND SOLUTION QUALITY
- 8. Tradeoff: Composition Effort vs. Solution Quality Optimize Heavy load on Middleware Composition Effort Tradeoff Adapt Dynamically! Quality of the Solution High-Priority Optimize Workflows
- 9. Tradeoff: Composition Effort vs. Solution Quality Composition Effort Quality of the Solution
- 10. Tradeoff: Composition Effort vs. Solution Quality C= Composition Effort CD - Discovery Cost + CO - Optimization Cost Quality of the Solution + CE - Execution Cost
- 11. Tradeoff: Composition Effort vs. Solution Quality C= Composition Effort CD - Discovery Cost + CO - Optimization Cost Quality of the Solution + CE - Execution Cost Parameter: #Downloaded Services per Task
- 12. Dependency: Cost and #Services Cost CO CD #Services
- 13. Dependency: Cost and #Services Cost CE CO CD #Services
- 14. Dependency: Cost and #Services Cost C CE CO CD Minimum Cost #Services Where?
- 15. ALGORITHM FOR AUTOMATICALLY TUNING COMPOSITION EFFORT
- 16. Sketch of Iterative Algorithm Round i: ∆CD,i ∆CO,i ∆CE,i Discovery Optimization next k services/task Within ? Execution current search space Condition for Next Iteration?
- 17. Relation between Cost for Last Round and Cost for New Round Relation: ∆CD,i ? ∆CD,i+1 ∆CO,i ? ∆CO,i+1 ∆CE,i ? ∆CE,i+1
- 18. Relation between Cost for Last Round and Cost for New Round Relation: ∆CD,i = ∆CD,i+1 ∆CO,i ? ∆CO,i+1 ∆CE,i ? ∆CE,i+1
- 19. Growth of Search Space for Optimization Search Space Round i Search Space Round i+1
- 20. Growth of Search Space for Optimization Search Space Round i Search Space Round i+1 Explored by Inefficient Method in Round i+1
- 21. Growth of Search Space for Optimization Search Space Round i Search Space Round i+1 Explored by Efficient Method in Round i+1
- 22. Growth of Search Space for Optimization (Cont.) t : number of tasks k: new services per task and iteration • Search Space Size in round i: • Search Space Size in round i+1: • Size of newly added search space: Size of newly added search space grows from round to round
- 23. Relation between Cost for Last Round and Cost for New Round Relation: ∆CD,i = ∆CD,i+1 ∆CO,i ? ∆CO,i+1 ∆CE,i ? ∆CE,i+1
- 24. Relation between Cost for Last Round and Cost for New Round Relation: ∆CD,i = ∆CD,i+1 ∆CO,i ∆CO,i+1 ∆CE,i ? ∆CE,i+1
- 25. Ratio between Size of New and Old Search Space Ratio diminishes, big improvements unlikely at some point
- 26. Diminishing Returns Cost CE #Iterations
- 27. Relation between Cost for Last Round and Cost for New Round Relation: ∆CD,i = ∆CD,i+1 ∆CO,i ∆CO,i+1 ∆CE,i ? ∆CE,i+1
- 28. Relation between Cost for Last Round and Cost for New Round Relation: ∆CD,i = ∆CD,i+1 ∆CO,i ∆CO,i+1 ∆CE,i ∆CE,i+1
- 29. Sketch of Iterative Algorithm Round i: ∆CD,i ∆CO,i ∆CE,i Discovery Optimization next k services/task Within ? Execution current search space Condition for Next Iteration?
- 30. Sketch of Iterative Algorithm Round i: ∆CD,i ∆CO,i ∆CE,i Discovery Optimization next k services/task Within ? Execution current search space Number of iterations is near-optimal
- 32. Testbed Overview • Starting Point: – Randomly generated sequential workflows with randomly generated quality requirements • Discovery: – Randomly generated service candidates – Simulated registry download • Optimization: – Transformation to Integer Linear Programming problem – Use of IBM CPLEX v12.1 • Verified that our initial assumptions hold
- 33. Testbed Cost Function Represent dynamic context by changing weights
- 34. Comparison: with vs. without Tuning 10SPT 40SPT 70SPT With Tuning 800% 700% 600% Aggregated Cost 500% 400% 300% 200% 100% 0% doe Doe dOe doE DoE dOE DOe Scenario
- 35. Comparison: with vs. without Tuning 10SPT 40SPT 70SPT With Tuning 800% 700% 600% Aggregated Cost 500% 400% 300% 200% 100% 0% doe Doe dOe doE DoE dOE DOe Scenario
- 36. Comparison: with vs. without Tuning 10SPT 40SPT 70SPT With Tuning 800% 700% 600% Aggregated Cost 500% 400% 300% 200% 100% 0% doe Doe dOe doE DoE dOE DOe Scenario
- 37. Comparison: with vs. without Tuning 10SPT 40SPT 70SPT With Tuning 800% 700% 600% Aggregated Cost 500% 400% 300% 200% 100% 0% doe Doe dOe doE DoE dOE DOe Scenario
- 38. CONCLUSION
- 39. Conclusion • Tradeoff between Composition Effort and Solution Quality in Service Composition • Iterative Algorithm for Quality-Driven Service Composition • Tuning of Composition Effort Gains in Efficiency • Iterative scheme is generic Immanuel.Trummer@epfl.ch
Hinweis der Redaktion
- QoS-Driven Composition starts from an abstract workflow template like the one I show hereExample explanationFor every task there is a set of candidate services available, same functionality, different QoS such as …Can make abstract workflow executable by assigning tasks to concrete servicesNon-functional properties of whole workflow are determined by service selectionsGoal of QoS-Driven Service Composition is to find an assignment which respects certain minimum quality requirements while optimizing othersExample GoalNP-hard
- QoS-Driven Composition starts from an abstract workflow template like the one I show hereExample explanationFor every task there is a set of candidate services available, same functionality, different QoS such as …Can make abstract workflow executable by assigning tasks to concrete servicesNon-functional properties of whole workflow are determined by service selectionsGoal of QoS-Driven Service Composition is to find an assignment which respects certain minimum quality requirements while optimizing othersExample GoalNP-hard
- Services in registry -> begin by retrieving corresponding services from the registryOptimization: Algorithms used include ILP, Gas, …Executed by the middlewareAfter assigning tasks to concrete services, the workflow can be executed (not part of composition)
- In the context of QoS-Driven composition: 2 things importantQuality of Solution=Executable WorkflowBut also: Effort of composition, like running time (since composition requests may arrive with high frequency and one expects them to be answered without delay)Many publicastionsUnfortunately: Often cannot optimise for bothIf I want high quality, must increase composition effortIntrinsic tradeoff between themFocus of our work: Dynamically tune this tradeoffExampleHow do we tune?
- We associate a cost with every processing phase, the total cost as sum of individual costWe want to minimize this total costThe way in which individual costs are calculated may depend on the context and on the specific composition requestIf the middleware is overloaded then every second of composition time gets more expensiveOn the other hand, if the composed workflow has to process large amounts of data, the cost of a suboptimal solution increases for this composition requestMost of the time we assume that they are proportional to the needed run time, but generic approach
- We want to tune the tradeoff between composition effort and solution qualityNeed a parameter to tuneSpecific parameters vs. Generic parameter, has influence on all three phasesNot forced to download all services per taskIncrease parameter …Lets look at a graphical representation for clarification
- AchsesCurbesDevelopment
- Total cost as sum that we want to minimizeWant to choose #services in order to reach global optimumBut it may be problematic to choose the optimal value in advanceIn particular: assuming that the variety of the workflow templates is not too restricted, how to estimate the development of execution cost without performing any discovery and optimization?Seems not possible in the general case => so we wont choose in advance and adopt an iterative approach instead
- SketchDownload next k service candidates for every taskSearch approximately optimal mapping with the current candidatesLook at result in order to decide whether to perform new iteration or to terminate composition and executeWe accumulate discovery and composition cost in every round – so … - but decrease execution cost, too - … negativeBut now we need a condition that tells us whether to perform new iteration or to stopIn order to formulate this condition we must use the changes in cost incured in last iteration to conclude on the cost changes to expect in the next one(look at what happened in the last round in order to predict what is going to happen in the next one)Lets look …
- Same number of services …Assume: download rate remains stable from one round to the nextLets look at optimizationCorrelated with size of search space
- This is the general formula for the size of the search spaceNow we assume that we use an efficient method which only looks at the newly added part of the search spaceBut also the size of the newly added search space grows from round to round, …
- And therefore we can conclude that the optimization cost will also tend to grow from round to round
- In average we assume here that the improvements tend to diminish, will come back to this point in the experimental evaluation
- We assume that the development of cost looks like thisSo the absolute value of the delta of the execution cost diminishes with growing number of iterations
- Wanted to find condition for executing next iteration or not
- The condition is: If the cost incurred in the last iteration do not exceed the improvements in execution cost, perform next iterationWith this condition, the number of iterations that is performed is in a distance of 1 to the optimum one which we proved in the paper
- We created a test suite in order to evaluate the assumptions we made in the beginning about the development of composition and execution cost and in order to prove that our algorithm performs better than static approaches
- We simulated different contexts associated with different weights and compared our self-tuning algorithm to static approaches that always download the same number of services per taskHere we show an extract from our experimental results, we averaged over 100 test cases for the figureaxes
- For every static method there is one scenario where it achieves at least 188% of the cost of our algorithm
- 188 %Shows benefits of dynamically adjusting composition effort
- Let me come to the conclusion