During KaizenConf, we discussed the notion of messaging as a first level concept quite a bit. I have already spoken about this at length, but I think that there is still a lot of room to talk about actual implementation and architecture details.
The example that was chosen as the reference implementation for Mass Transit reference implementation was Starbucks. This is a concept that should be familiar to most programmers, while at the same time offering us a good way of exploring quite a few messaging concepts.
The scenario in the example is simple, I want to order a venti hot chocolate. Let us explore how this is done:
- I (client) ask the cashier (external facing service) for a venti hot chocolate.
- The cashier informs the barista (internal service) that a new order for venti hot chocolate has arrived.
- The barista starts preparing the drink.
- The cashier starts the payment process (credit card auth, or just counting change).
- When the cashier finishes the payment process, he tells the barista that the payment process is done.
- I (client) move to the outgoing coffee stand, and wait for my coffee.
- The barista finishes preparing the drink, check that the payment for this order was done, and serve the drink.
- I pick up my drink, and the whole thing is finished.
As you can see, there are a lot of steps invovles in the process, and that is just the plain all success story. We have cases in which the cashier finish the payment process before the the barista starts, cases where I forget to pick up the drink, cases where the authorization fails after the drink is done, etc.
All of those scenarios represent a really good background for discussing messaging scenarios, patterns and applications. This will also be the default topic that I'll use for messaging scenarios (much the same way that the blog & payroll are my default examples for data and behaviors).