event-driven architectures - vrije universiteit...
TRANSCRIPT
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Architectures
Tom Van Cutsem
1
Programming Technology Lab
Vrije Universiteit Brussel
© 2006 Tom Van Cutsem - Programming Technology Lab
Overview
Event-driven Programming Model
Event-driven Programming Techniques
Event-driven Architectures
2
© 2006 Tom Van Cutsem - Programming Technology Lab
Call versus Event
Programming without a call stack
Much more flexible interactions
But... free synchronization & context are gone
3
call
return
call
return
fire event
fire event
fire event
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Model
4
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Model
4
Events
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Model
4
Events Event Queue
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Model
4
Events Event Queue
Event Loopwhile (true) { Event e = eventQueue.next(); switch (e.type) { ... }}
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Model
4
Events Event Queue
Event Loop Event handlers
void onKeyPressed(KeyEvent e) { // process the event}
© 2006 Tom Van Cutsem - Programming Technology Lab
Examples
GUI Frameworks (e.g. Java AWT)
Highly interactive applications (e.g. games)
Operating Systems
Discrete Event Modelling (e.g. simulations)
5
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-loop Concurrency
6
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-loop Concurrency
6
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-loop Concurrency
6
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-loop Concurrency
6
© 2006 Tom Van Cutsem - Programming Technology Lab
No locks, no deadlocks
No shared state, no race conditions
Event-loop Concurrency
6
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Programming
© 2006 Tom Van Cutsem - Programming Technology Lab
Return values
8
void processDelivery(Order o) { // request customer’s address Address a = customerService.requestAddress(o.customerId)); courier.shipToRequest(o, a);}
requestAddress
DeliveryService CustomerService
shipToRequest
© 2006 Tom Van Cutsem - Programming Technology Lab
Callbacks
Dealing with asynchronous ‘return values’
9
void processDelivery(Order o) { // store order to retrieve it later orders.add(o); // request customer’s address customerService.receive( new RequestAddress(o.orderId, o.customerId));}
requestAddress
replyAddress
DeliveryService CustomerService
shipToRequest
© 2006 Tom Van Cutsem - Programming Technology Lab
Callbacks
Dealing with asynchronous ‘return values’
9
void processDelivery(Order o) { // store order to retrieve it later orders.add(o); // request customer’s address customerService.receive( new RequestAddress(o.orderId, o.customerId));}
void replyAddress(AddressReply reply) { // retrieve order again Order o = orders.get(reply.orderId); Address a = reply.address; courier.receive(new ShipToRequest(o, a));}
requestAddress
replyAddress
DeliveryService CustomerService
shipToRequest
© 2006 Tom Van Cutsem - Programming Technology Lab
Issues with Callbacks
Fragmented Code
Callback is out of context:
what is its originating call?
what was the state (e.g. local variables) when call was made?
requestAddress
replyAddress
DeliveryService CustomerService
requestAddress
replyAddress
?
10
© 2006 Tom Van Cutsem - Programming Technology Lab
Futures
Placeholders for asynchronous return values
Typically synchronize when used
11
void processDelivery(Order o) { Future addressFuture = customerService.receive( new RequestAddress(o.customerId)); // do things that don’t require address Address adr = (Address) addressFuture.get(); courier.receive(new ShipToRequest(o, adr));}
f := requestAddress
f.resolve(address)
DeliveryService CustomerService
f.get()
shipToRequest
© 2006 Tom Van Cutsem - Programming Technology Lab
Asynchronous Futures
Subscription of listeners that are executed when return value is available
12
void processDelivery(Order o) { Future addressFuture = customerService.receive( new RequestAddress(o.customerId)); addressFuture.addListener(new FutureListener() { void whenComputed(Result r) { Address adr = (Address) r; courier.receive(new ShipToRequest(o, adr)); } });}
f := requestAddress
f.resolve(address)
DeliveryService CustomerService
shipToRequest
© 2006 Tom Van Cutsem - Programming Technology Lab
Event-driven Architecture
© 2006 Tom Van Cutsem - Programming Technology Lab
A program is composed of services
Services communicate via channels
Event-driven Architecture
14
Delivery Service
Stock Service
Billing Service
Order Service
Shopping Service
orderPlaced
orderPayedorderProcessed
checkout orderProcessed
© 2006 Tom Van Cutsem - Programming Technology Lab
ChannelsPoint-to-point: fixed endpoints
Publish-subscribe: very loose coupling
Example: Model-View-Controller
15
© 2006 Tom Van Cutsem - Programming Technology Lab
ChannelsPoint-to-point: fixed endpoints
Publish-subscribe: very loose coupling
Example: Model-View-Controller
15
yes 41no 44
abstain 15
Model
Votes
© 2006 Tom Van Cutsem - Programming Technology Lab
ChannelsPoint-to-point: fixed endpoints
Publish-subscribe: very loose coupling
Example: Model-View-Controller
15
0153045
15%
44%41%
0 33 67100
Views
yes 41no 44
abstain 15
Model
Votes
© 2006 Tom Van Cutsem - Programming Technology Lab
ChannelsPoint-to-point: fixed endpoints
Publish-subscribe: very loose coupling
Example: Model-View-Controller
15
0153045
15%
44%41%
0 33 67100
Views
yes 41no 44
abstain 15
Model
Votessubscribe
© 2006 Tom Van Cutsem - Programming Technology Lab
ChannelsPoint-to-point: fixed endpoints
Publish-subscribe: very loose coupling
Example: Model-View-Controller
15
0153045
15%
44%41%
0 33 67100
Views
yes 41no 44
abstain 15
Model
Votes
publish events
© 2006 Tom Van Cutsem - Programming Technology Lab
Composing Services
Service Repository
Topic hierarchy:
Wildcard subscriptions
Additional level of abstraction
Service Repository
Client Service
Provider Service
publish subscribe
Root
Orders
Updates New
Online Fax
Payment
Credit Card
16
© 2006 Tom Van Cutsem - Programming Technology Lab
EDA: Benefits
Services are highly reusable
Highly reconfigurable (e.g. upgrades)
17
Old Service
Service
Replacement Service
retire
cancel subscription
synchronize
subscribe
© 2006 Tom Van Cutsem - Programming Technology Lab
EDA: Benefits
Unit Testing: testing services in isolation
18
Service under test
Client Service
Provider Service
Test Driver Mock-up service
Provides test data Verifies outgoing events
© 2006 Tom Van Cutsem - Programming Technology Lab
EDA: Benefits
Temporal decoupling:
services cannot block one another
more responsive applications
19
© 2006 Tom Van Cutsem - Programming Technology Lab
Adaptor services easily introduced:
logging events
authenticating events
matching events to an updated interface
...
EDA: Benefits
20
Service A Service BAdaptor
© 2006 Tom Van Cutsem - Programming Technology Lab
EDA: Drawbacks
Loose coupling: implicit control flow
makes source code harder to understand
less compile-time checks, unit testing even more critical
tool support required for easy visualization and composition validation
21
© 2006 Tom Van Cutsem - Programming Technology Lab
EDA: Drawbacks
Temporal decoupling: non-determinism
Events may arrive in arbitrary order
make as little assumptions as possible on ordering
22
© 2006 Tom Van Cutsem - Programming Technology Lab
Failure Handling
Pessimistic synchronization (e.g. 2PC protocol)
strong guarantees but...
kills asynchrony in the system
Optimistic synchronization (e.g. compensating actions)
works entirely asynchronously but...
system (temporarily) in inconsistent state23
© 2006 Tom Van Cutsem - Programming Technology Lab
Conclusions
Event-driven programming = programming without a call stack
With flexibility comes more responsibility: return values, local state, ordering, ...
EDA: emphasis on loose coupling
Services easily reused
Concurrency becomes manageable
24
© 2006 Tom Van Cutsem - Programming Technology Lab
Concurrency among StrangersMiller, Tribble and ShapiroIn Symposium on Trustworthy global computing, LNCS Vol 3705, pp. 195-229, 2005
Enterprise Integration PatternsGregor Hohpe and Bobby WoolfAddison-Wesley
References
25
The Power of EventsDavid LuckhamAddison-Wesley
Programming without a call stackGregor HohpeAvailable online: www.enterpriseintegrationpatterns.com
Concurrent Object-oriented ProgrammingGul AghaIn Communications of the ACM, Vol 33 (9), p. 125, 1990