Event-Driven Architectures: Tom Van Cutsem

2006 Tom Van Cutsem - Programming Technology Lab
Event-driven
Architectures
Tom Van Cutsem
Programming Vrije Universiteit

Technology Lab Brussel
1
Overview
Event-driven Programming Model
Event-driven Programming Techniques
Event-driven Architectures
2
Call versus Event
call fire event

call
fire event
return return
fire event
Programming without a call stack
Much more flexible interactions
But... free synchronization & context are gone
3
Event-driven Model
4
Event-driven Model
Events
4
Event-driven Model
Event Queue
Events
4
Event-driven Model
Event Queue
Events
Event Loop
while (true) {
Event e = eventQueue.next();
switch (e.type) {
...
}
}
4
Event-driven Model
Event Queue
Events
Event Loop Event handlers
void onKeyPressed(KeyEvent e) {
// process the event
}
4
Examples
GUI Frameworks (e.g. Java AWT)
Highly interactive applications (e.g. games)
Operating Systems
Discrete Event Modelling (e.g. simulations)
5
Event-loop Concurrency
6
6
6
6
No locks, no deadlocks
No shared state, no race conditions
6
Event-driven
Programming
Return values
DeliveryService CustomerService
requestAddress
shipToRequest
void processDelivery(Order o) {
// request customers address
Address a = customerService.requestAddress(o.customerId));
courier.shipToRequest(o, a);
}
8
Callbacks
Dealing with asynchronous return values
// store order to retrieve it later
DeliveryService CustomerService orders.add(o);
customerService.receive(
requestAddress new RequestAddress(o.orderId, o.customerId));
}
replyAddress
shipToRequest
9
Callbacks
Dealing with asynchronous return values
// store order to retrieve it later
DeliveryService CustomerService orders.add(o);
customerService.receive(
requestAddress new RequestAddress(o.orderId, o.customerId));
}
replyAddress void replyAddress(AddressReply reply) {

shipToRequest // retrieve order again
Order o = orders.get(reply.orderId);
Address a = reply.address;
courier.receive(new ShipToRequest(o, a));
}
9
Issues with Callbacks

Fragmented Code
Callback is out of context: requestAddress
? requestAddress
what is its originating call?
replyAddress
what was the state (e.g. replyAddress
local variables) when call
was made?
10
Futures
Placeholders for asynchronous return values
Typically synchronize when used
Future addressFuture = customerService.receive(
f := requestAddress
new RequestAddress(o.customerId));
// do things that dont require address
f.get()
f.resolve(address) Address adr = (Address) addressFuture.get();
courier.receive(new ShipToRequest(o, adr));
}
shipToRequest
11
Asynchronous Futures
Subscription of listeners that are executed
when return value is available
DeliveryService CustomerService void processDelivery(Order o) {

Future addressFuture = customerService.receive(
new RequestAddress(o.customerId));
f := requestAddress addressFuture.addListener(new FutureListener() {
void whenComputed(Result r) {
Address adr = (Address) r;
courier.receive(new ShipToRequest(o, adr));
f.resolve(address) }
});
shipToRequest }
12
Event-driven
Architecture
Event-driven Architecture
A program is composed of services
Services communicate via channels
checkout orderPlaced orderProcessed

Shopping Order Stock
Service Service Service
orderProcessed orderPayed
Billing Delivery
Service Service
14
Channels
Point-to-point: fixed endpoints
Publish-subscribe: very loose coupling
Example: Model-View-Controller
15
Channels
Model
Votes
yes 41
no 44
abstain 15
15
Channels
Model Views
45
30
Votes 15
0
yes 41 15%
no 44 41%
44%
abstain 15
0 33 67 100
15
Channels
Model Views
45
subscribe 30
Votes 15
0
yes 41 15%
no 44 41%
44%
abstain 15
0 33 67 100
15
Channels
Model Views
45
30
Votes 15
0
yes 41 15%
no 44 41%
44%
abstain 15
publish events
0 33 67 100
15
Composing Services
Service Repository
Root
Topic hierarchy:
Orders Payment
Wildcard subscriptions Updates New

Credit
Card
Additional level of Online Fax
abstraction
Provider publish Service subscribe Client

Service Repository Service
16
EDA: Benefits
Services are highly reusable
Highly reconfigurable (e.g. upgrades)
Service
cancel subscription subscribe
Old Replacement
Service Service
synchronize
retire
17
EDA: Benefits
Unit Testing: testing services in isolation
Provider Client
Service Service
Service
under test
Mock-up
Test Driver
service
Provides test data Verifies outgoing events
18
EDA: Benefits
Temporal decoupling:
services cannot block one another
more responsive applications
19
EDA: Benefits
Adaptor services easily introduced:
logging events
authenticating events
matching events to an updated interface
...
Service A Adaptor Service B
20
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
EDA: Drawbacks
Temporal decoupling: non-determinism
Events may arrive in arbitrary order
make as little assumptions as possible on

ordering
22
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 state

23
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
References
Enterprise Integration Patterns The Power of Events
Gregor Hohpe and Bobby Woolf David Luckham
Addison-Wesley Addison-Wesley
Concurrency among Strangers

Miller, Tribble and Shapiro
In Symposium on Trustworthy global computing, LNCS Vol 3705, pp. 195-229, 2005
Programming without a call stack

Gregor Hohpe
Available online: www.enterpriseintegrationpatterns.com
Concurrent Object-oriented Programming

Gul Agha
In Communications of the ACM, Vol 33 (9), p. 125, 1990
25

Event-Driven Architectures: Tom Van Cutsem

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Event-Driven Architectures: Tom Van Cutsem

Încărcat de

Drepturi de autor:

Formate disponibile

2006 Tom Van Cutsem - Programming Technology Lab

Programming Vrije Universiteit

Event-driven Programming Model

Event-driven Programming Techniques

Call versus Event

call fire event

Programming without a call stack

Much more flexible interactions

But... free synchronization & context are gone

Event Loop Event handlers

Highly interactive applications (e.g. games)

Discrete Event Modelling (e.g. simulations)

No shared state, no race conditions

replyAddress void replyAddress(AddressReply reply) {

Issues with Callbacks

Typically synchronize when used

DeliveryService CustomerService void processDelivery(Order o) {

Services communicate via channels

checkout orderPlaced orderProcessed

Publish-subscribe: very loose coupling

Publish-subscribe: very loose coupling

Publish-subscribe: very loose coupling

Publish-subscribe: very loose coupling

Publish-subscribe: very loose coupling

Wildcard subscriptions Updates New

Provider publish Service subscribe Client

Highly reconfigurable (e.g. upgrades)

cancel subscription subscribe

Provides test data Verifies outgoing events

services cannot block one another

more responsive applications

matching events to an updated interface

Service A Adaptor Service B

Loose coupling: implicit control flow

makes source code harder to understand

less compile-time checks, unit testing even

tool support required for easy

Temporal decoupling: non-determinism

Events may arrive in arbitrary order

make as little assumptions as possible on

strong guarantees but...

kills asynchrony in the system

Optimistic synchronization (e.g. compensating

works entirely asynchronously but...

system (temporarily) in inconsistent state

With flexibility comes more responsibility:

EDA: emphasis on loose coupling

Services easily reused

Concurrency becomes manageable

Concurrency among Strangers

Programming without a call stack

Concurrent Object-oriented Programming

S-ar putea să vă placă și