+972 52-548-6969
Messaging Concepts - The Starbucks example
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).
Comments
Good post on this from the REST angle:
http://www.infoq.com/articles/webber-rest-workflow
Great idea for a reference implementation. I could also imagine it being useful for demonstrating use case or workflow modeling.
This was discussed in a pretty popular short essay, "Starbucks Does Not Use Two-Phase Commit", by Gregor Hohpe:
www.eaipatterns.com/ramblings/18_starbucks.html
It's definitely an excellent example of managing conversations and short-running vs. long-running processes.
IMO, the starbucks example is not an ideal reference implementation. In a well designed messaging system, clients DO NOT WAIT. This is part of making the leap from synchronous request/reply systems to asynchronous messaging.
Mike
Mike,
In SB, I can do whatever I want, and I just listen to my name (or drink) being call, in which time I am getting the drink.
I agree with Mike, 'service writes' should ideally be 'document-centric' and sent OneWay Async. Optimally it would be delivered and processed with the 'Store and Forward' messaging paradigm.
This allows you to add reliablity and removes the temporal coupling between the client and service which has the added benefit of easily being able to work offline.
I find it interesting that you order a hot chocolate and then wait for your coffee...
As long as you stay within SB and wait, then you get your coffee. This is why I don't order coffee from SB in the morning. If I place an order, then I will probably have to wait 15 minutes for the drink to arrive. With messaging, I'd rather just post my order without waiting in a line and continue on my way to work and assume the coffee will be delivered to me sometime later.
Real world scenarios rarely translate well to system design, and I'm sure someone can claim that some SB clients want to be there to enjoy the atmosphere or the wifi, but it simply does not translate to a well designed messaging system.
Ideally, messaging is asynchronous and non-blocking. Any example that can possibly be interpreted as a blocking interaction should not be regarded as a reference implementation.
Mike
It would be interesting to have cases for how customer gets updated while barista prepares the coffee like State of the Barista Process
How can you finish a venti hot chocolate all by yourself?! I find it hard to finish a tall one!!! :D
I have seen another explanation of the starbuck procedure: When customers have to wait they get annoyed and often just leave the queue. So starbucks makes sure customers place their orders ASAP - and then they just have to wait for their coffee, but without the option of leaving :)
Comment preview