As you may have read, I’ve been working on some MSMQ configuration and
coding for the last little while.  In the past I had always heard
“Asynchronous System” and hid under my desk where the left over
Skittles, M&Ms and Smarties are kept.  Looking back on the
code that I’ve written thus far, and forward to the code I know I’m
writing this week, I have to say that the MSMQ technology is not that
difficult to work with.  The .NET namespace nicely encapsulates
all that is needed (Queue and Message) and the amount of code required
to actually send, retrieve or peek a message is minimal.

Where the difficulty arises is in the application of the code. 
Most of the places I’ve worked in the past have had an architect at the
keyboard philosophy and perhaps that is why the technology seemed so
daunting.  The amount of scenarios, both technical and business,
that you must consider are enormous.  What do you do if you run
into a connectivity error when processing the message?  Put it
back on the source Queue?  Ship it to the Dead Letter Queue? 
What if the connectivity error occurs and then you can no longer write
to any Queue?  Is writing the error to the Event Log
acceptable?  On and on and on and on you can go.

I probably wrote no more than 25 to 50 lines of code to access 2
different Queues.  I also wrote about 300 to 500 lines of code to
handle the potential gotchas of an asynchronous system.  Don’t be
scared of asynch, but allocate enourmous time for planning and
preparing for all the different scenarios.