SLA-Driven Business Process Management in SOA

1. SLA-Driven Business Process Management in SOA Vinod Muthusamy, Hans- Arno Jacobsen University of Toronto Tony Chau, Allen Chan, Phil Coulthard IBM Canada November 4, 2009 CASCON 2009 msrg.toronto.edu

2. Software Development Evolution CASCON 2009

3. Agenda • Goals and the business process development cycle • Service Level Agreements and business process management • Distributed process execution CASCON 2009

4. Currently, business goals must be manually considered at every stage of the business process development cycle Only trusted partners service time < 3s Find flight Y Far? Validaterequest Getdestination Find train N cost < $0.02

5. Goals and the Development Cycle Let the system adapt to changing conditions to achieve the goals with minimal development and administrative effort SimplicityAn analyst can specify goals without detailed knowledge of the implementation technologies FlexibilityThe requirements and implementation technologies can be independently updated End-to-end specificationRequirements captured in the tools can be enforced and monitored throughout the development cycle Adaptive efficiencyThe system can allocate resources to meet changing requirements Modelling Business analyst Model Development Architect, developer Services Execution Administrator Events Monitoring Analyst, architect, administrator

6. Service Level Agreements SLAs are a contract between service consumers and providers that specifies the expected behaviour of each party and the penalties of violating the contract SLAs specify business goals declaratively

7. SLAs at Development Time Precisely specify SLA Flexible, reusable, extensible model Quickly construct SLA Validate SLA Supports loose coupling of process and SLA Monitor process Automatic instrumentation Efficient event-based monitoring 7

8. p q A B C D Runtime Uses of SLAs Dynamic service discovery(fabric support)Discover services with capabilities that satisfy goals. MonitoringOnly monitor the business events related to goals.Feed back measurements to support runtime adaptations. Distributed executionFine-grained allocation of process to available resources.Move portions of process to strategic locations. ESB adaptationReconfigure the ESB topology to satisfy goals. ESB C A,B service time < 2s 1a M service time < 1s 1b D 2 Web service Execution engine ESB router M Monitor CASCON 2009

9. Vision

10. Large-scale Business Processes Vendor Goods selection Goods delivery Dispatch B Packaging Pick-up goods Out-stock B FedEx Delivery Pick up Sale prediction Sign Contract Sale Fill order Determinate plan Process Check order CCC administrate Fill out-stock bill Check stock Manufacture Confirm features Design Fill dispatch bill Determinate plan Control Prototype Out Take Raw materials Execute plan Warehouse Material Out-stock B Pay Credit card Check Assign Audit Process control Make plan Target price Signature Raw Checkdealer Checkcredit Finance Confirm Approval Approval Monitoring Feature selection Print receipt Validate Statistic Monitor Marketing Requirement collection Feedback Affirm order Chart Strategy Design Marketing Manufacture Order Payment

11. Distributed Process Execution

12. Process Execution Architectures Centralized One execution engine May not scale Central point of failure Clustered • Replicated execution engines • Centralized control and data • High bandwidth and latency • Still may not scale AB C D AB C D AB C D C A,B D Agent-based • Distributed execution engine • In-network processing • Lower bandwidth and latency • Fine-grained use of resources

13. RedeploymentManager SLAs Cost models Ranking algorithms Software Architecture Agent Server CandidateDiscovery Execution ResourceMonitor Estimators Latency Bandwidth Engine Resource Execution Engine Tasks Instance states Atomic Redeployer Input, output queues Messaging CASCON 2009

