This post originated from an RSS feed registered with .NET Buzz
by Udi Dahan.
Original Post: Databases are queues are services are elephants are...
Feed Title: Udi Dahan - The Software Simplist
Feed URL: http://feeds.feedburner.com/UdiDahan-TheSoftwareSimplist
Feed Description: I am a software simplist. I make this beast of architecting, analysing, designing, developing, testing, managing, deploying software systems simple.
This blog is about how I do it.
Arnon gave a nice writeup of one of the sessions at our recent meeting. The whole SOA thing came up again, but this time in the context of databases; so called Service Oriented Data Architectures (SODA). One of the points made in favour of SODA rested upon a thesis Jim Gray wrote a while ago entitled "Queues are databases". Anyway, I won't belabor the point seeing as Arnon handled that one.
What I do want to call out is Sql Server Service Broker's hard-won feature of only-once and in-order delivery. From Arnon's post:
"You can add readers to empty queues faster, and lock all related messages that are read by one of the readers (so you won't have a situation where one reader reads the order and another reads the same order's order-line before the first even updated the order into the database)."
And here's the kicker. Modeling your messages in such a way is a rather poor design. Why on earth would you take an Aggregate Root like an Order, and split it up into multiple messages - orderlines and the order itself separate?
It cracks me up time and time again. Some new fangled product bends over backwards trying to support some really hard feature, which is then touted as a key strength, which, in turn, makes more developers work that way. If you design your messages properly, you won't have any problem adding "readers" even without using Service Broker.
Previous Topic
