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
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
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
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
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
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
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
Notes de l'éditeur
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