Event-driven Architectures - Vrije Universiteit...

Preview:

Citation preview

© 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

Recommended