Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition

649 views

Published on

SOSOA talk presented at ICWS 2011.

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
649
On SlideShare
0
From Embeds
0
Number of Embeds
148
Actions
Shares
0
Downloads
4
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • 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
  • Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition

    1. 1. Optimizing the Tradeoff between Discovery, Composition, and Execution Cost in Service Composition Authors: Immanuel Trummer, Boi Faltings
    2. 2. Presentation Plan1. Introduction to Quality-Driven Service Composition2. Tradeoff between Composition Effort and Solution Quality3. Algorithm for Automatically Tuning Composition Effort4. Experimental Evaluation5. Conclusion
    3. 3. INTRODUCTION TO QUALITY-DRIVEN SERVICE COMPOSITION
    4. 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,2Text WS … … Candidates: - S2,1 - S2,2 …Example: «Web Services Selection for Distributed Composition of Multimedia Content», Wagner & Kellerer, 2004
    5. 5. Problem of Quality-Driven Service Composition TranscodingVideo WS Candidates: - S1,1 Compression Merging WS - S1,2 WS … Candidates: Candidates: - S3,1 - S4,1 Translation - S3,2 - S4,2Text WS … … Candidates: - S2,1 Goal: - S2,2 … - Cost < x $ per invocation - Minimize response timeExample: «Web Services Selection for Distributed Composition of Multimedia Content», Wagner & Kellerer, 2004
    6. 6. Process in Quality-Driven Service CompositionDiscovery Optimization Execution Composition Phase
    7. 7. TRADEOFF BETWEEN COMPOSITION EFFORT AND SOLUTION QUALITY
    8. 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. 9. Tradeoff: Composition Effort vs. Solution Quality Composition Effort Quality of the Solution
    10. 10. Tradeoff: Composition Effort vs. Solution QualityC= Composition Effort CD - Discovery Cost+ CO - Optimization Cost Quality of the Solution+ CE - Execution Cost
    11. 11. Tradeoff: Composition Effort vs. Solution QualityC= Composition Effort CD - Discovery Cost+ CO - Optimization Cost Quality of the Solution+ CE - Execution Cost Parameter: #Downloaded Services per Task
    12. 12. Dependency: Cost and #ServicesCost CO CD #Services
    13. 13. Dependency: Cost and #ServicesCost CE CO CD #Services
    14. 14. Dependency: Cost and #ServicesCost C CE CO CD Minimum Cost #Services Where?
    15. 15. ALGORITHM FOR AUTOMATICALLYTUNING COMPOSITION EFFORT
    16. 16. Sketch of Iterative AlgorithmRound i: ∆CD,i ∆CO,i ∆CE,i Discovery Optimization next k services/task Within ? Execution current search space Condition for Next Iteration?
    17. 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. 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. 19. Growth of Search Space for Optimization Search Space Round i Search Space Round i+1
    20. 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. 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. 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. 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. 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. 25. Ratio between Size of New and Old Search Space Ratio diminishes, big improvements unlikely at some point
    26. 26. Diminishing ReturnsCost CE #Iterations
    27. 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. 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. 29. Sketch of Iterative AlgorithmRound i: ∆CD,i ∆CO,i ∆CE,i Discovery Optimization next k services/task Within ? Execution current search space Condition for Next Iteration?
    30. 30. Sketch of Iterative AlgorithmRound i: ∆CD,i ∆CO,i ∆CE,i Discovery Optimization next k services/task Within ? Execution current search space Number of iterations is near-optimal
    31. 31. EXPERIMENTAL EVALUATION
    32. 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. 33. Testbed Cost FunctionRepresent dynamic context by changing weights
    34. 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. 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. 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. 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. 38. CONCLUSION
    39. 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 genericImmanuel.Trummer@epfl.ch

    ×