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


Techweb
Informationweek Business Technology Network
InformationweekInformationweek 500Informationweek 500 ConferenceInformationweek AnalyticsInformationweek Events
Informationweek MagazineGlobal CIOIWK Government ITbMightyByte and SwitchDark Reading
Digital LibraryIntelligent EnterpriseInternet EvolutionNetwork ComputingPlug Into The CloudDr. DobbsContentinople
space
TechWeb Events Network
InteropVoiceConWeb 2.0 ExpoWeb 2.0 SummitEnterprise 2.0Mobile Business ExpoNoJitter
Black HatGTECEnergy CampCloud ConnectGov 2.0 ExpoGov 2.0 Summit
space
Light Reading Communications Network
Light ReadingLight Reading AsiaUnstrungCable Digital NewsInternet EvolutionPyramid Research
Heavy ReadingLight Reading LiveLight Reading InsiderEthrnet ExpoTelco TVTower Technology Summit
space
Financial Technology Network
Advanced TradingBank Systems and TechnologyInsurance and TechnologyWall Street and TechnologyAccelerating WallstreetBST SummitBuyside Trading SummitIT Summit
space
Microsoft Technology Network
MSDNTechNetTotal IT ProTotal Dev ProNET Total Dev Pro CommunitySQL Total Dev Pro Community
space