Well, I don't know that I'm going to suggest MSMQ, but I will suggest that there's a lot of edge cases to think about for 'roll your own'.
Even with a thread pool approach, be aware that there may be ordering issues if you care - two items posted sequentially to thread pools may not be executed in order, due to how the thread pools handle work items.
You'll also need to think about persistence of messages, and how long they should exist, how to detect 'fatal' non-delivery status, and what to do in that case.
There's also a number of potential edge cases in scenarios where your app goes down around the same time as it's queueing a message - for instance, it may not get the acknowledgement that the message was queued, even though it was. Yes, you can ack the queue acknowledgement, but you can endlessly get into ack circles...
Why not just have the app detect when it gets connected, and send all the data at that point?
You can think of a service bus as the Ethernet of SOA.
First and foremost, it introduces a language of identifying things, like an IP address in Ethernet. This name isn't something inherently physical.
Next, you have something physical involved on each node, like a queue in the case of a bus for supporting semi-connected communication, or an Ethernet card in the metaphor.
Beyond just the physical, there is the "protocol" part of the communication, like the OSI stack for Ethernet. With the bus, this is the client libraries used by application code.
Ultimately, you can view a service bus as providing the next higher level of abstraction for building distributed systems. You can use it also for client-server communication to give you durable one-way messaging as well as for the server to push notifications back to the client.
Specifically, you'll find NServiceBus to be quite lightweight and easy to use once you make peace with its use of queuing technology - your choice of RabbitMQ, MSMQ, Regular SQL Tables, Amazon SQS, Azure Storage Queues, and Azure Service Bus.
Best Answer
I'm responsible for the Windows Azure ServiceBus support in NServicebus. And in my opinion this new Windows Server Servicebus provides the exact same capabilities as the Azure ServiceBus. So in my opinion it will be a good match with NServiceBus instead of a competitor (just as the Windows Azure ServiceBus is) and could be used instead of msmq.
To answer your questions
Hope this helps?
Kind regards, Yves