Transcript test

eQoSystem:
Supporting Fluid
Distributed ServiceOriented Workflows
Vinod Muthusamy, Young Yoon, Mo Sadoghi, Arno Jacobsen
[email protected], [email protected],
[email protected], [email protected]
Middleware Systems Research Group
www.msrg.org
University of Toronto
Currently, business goals must be manually
considered at every stage of the business
process development cycle
Only trusted
partners
service time < 3s
Y
Get
destination
Validate
request
Find flight
Far?
N
cost < $0.02
Find train
Objective: Exploit SLAs in BPM life cycle
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
Modelling
WebSphere Business Modeler
(business analyst)
Model
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
Development
WebSphere Integration Developer
(architect, developer)
Services
Execution
WebSphere Process Server
(administrator)
Events
Adaptive efficiency
The system can allocate resources to
meet changing requirements
Monitoring
WebSphere Business Monitor
(analyst, architect, administrator)
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
Layer
SLA Metric
Business
process
Cost
Cost of search service < $0.02 per use
Fidelity/quality/utility
Map resolution > 300x300
Trust/reputation
Only use trusted payment service
Service time
Execution time < 3s
Throughput
Throughput > 100/min
Availability
Uptime > 99.9%
Load balance
Server utilization delta < 10%
Latency
Service RTT < 100ms
Bandwidth
Max bandwidth < 3Mbps
Jitter
Delay jitter < 10ms
Deployment/
Operations
Network
Example
Runtime Uses of SLAs
Optim.
criteria
p
Dynamic service selection
Discover services with capabilities
that satisfy goals.
A
B
SLA
C
q
D
Distributed Monitoring
Only monitor the business events
related to goals.
Treat monitoring as a process.
Feed back measurements to support
runtime adaptations.
ESB
C
A,B
M
1a
service time < 2s
1b
service time < 1s
M
Distributed execution
Fine-grained allocation of process to
available resources.
Move portions of process to strategic
locations.
D
M
Web service
ESB adaptation
Reconfigure the ESB topology to
satisfy goals.
2
Task agent
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
A
B
C
D
A
B
C
D
C
A,B
D
Agent-based
 Distributed execution engine
 In-network processing


Lower bandwidth and latency
Fine-grained use of resources
A
B
C
D
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
Cost Model
The cost of a process is based on three cost components
Distribution cost Cdist = Cd3 * (Cd1 + Cd2)
Service cost Cserv = Cs1 + Cs2 + Cs3
Cd1 Message rate
Cd2 Message size
Cd3 Latency
Cs1 Latency of external service
Cs2 Execution time of external service
Cs3 Marshalling/unmarshalling
Engine cost Ceng = f(Ce1, Ce2,Ce3)
Ce1 Load (number of instances)
Ce2 Resources (CPU, memory, etc.)
Ce3 Task complexity
Cost(agent) = ∑wiCi
Cost(process) = ∑cost(agent)
These costs can be weighted to achieve different objectives
Optimize time
Optimize network overhead
wd1 = wd3 = we3 = Cserv = 1, other wi = 0
wd2 = wd3 = 1, other wi = 0
Various optimization criteria can be specified
Threshold criteria: ∑wiCi > x
Minimized criteria: min( ∑wiCi )
E.g., Report SLA violations within 3 s.
E.g., Minimize distribution overhead
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 to
maintain 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
Features (Execution Time)
A

Distributed BPEL engine


E
Scalable execution of large business processes
Event-based interaction among activities
B
F
C
D
ESB

Autonomous SLA-aware process
reconfiguration


Distributed optimization algorithms
Decoupled event-based interactions enable
reconfiguration of live process
C
A,B
M
D
ESB

Adaptive event-based SLA monitoring


StartTime
EndTime
Optimize monitoring overhead
No additional instrumentation required
Execution
Time
Charge
Business
Partner
Execution
Time
SLO
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
Request
Agent
Pub/Sub Broker
Network
Vision
Workflow Management and Business Activity Monitoring
start
Deploy
add
remove
halt
resume
Control
Redirect
7
6
4
Visualize
Update
Business
ActivityEvents
3
Monitor
...
Workflow and Business Process Execution
Business Process
Events
Communication Abstractions
Publish/Subscribe
Point-to-Point
Request/Reply
Communication
Events
Orchestration
Content-based Routing
Business Process
Execution Events
Clients (publisher/subscriber)
Content-based Router
Computers
Computers
Laptops
Computers
4
CA*net
Switch
Server Farm
Database
Switch
Network and
System Events
Server Database
Server
Switch
Server
Laptops
Computing, Storage, Instruments and Networking Resources
Event Management
Framework
Redeployment Manager

Compute the cost of deploying local agents Ai
at candidate engines Ej
Measurements
C(Ai): Cost at local engine
E(P(Ai)): Location of predecessors
E(S(Ai)): Location of successors
Given
F(Ai): Cost function
P(Ai): Predecessors
S(Ai): Successors
Cost Model
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
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
A
1
4
Deployer
7
C
B
Broker
Execution engine
For More Information
Visit
http://eqosystem.msrg.utoronto.ca