FREE Subscription to Dr. Dobb’s Digest: Same Great Content, New Digital Edition
Site Archive (Complete)
Architecture Blog: Queues Are Databases: Round Two
Architecture & Design
PATTERN LANGUAGE

Modeling, Managing, Making it Right.

by Jonathan Erickson
IF YOU BUILD IT

... Will they Come?

by Arnon Rotem-Gal-Oz
October 20, 2006

Queues Are Databases: Round Two

Udi Dahan commented (in his blog) on my last post.

Udi mostly agreed with what I said but commented on the SQL 2005 Service broker features I described: "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)".

What Udi said to that was:

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.

First, Udi is right in that the example I used was lame; I was merely trying to explain the feature by a simple example. Nevertheless, since service consumers are sometimes humans and not just other services, you might have a situation where this would occur; e.g., someone submits an order, then has a "duh" moment and adds another line (you can argue that it is better to repost the whole order in this case, but what if bandwidth is very low; e.g., GPRS). Okay, so this is an extreme example. Another (much more common) situation is what is known as a "Saga" -- a series of messages that goes back and forth between two (or more) services in a long running session. There is an advantage of using an infrastructure that gives you message correlation out of the box.

So yes, you need to try to tell a "complete story" for each message. You may still have situations where you need two or more related messages to paint a coherent and complete picture (just try not to make that the norm...)

Posted by Arnon Rotem-Gal-Oz at 11:25 AM  Permalink




 
INFO-LINK