Rhino Service BusThe Starbucks example
Yesterday I finally completed the Starbucks sample for Rhino Service Bus. It is surprising to see how many aspects that little sample required.
There are several of highlights in the sample.
- There are three actors in the application:
- Barista
- Cashier
- Customer
- There is zero setup necessary, Rhino Service Bus will create the queues if they don’t already exists. Again, the idea of reducing moving parts.
- All three actors are running in the same process – but each is running in a different AppDomain.
Note that this is a common deployment choice for development, but not one that I would use for production.
The idea is that this make it significantly easier to debug & develop a distributed application. - There is very little configuration whatsoever. And a lot of conventions about how to figure out what consumers to use and how to build it.
- The use of sagas & conversations is demoed. The entire buying process is a single conversation composed of several sagas.
- The customer actor is showing how we can create instance & temporary subscriptions.
More posts in "Rhino Service Bus" series:
- (08 Aug 2009) DHT Saga Sate Persisters Options
- (21 Jan 2009) Concurrency Violations are Business Logic
- (19 Jan 2009) Concurrency in a distributed world
- (16 Jan 2009) Saga and State
- (15 Jan 2009) Field Level Security
- (14 Jan 2009) Understanding a Distributed System
- (14 Jan 2009) The Starbucks example
- (14 Jan 2009) Locality and Independence
- (14 Jan 2009) Managing Timeouts
Comments
Thanks Ayende!
This is a great setup for most all my service bus needs right now
Especially the use of the sagas/conversations piece
What's the reasoning behind the use of the term 'saga'? To me, a saga is an epic tale (a long story), not a part of a single conversation.
See the discussion here:
ayende.com/.../...s-conversation-saga-message.aspx
Thanks for your work, please would you guide me to where I can download the Bus and the Startbucks example. Thanks
rhino-tools.svn.sourceforge.net/.../trunk/
can you comment on why the consumer's instance subscriptions are stored in the "subscription" subqueue of the cashier and just in queue messages in the barista?
I am not sure that I understand the question
Inspecting the customer's two instance subscriptions using "Computer Management>Message Queuing" during debugging, you can see that the "DrinkReady" temp subscription is in "starbucks.barista\Queue messages" while the "PaymentDue" temp subscription is in "starbucks.cashier\subscriptions".
I was just wondering about this difference in design.
You caught this in a moment in time.
Instance subscriptions are not kept in the main queue
Comment preview