Optimizing Service Selection and Allocation in Situational Computing Applications

1. Optimizing Service Selection and Allocation in Situational Computing Applications Chiara Sandionigi Danilo Ardagna Gianpaolo Cugola Carlo Ghezzi Presented by Kaiqun Fu

2. Outline Introduction Scenario Motivations Objective Related work Reference framework Optimization model Quality dimensions Parameters Decision variables Constraints Optimization problem analysis Run-time re-optimization Results and conclusions Case study Experimental results Conclusions and future work

3. Scenario • Situational computing systems: Continuously evolving environments including mobile devices, intelligent sensors, and smart systems which surround us and interact with each other and their users • Software as a Service paradigm (SaaS): • Software fragments providing a well-defined functionality of possible general use • Systems based on a discovery phase • Dynamic binding between service request and service provisioning

4. Motivations • Maximize the Quality of Service of the overall services composition • Re-optimization to cope with changes occurring at run-time • Remote vs. local execution

5. Objective • Service selection and allocation model for the run-time Quality of Service (re-)optimization of situational computing applications

6. Related work • Applications built through the composition of available services: • Composition by planning: Application schema built automatically or semi-automatically • Business process optimization: Application schema given • Three generations of solutions: • Local approaches: Services selected one at a time • Only local Quality of Service constraints • Global approaches: Services selection before the process is executed: • Significant overhead and unfeasibility conditions • Third generation approaches: introduction of techniques overcoming the limits of the previous approaches (e.g., loops peeling, negotiation) • Only remote service invocations

7. Related work - contributions • Service selection include both remote- and locally-available services • Pervasive environment network modeling • Incremental optimization of multiple quality criteria • Energy constraints

8. Reference framework • SMScom framework: • Application Manager: Management of the process execution • Optimizer Module: Dynamic selection and allocation of the concrete services to be invoked • SMScom Service Registry: Store concrete services and their quality profiles

9. Reference framework • SMScom Registry : • Self Managing Situated Computing • SMScom Service Registry: an extension of a UDDI registry. • UDDI: • Universal Description, Discovery and Integration is a platform-independent, Extensible Markup Language (XML)-based registry by which businesses worldwide can list themselves on the Internet, and a mechanism to register and locate web service applications. --------- Wikipedia

10. Reference framework

11. Reference framework - Application specification • Application specified as high-level business process written in BPEL and modeled as Directed Acyclic Graphs • Loop unfolding • Annotations • Maximum number of iterations for cycles • Global and local constraints on Quality of Service dimensions • Paths • Execution paths: Possible run of an application, without branches • Sub-path: No parallel execution of abstract services

12. Outline Introduction Scenario Motivations Objective Related work Reference framework Optimization model Quality dimensions Parameters Decision variables Constraints Optimization problem analysis Run-time re-optimization Results and conclusions Case study Experimental results Conclusions and future work

13. Quality dimensions • Availability: Probability that the invocation of a concrete service is performed successfully max A • Cost: Fee to pay for remote or local service invocation min C • Response time: Delay between the time instant when a request is sent and the time when the result is obtained min T • Energy: Energy consumed for the deployment and execution of services on local devices min E

14. Parameters

15. Decision variables • yi,j: Concrete service j remotely executed to support abstract service i • zi,j,k: Concrete service j locally executed by device k to support abstract service i • xi,j,k: Concrete service j deployed on device k and invoked for the first time to execute abstract service i • wi,j,k: Concrete service j already deployed on device k when abstract service i is executed

16. Constraints • Services assignment • Availability • A value in the range [0,1] representing the probability that a given operation of a concrete service is available, i.e., its invocation at run-time will be performed successfully. • Cost • A number representing the fee (e.g., in Euros) the end-user has to pay to the Service Provider for local or remote service operation invocation. • Response time • A numeric value representing the expected delay between the time when an operation is invoked and the time when the result is obtained. Response time is measured in seconds. • Energy • A value representing the energy (in Joule) consumed for the deployment of concrete services and execution of operations on local devices.

17. Services assignment constraints • For each abstract service, at most one remote concrete service must be selected: • For each abstract service, at most one concrete service deployed on a local device must be selected: • Every abstract service has to be executed either remotely or locally:

