1 / 15

Far?

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.

sarah
Download Presentation

Far?

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. eQoSystem: Supporting Fluid Distributed Service-Oriented WorkflowsVinod Muthusamy, Young Yoon, Mo Sadoghi, Arno Jacobsenmuthusamy@eecg.toronto.edu, yoon@msrg.utoronto.ca, mo@cs.toronto.edu, jacobsen@eecg.toronto.eduMiddleware Systems Research Groupwww.msrg.orgUniversity of Toronto

  2. 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

  3. Objective: Exploit SLAs in BPM life cycle 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 WebSphere Business Modeler(business analyst) Model Development WebSphere Integration Developer(architect, developer) Services Execution WebSphere Process Server(administrator) Events Monitoring WebSphere Business Monitor(analyst, architect, administrator)

  4. 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. M M M p q A B C D Web service Task agent Runtime Uses of SLAs Optim.criteria SLA Dynamic service selectionDiscover services with capabilities that satisfy goals. Distributed MonitoringOnly monitor the business events related to goals.Treat monitoring as a process.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 service time < 1s 1b D 2

  6. AB C D AB C D AB C D C A,B D Process Execution Architectures Clustered • Replicated execution engines • Centralized control and data • High bandwidth and latency • Still may not scale 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

  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. Cost Model The cost of a process is based on three costcomponents Distribution cost Cdist = Cd3 * (Cd1 + Cd2) Cd1 Message rate Cd2 Message size Cd3Latency Engine cost Ceng = f(Ce1, Ce2,Ce3) Ce1 Load (number of instances) Ce2 Resources (CPU, memory, etc.) Ce3 Task complexity 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

  9. Summary of Approach 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. Process monitoring Distributed execution Service selection Distributed, scalable architecture. Real-time monitoring. Loosely coupled system. Transparent, live reconfiguration. Localize process modification. Distributed process search. Continuous search. An event-based system is an enabling technology for certain features. Distributed event-based messaging middleware

  10. 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 ESB StartTime EndTime Charge Business Partner ExecutionTime ExecutionTimeSLO A E B C F D Task A done Trigger Fault ESB C A,B M D

  11. 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 Service Agent Search Result Pub/Sub Broker Network Request Agent

  12. Vision

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

  14. Demonstration ProcessID:PROCESS_3 START:TASKA GLOBALVARIABLES:acond true bcond true ccond true bprob 0.1 cprob 0.9 count 1 <TASK> TaskID:TASKA PreNode:OR_SPLIT PostNode:SEQUENCE Decision PostIDs:TASKB PostPubCondition PreSubCondition:START TASKB TargetEngine:A </TASK> <TASK> TaskID:TASKB PreNode:OR_SPLIT PostNode:OR_JOINT Decision PostIDs:TASKXXX PostPubCondition:bcond true TASKA else TASKC PreSubCondition:TASKA TASKC TargetEngine:A </TASK> <TASK> TaskID:TASKC PreNode:SEQUENCE PostNode:OR_JOINT Decision PostIDs:TASKXXX PostPubCondition:ccond true TASKB else END PreSubCondition:TASKB TargetEngine:A </TASK> Process p q A B C Topology 5 Deployer A 1 4 7 C B Broker Execution engine

  15. For More Information Visithttp://eqosystem.msrg.utoronto.ca

More Related