20.01.2015 Views

Performance Modeling and Benchmarking of Event-Based ... - DVS

Performance Modeling and Benchmarking of Event-Based ... - DVS

Performance Modeling and Benchmarking of Event-Based ... - DVS

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4.2. PERFORMANCE MODELING PATTERN 59<br />

Pattern 6: Request Controlled Pull I<br />

Timer<br />

1‘Sleep!<br />

T3<br />

Trigger<br />

Store<br />

1‘<strong>Event</strong>!<br />

1‘<strong>Event</strong> 1‘<strong>Event</strong> 1‘<strong>Event</strong> 1‘<strong>Event</strong><br />

Producer<br />

T1<br />

Broker<br />

T2<br />

Consumer<br />

T2-I: Pull <strong>Event</strong><br />

T3-I: Consumer is ready<br />

Broker<br />

<strong>Event</strong><br />

Trigger Store<br />

Trigger<br />

T2-II: Go to sleep<br />

Broker<br />

Trigger<br />

1<br />

1<br />

1<br />

1<br />

1<br />

Consumer<br />

<strong>Event</strong><br />

Timer<br />

Sleep<br />

Consumer<br />

<strong>Event</strong><br />

Timer<br />

Sleep<br />

1<br />

T3-II: Wake up<br />

1<br />

1<br />

1<br />

Trigger Store<br />

Trigger<br />

Trigger Store<br />

Trigger<br />

Figure 4.14: St<strong>and</strong>ard Pull Patterns<br />

Characteristics<br />

• Pull-based communication on dem<strong>and</strong><br />

• Resource modeling (number <strong>of</strong> service places)<br />

Example<br />

An event consumer connects frequently to a broker to check whether notifications are waiting.<br />

If yes, the consumer downloads one <strong>of</strong> them, closes the connection <strong>and</strong> processes the event<br />

notification. As soon as the event has been processed the consumer connects again to the broker<br />

to pull the next event. If no event is available, the consumer closes the connection <strong>and</strong> waits for<br />

a specified period <strong>of</strong> time before pursuing the next pull attempt.<br />

Description<br />

This scenario differs mainly from the previous ones in that the pull attempt <strong>of</strong> the consumer is<br />

not only controlled by time but also by the availability <strong>of</strong> the consumer. The consumer tries<br />

to pull the next event as soon as he is ready, i.e. after the last event was processed. Only if<br />

no further event is available at the depository <strong>of</strong> the broker, the consumer disconnects <strong>and</strong> the<br />

next connection is triggered after a specified time interval.<br />

This behavior is reflected in transitions 2 & 3. When the consumer has processed an event,<br />

the <strong>Event</strong> token is transformed by transition 3-I to a Trigger token. Next, transition 2 is fired.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!