Introduction to MSMQ

What is MSMQ?

Microsoft Message Queuing, or MSMQ, is technology for asynchronous messaging. Whenever there's need for two or more applications (processes) to send messages to each other without having to immediately know results, MSMQ can be used. MSMQ can communicate between remote machines, even over internet. It's free and comes with Windows, but is not installed by default.

Typical usage

Typical example of MSMQ usage would be order processing application: orders are collected online using web forms and by sales team using some offline application. Order processing is slow, because third party payment provider is used. Third party resource can be unavailable at times and we don't want that failure to affect our application - we can delay processing of pending orders, but new orders must be collected.

Notification web page should be immediately displayed to user, even if that order is processed hours later. Sales must collect orders offline and send them to processing later, when connection with order processing server is available. After payment is processed it should be enough just to send message that shipment should be sent, and not wait for delivery to be completed. MSMQ is ideal for these kind of scenarios - when applications should be isolated and work even if other applications they interact with are down or unavailable.

From programming point of view, MSMQ is very easy - applications just need to send and receive messages, MSMQ will take care of message delivery, wait until recipient is available, etc. MSMQ supports transactions, if processing fails for any reason message can be returned back to queue to be retried later. Distributed transactions with database operations are supported too, if COM+ is used.

Alternative to MSMQ

Another approach to isolate applications could be to use some shared resource, like database. First application would write there data for processing. Another application would have to periodically check if there's something new, and process it. Beside inefficiency of pinging database constantly, this approach requires much more work - some protocol must be created to know if message (i.e. row) is pending or processed. However this is tip of an iceberg - MSMQ offers much more: messages can have different priority, limited life time, notification of success or failure can be delivered, processed messages can be stored in journal, etc. All this functionality would have to be reinvented.

When things go wrong

So far one of main reasons not to use MSMQ was lack of tools that could help when things go wrong. And they do go wrong. Most notorious problem are poison messages - when some message can not be processed and blocks entire queue. If we implement manual messaging using database every situation could be solved by manual database modifications.

If MSMQ is used messages and queues are in proprietary format which cannot be edited directly. Only available management tool is MMC administration console (or MqExplorer in earlier versions). If it can't do what you need you're out of luck - you have to write some code that accesses MSMQ API directly. Problem is even simplest operations like deleting or copying messages are not available from MMC!

Fortunately with tool like QueueExplorer troubleshooting becomes much easier - all commonly used operations are available from explorer-like interface.