1. eQoSystem: Supporting Fluid Distributed Service- Oriented Workflows Vinod Muthusamy, Young Yoon, Mo Sadoghi, Arno Jacobsen muthusamy@eecg.toronto.edu, yoon@msrg.utoronto.ca, mo@cs.toronto.edu, jacobsen@eecg.toronto.edu Middleware Systems Research Group www.msrg.org University of Toronto

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

3. WebSphere Business Modeler (business analyst) WebSphere Integration Developer (architect, developer) WebSphere Process Server (administrator) WebSphere Business Monitor (analyst, architect, administrator) Model Services Events Objective: Exploit SLAs in BPM life cycle Modelling Development Execution Monitoring Adapt to changing conditions to achieve the goals with minimal development and administrative effort Simplicity An analyst can specify goals without detailed knowledge of the implementation technologies Flexibility The requirements and implementation technologies can be independently updated End-to-end specification Requirements captured in the tools can be enforced and monitored throughout the development cycle Adaptive efficiency The system can allocate resources to meet changing requirements

4. LayerSLA MetricExample Business process CostCost of search service < $0.02 per use Fidelity/quality/utilityMap resolution > 300x300 Trust/reputationOnly use trusted payment service Deployment/ Operations Service timeExecution time < 3s ThroughputThroughput > 100/min AvailabilityUptime > 99.9% Load balanceServer utilization delta < 10% NetworkLatencyService RTT < 100ms BandwidthMax bandwidth < 3Mbps JitterDelay jitter < 10ms 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

5. SLA Optim. criteria Runtime Uses of SLAs ABCD p q Web serviceTask agent 2 1b service time < 1s ESB A,B D 1a C service time < 2s Dynamic service selection Discover services with capabilities that satisfy goals. Distributed Monitoring Only monitor the business events related to goals. Treat monitoring as a process. Feed back measurements to support runtime adaptations. Distributed execution Fine-grained allocation of process to available resources. Move portions of process to strategic locations. ESB adaptation Reconfigure the ESB topology to satisfy goals. MMM

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

7. Dynamic Process Redeployment Business process executing on nine execution engines Process hotspot varies over time No optimal static deployment Dynamic redeployment suffers temporarily after process hotspot moves Traffic with redeployment is 42% of the static case

8. Distribution cost C dist = C d3 * (C d1 + C d2 ) C d1 Message rate C d2 Message size C d3 Latency Engine cost C eng = f(C e1, C e2,C e3 ) C e1 Load (number of instances) C e2 Resources (CPU, memory, etc.) C e3 Task complexity Service cost C serv = C s1 + C s2 + C s3 C s1 Latency of external service C s2 Execution time of external service C s3 Marshalling/unmarshalling Cost(agent) = ∑w i C i Cost(process) = ∑cost(agent) The cost of a process is based on three cost components These costs can be weighted to achieve different objectives Optimize time w d1 = w d3 = w e3 = C serv = 1, other w i = 0 Optimize network overhead w d2 = w d3 = 1, other w i = 0 Various optimization criteria can be specified Threshold criteria: ∑w i C i > x E.g., Report SLA violations within 3 s. Minimized criteria: min( ∑wiCi ) E.g., Minimize distribution overhead Cost Model

9. Summary of Approach Process instrumentation. Monitoring rules generation. SLA validation. Autonomic reconfiguration to maintain SLA. Fine grained resource usage. Automatic service composition. Goal-based discovery. Distributed, scalable architecture. Real-time monitoring. Loosely coupled system. Transparent, live reconfiguration. Localize process modification. Distributed process search. Continuous search. Process monitoring Distributed executionService selection Formal SLA model Distributed event-based messaging middleware A formal SLA model can drive various stages of distributed application development. An event-based system is an enabling technology for certain features.

10. Features (Development time) SLA editor in WebSphere Integration Developer Simple and flexible way to author precise SLAs WebSphere Monitor model generator Efficiently monitor the SLA without additional development effort Event-based monitoring

11. Features (Execution Time) Distributed BPEL engine Scalable execution of large business processes Event-based interaction among activities Autonomous SLA-aware process reconfiguration Distributed optimization algorithms Decoupled event-based interactions enable reconfiguration of live process Adaptive event-based SLA monitoring Optimize monitoring overhead No additional instrumentation required A BC D E F Fault Task A done Trigger M ESB A,B D C StartTime Execution Time EndTime Execution Time SLO Charge Business Partner ESB

12. Features (Discovery) Event-based service discovery Fully distributed architecture Support a number of modes including real-time discovery Automatic service composition Search a distributed set of service repositories Utilize distributed pub/sub data structures to index service compatibility relationships Incrementally construct a DAG of candidate processes Search Request Search Result Service Agent Request Agent Pub/Sub Broker Network

13. Vision

14. Redeployment Manager Compute the cost of deploying local agents A i at candidate engines E j Given F(Ai): Cost function P(Ai): Predecessors S(Ai): Successors Measurements C(Ai): Cost at local engine E(P(Ai)): Location of predecessors E(S(Ai)): Location of successors Compute C(Ai,Ej) for every Ai,Ej: Estimated cost of deploying agent Ai at candidate engine Ej Complexity Memory: O( |Ai| |Ej| ) Computation: O( |Ai| |Ej| |N avg (Ai)| ) Cost Model

15. Varying Hotspot – Illustration DEF pq 147 Execution engineBroker Process Topology B C AI G H 2 3 5 6 8 9 AB C GI H D F E

16. Demonstration BC pq 147 Execution engineBroker Process Topology A 5 Deployer A C B ProcessID:PROCESS_3 START:TASKA GLOBALVARIABLES: acond true bcond true ccond true bprob 0.1 cprob 0.9 count 1 TaskID:TASKA PreNode:OR_SPLIT PostNode:SEQUENCE Decision PostIDs:TASKB PostPubCondition PreSubCondition:START TASKB TargetEngine:A TaskID:TASKB PreNode:OR_SPLIT PostNode:OR_JOINT Decision PostIDs:TASKXXX PostPubCondition:bcond true TASKA else TASKC PreSubCondition:TASKA TASKC TargetEngine:A TaskID:TASKC PreNode:SEQUENCE PostNode:OR_JOINT Decision PostIDs:TASKXXX PostPubCondition:ccond true TASKB else END PreSubCondition:TASKB TargetEngine:A

17. For More Information Visit http://eqosystem.msrg.utoronto.ca http://eqosystem.msrg.utoronto.ca