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:
- 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
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:
Thanks for your work, please would you guide me to where I can download the Bus and the Startbucks example. Thanks
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