14. Cost Model The cost of a process is based on three costcomponents 1. Distribution cost Cdist = Cd3 * (Cd1 + Cd2) Cd1 Message rate Cd2 Message size Cd3Latency 2. Engine cost Ceng = f(Ce1, Ce2,Ce3) Ce1 Load (number of instances) Ce2 Resources (CPU, memory, etc.) Ce3 Task complexity 3. Service cost Cserv = Cs1 + Cs2 + Cs3 Cs1 Latency of external service Cs2 Execution time of external service Cs3 Marshalling/unmarshalling Cost(agent) = ∑wiCi Cost(process) = ∑cost(agent) These costs can be weighted to achieve different objectives Optimize time wd1 = wd3 = we3 = Cserv = 1, other wi = 0 Optimize network overhead wd2 = wd3 = 1, other wi = 0 Various optimization criteria can be specified Threshold criteria: ∑wiCi > x E.g., Report SLA violations within 3 s. Minimized criteria:min( ∑wiCi ) E.g., Minimize distribution overhead

15. t1 t2 t3 t4 At Old Broker Disconnected At New Broker tp Disconnect Connect Active (moveout) (movein) Atomic Redeployment • Traditional pub/sub client movement protocols are expensive and do not offer strong transparency properties • Transactional movement • Formalized movement properties similar to ACID properties • Efficient and guaranteed routing reconfiguration • See padres.msrg.utoronto.ca 1 2 moveout movein Client Client

16. SLA Monitoring Overhead Monitoring an SLA can be expressed as a process Systematic mapping into flow of monitoring agents Optimize the execution of the monitoring “process” itself E.g., minimize traffic M M M Optim.criteria SLA One per ActionGuarantee M M M Scopefiltering Events MetricComputation Scopefiltering SLOEvaluation Scopefiltering Events Action ESB Scopefiltering MetricComputation SLOEvaluation 1a Events Reports One per atomic or composite metric ExclusionsEnabling One per SLO 1b 2 One per SLA ExclusionsEnabling Events Events Web service M Monitor

17. Evaluation

18. Evaluation Business process Deployment Topology • Business process with time varying branch hotspots • Initially biased towards A, B tasks • p = 90%, q = 10% • Then biased towards B, C tasks • p = 10%, q = 90% • Optimize network bandwidth • wd1 = 1, other wi = 0 • 3 execution engines • Fix tasks A, C; allow task B to move • Total cross-server messages of 100 process instances p q A B C A B C 1-p 1-q 1 2 3 ESB router Execution engine CASCON 2009

19. Scenario 1: No change in initial branch probabilities (90%, 10%) Scenario 2: Changing branch probabilities System reconfigures to changing load Results CASCON 2009

20. Summary

21. Exploiting SLAs Formal SLA model A formal SLA model can drive various stages of distributed application development. Process instrumentation.Monitoring rules generation.SLA validation. Autonomic reconfiguration tomaintain SLA. Fine grained resource usage. Automatic service composition. Goal-based discovery. ESB C A,B Process monitoring1 Distributed execution2 Service selection3 1a Distributed, scalable architecture. Real-time monitoring. Loosely coupled system. Transparent, live reconfiguration. Localize process modification. Distributed process search. Continuous search. M 1b D 2 Publish/subscribe messaging is an enabling technology for certain features. Distributed content-based publish/subscribe messaging middleware Papers: 1. Automating SLA Modeling, CASCON 2008. 2. SLA-Driven Distributed Application Development, MW4SOC 2008. Transactional Mobility in Distributed Content-Based Publish/Subscribe Systems, ICDCS 2009. 3. Distributed Automatic Service Composition in Large-scale Systems, DEBS 2008. Efficient Event-based Resource Discovery, DEBS 2009

22. Conclusions • End-to-end management of process development • Declarative SLA goals separate from the business process • Simplify transitions between modeling, development, execution, monitoring phases • All stages driven by declarative SLA requirements • Distributed process monitoring, execution, service selection • Scalable but more difficult to globally optimize • Ongoing work • More sophisticated reconfiguration algorithms • Larger processes, topologies CASCON 2009

23. Project websites An eQoSystem for declarative distributed applications with SLAs • http://research.msrg.utoronto.ca/Eqosystem/ • http://padres.msrg.utoronto.ca Acknowledgements CASCON 2009