EQoSystem: Supporting Fluid Distributed Service- Oriented Workflows Vinod Muthusamy, Young Yoon, Mo Sadoghi, Arno Jacobsen muthusamy@eecg.toronto.edu,
Post on 02-Jan-2016
217 Views
Preview:
Transcript
eQoSystem: Supporting Fluid
Distributed Service-Oriented Workflows
Vinod Muthusamy, Young Yoon, Mo Sadoghi, Arno Jacobsenmuthusamy@eecg.toronto.edu, yoon@msrg.utoronto.ca,
mo@cs.toronto.edu, jacobsen@eecg.toronto.edu
Middleware Systems Research Groupwww.msrg.org
University of Toronto
Currently, business goals must be manually considered at every stage of the business
process development cycle
N
Y
Far?Get
destinationValidaterequest
Find flight
Find train
cost < $0.02
service time < 3s
Only trusted partners
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
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
Layer SLA Metric Example
Business process
Cost Cost of search service < $0.02 per use
Fidelity/quality/utility Map resolution > 300x300
Trust/reputation Only use trusted payment service
Deployment/ Operations
Service time Execution time < 3s
Throughput Throughput > 100/min
Availability Uptime > 99.9%
Load balance Server utilization delta < 10%
Network Latency Service RTT < 100ms
Bandwidth Max bandwidth < 3Mbps
Jitter Delay jitter < 10ms
Service Level AgreementsSLAs 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
SLA
Optim.criteria
Runtime Uses of SLAs
A B C D
p
q
Web service Task agent
2
1b service time < 1s
ESB
A,B
D
1a
C
service time < 2s
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.
M
M
M
Process Execution ArchitecturesCentralized 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
ABCD
ABCD
ABCD
D
C
A,B
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
Distribution cost Cdist = Cd3 * (Cd1 + Cd2)Cd1 Message rateCd2 Message sizeCd3 Latency
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 serviceCs2 Execution time of external serviceCs3 Marshalling/unmarshalling
Cost(agent) = ∑wiCi
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 timewd1 = wd3 = we3 = Cserv = 1, other wi = 0
Optimize network overheadwd2 = 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
Cost Model
Summary of Approach
Process instrumentation.Monitoring rules generation.
SLA validation.
Autonomic reconfiguration tomaintain 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 execution Service 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.
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
B C
D
E
F
Fault
Task A doneTrigger
M
ESB
A,B
D
C
StartTime
ExecutionTime
EndTime
ExecutionTimeSLO
Charge Business
Partner
ESB
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
Server Farm
Computers
ComputersDatabase
Laptops
Computers
Laptops
Database Server
Server
Deploy Control UpdateVisualize
Monitor ...
6
43
7
Content-based Routing
Workflow and Business Process Execution
start halt
Workflow Management and Business Activity Monitoring
Redirectresume
addremove
Content-based RouterClients (publisher/subscriber)
Switch
Server
Switch
Computing, Storage, Instruments and Networking Resources
Event ManagementFramework
BusinessActivityEvents
Business ProcessEvents
Business ProcessExecution Events
Network andSystem Events
Switch
CA*net 4
CommunicationEvents
Publish/Subscribe Point-to-Point Request/Reply Orchestration
Communication Abstractions
Vision
Redeployment Manager Compute the cost of deploying local agents A i at
candidate engines Ej
GivenF(Ai): Cost functionP(Ai): PredecessorsS(Ai): Successors
MeasurementsC(Ai): Cost at local engineE(P(Ai)): Location of predecessorsE(S(Ai)): Location of successors
ComputeC(Ai,Ej) for every Ai,Ej:
Estimated cost of deploying agent Ai at candidate engine Ej
ComplexityMemory: O( |Ai| |Ej| )
Computation: O( |Ai| |Ej| |Navg(Ai)| )Cost Model
Demonstration
B C
p q
1 4 7
Execution engineBroker
Process
Topology
A
5 Deployer
A C B
ProcessID:PROCESS_3START:TASKAGLOBALVARIABLES: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>
top related