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.

124 CHAPTER 6. PERFORMANCE MODELING OF EBS - CASE STUDIES<br />

1‘PriceUpdate !<br />

" n‘PriceUpdateN<br />

1‘PriceUpdate 1‘PriceUpdate 1‘PriceUpdateN<br />

I3_2<br />

1‘PriceUpdateN<br />

HQ<br />

I3_1<br />

HQ_PriceUpdateT<br />

I3_3<br />

SMs<br />

1‘InventoryInfo 1‘InventoryInfo 1‘InvInfoRegister 1‘InvInfoRegister<br />

SMs<br />

I4_1<br />

SM_InvMovementQ<br />

I4_2<br />

SMs<br />

1‘StatInfoSM 1‘StatInfoSM 1‘StatInfoSM 1‘StatInfoSM<br />

SMs<br />

I5_1<br />

HQ_SMStatsQ<br />

I5_2<br />

HQ<br />

1‘ProdAnnounce !<br />

" n‘ProdAnnounceN<br />

I6_2<br />

1‘ProdAnnounce 1‘ProdAnnounce 1‘ProdAnnounceN<br />

1‘ProdAnnounceN<br />

HQ<br />

I6_1<br />

HQ_ProductAnnouncementT<br />

I6_3<br />

SMs<br />

1‘CreditCardHL !<br />

" n‘CreditCardHL_N<br />

I7_2<br />

1‘CreditCardHL 1‘CreditCardHL 1‘CreditCardHL_N<br />

1‘CreditCardHL_N<br />

HQ<br />

I7_1<br />

HQ_CreditCardHotlistT<br />

I7_3<br />

SMs<br />

Figure 6.3: Models <strong>of</strong> Interactions 3, 4, 5, 6 <strong>and</strong> 7<br />

Each <strong>of</strong> these messages is forwarded by transition I3_3 to place SMs representing the machine<br />

hosting the SMs. Interactions 4 to 7 are modeled similarly.<br />

We now look at Interactions 1 <strong>and</strong> 2 whose models are shown in Figures 6.4 <strong>and</strong> 6.5, respectively.<br />

The workflow <strong>of</strong> the interactions can be traced by following the transitions in the<br />

order <strong>of</strong> their suffixes, i.e., I1_1, I1_2, I1_3, etc. In Interaction 2, the CallForOffers message<br />

is sent to a HQ_ProductFamilyT topic where n represents the respective product family.<br />

The CallForOffers message is then transformed to x CallForOffersN messages representing<br />

the respective notification messages forwarded to the SPs (transition I2_2_FindSubscribers).<br />

Each SP sends an <strong>of</strong>fer (Offer message) to the DC <strong>and</strong> one <strong>of</strong> the <strong>of</strong>fers is selected by transition<br />

I2_6 which takes the x <strong>of</strong>fers as input <strong>and</strong> generates a purchase order (POrder message)<br />

sent to the SP_POrderQ queue. The rest <strong>of</strong> the workflow is similar to Interaction 1.<br />

Mapping <strong>of</strong> Logical to Physical Resources<br />

The case study presented exploits the ability to share queues in multiple queueing places by<br />

decoupling the logical (s<strong>of</strong>tware) <strong>and</strong> physical (hardware) layers <strong>of</strong> the modeled system. Therefore,<br />

the same logical model <strong>of</strong> the benchmark interactions can be easily customized to different<br />

deployment environments. The results presented in this case study can be seen as a validation

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

Saved successfully!

Ooh no, something went wrong!