MSMQ vs Temporary Table Dump

I know this question has been asked a bit before. But looking around I still cant make my mind up which route I should go down. Here's my scenario, hopefully you can help out:

We will have a series of web services that will be hit on a scheduled basis by hundreds of mobile applications. These services will data on the device with new information both going to the devices and coming back from them. The data returned from the devices will need to update a single central SQL server database that also feeds several desktop applications and a website.

In order to reduce the amount of time for the request/response of these services we have decided to process data coming in from the devices after the fact by either sticking them in an MSMQ instance or storing the serialized objects in a temporary data store and having a windows service process them later.

So there's my choices, but aside from this here's a few more things that might help you guys advise me:

The data returned from the devices will not be returned in smaller message packets that need to be ordered server side.
I know nothing about MSMQ but I have written windows services before. Though I have no issue picking up MSMQ if it is required.
I want to keep the response from the devices some where in case the processing fails for some reason that is caused by the data. This way I can interrogate the data and see if there is a problem i.e. the device allows a user to add comments that extend the related field's length in the server side database.

With this information, do you think it is worth me looking into learning MSMQ or should I stick with the simpler solution?

Chris.

MSMQ isn't a bad choice and is definitely not difficult to learn, but keep in mind that there are some constraints that you should be aware of.

Cons:

Each queue can only be 2GB.
Each message 4MB (altough the 4MB limit can be fixed by using MSMQ with WCF).
Only for Windows so you're limited to use it with .NET, C/C++ or COM library for COM-enabled environments.

Pros:

Supports Windows Network Load Balancer.
Supports Microsoft Cluster Service.
Integrated with Active Directory.
Ships with Windows.
Supports transactions.
MSMQ messages can be tracked by audit messages in the Windows Event log.
Messages can be automatically authenticated (signed) or encrypted upon sending, and verified and decrypted upon reception.

Another approach you might want to consider is writing your data to a staging table. This might be a good idea since you want to have a message back log.

It's difficult giving advice when I don't know the rest of the system's architecture, but I hope this answer will help a little.

Useful links

Programming MSMQ in .NET - Part 1
Using MSMQ with WCF