18. Availability constraints • The availability of each abstract service is computed as the availability for executing the related concrete service: • The availability of each execution path is computed as the product of the availabilities of the abstract services composing it: • The availability of each execution path must satisfy the availability global constraint:

19. Cost constraints • The cost for the execution of an abstract service is computed as the cost for the execution of the related concrete service remotely or locally: • The cost of each execution path is computed as the sum of the costs of the abstract services composing it: • The cost of each execution path must satisfy the cost global constraint:

20. Response time constraints • The time for the execution of an abstract service is computed as the time for the execution of the related concrete service remotely or locally: • The time for the deployment of a concrete service on a local device to support an abstract service must be computed only when the concrete service is invoked for the first time: • The time for the data transfer of an abstract service is computed as the time for the data transfer of the related concrete service remotely or locally: • The finishing time of the last abstract service must satisfy the time global constraint:

21. Energy constraints • The residual energy of any device different to the Application Manager is computed by taking into account the initial energy, the discharged energy, and the energy for deployment, execution and data transfer: • The residual energy of the Application Manager is computed by taking into account also the energy for the invocation of remote concrete services: • The residual energy of every device cannot be negative: • The energy for the whole application is equal to the maximum of the sum of energy consumption of every device:

22. Optimization model analysis • Mixed Integer Linear Programming problem • A mixed-integer program is the minimization or maximization of a linear function subject to linear constraints. • If all the variables can be rational, this is a linear programming problem, which can be solved in polynomial time. In practice linear programs can be solved efficiently for reasonable-sized problems, or even for big problems with special structure. However when some or all of the variables must be integer, corresponding to pure integer and mixed integer programming respectively, the problem becomes.

23. Optimization model analysis • Multi-objective Mixed Integer Linear Programming problem • optA = max A • optC = min C A = optA • optT = min T A = optA C = optC • min E A = optA C = optC T = optT

24. Run-time re-optimization • Re-optimization triggered when: • The current Quality of Service values differ from the prediction more than a given threshold • A service invocation fails • The final number of iterations of a loop differs from the one expected • New services or local devices emerge or current ones become unavailable • Quality of Service constraints or optimization parameters change • Requires a lower computation effort than the initial optimization • Lower number of abstract services and decision variables

25. Outline Introduction Scenario Motivations Objective Related work Reference framework Optimization model Quality dimensions Parameters Decision variables Constraints Optimization problem analysis Run-time re-optimization Results and conclusions Case study Experimental results Conclusions and future work

26. Case study • Business Process Execution Language (BPEL), short for Web Services Business Process Execution Language (WS-BPEL) is an OASIS standard executable language for specifying actions within business processes with web services. Processes in BPEL export and import information by using web service interfaces exclusively.

27. Case study

28. Experimental results - Case study setup • Local devices available: • Body sensors • Local PC • Hand-held device (Application Manager) • Case study activities: • Data reading, executable only by the body sensors • Data processing, executable both locally and remotely • Analysis reservation, executable only remotely • Abstract service supported on average by 4 concrete services • Case study execution steps: • Initial solving • First re-optimization: Failure of ECG invocation • Second re-optimization: Only one analysis center reservation is required

29. Experimental results - Case study setup • Availability values: Minimum and maximum availability values were randomly generated in the range [0, 1]. • Cost values: assume that the cost of a service operation invocation is inversely proportional to the execution time and depends exponentially on availability: where ηi and δi are constants that depend on the particular functionality implemented by the abstract service • Time values: Time parameters were calculated by considering the Internet for remote communication and ZigBee for local communication.

30. Experimental results - Case study setup • Energy values: For each device, the initial energy has been considered in the range (5000, 18000) J. while the power consumption has been set equal to 6 mW for executio (execution power), 65 mW for ZigBee transmission (z power), 1.5 W for WiFi transmission (i power), and 40 μW in idle state (idle power)

31. Experimental results - Optimization model scalability • Model tested by considering a wide set of randomly generated instances • Quality of Service values randomly generated by assuming a uniform distribution in realistic intervals

32. Experimental results - Case study execution

33. Conclusions • Development of a service selection and allocation model for run-time optimization / re-optimization of pervasive applications’ Quality of Service, by taking into account: • Incremental optimization of multiple quality criteria • Both remote and local execution • Energy constraints • Pervasive network interaction