System.Messaging versus WCF Queuing

Should your app be using System.Messaging or WCF Queuing? We’ve all seen these kind of technology comparisons before — someone extols the virtues of two solutions, highlights the pros and cons in certain situations, and ultimately answers the comparison question with the helpful and enlightening “it depends.” In this case however, I’ll spare you the ambiguity. Your app needs to use WCF Queuing. *

To understand why, let’s so a side-by-side comparison:

System.Messaging (SM)	WCF Queuing	Why is this interesting?
At its core, is a wrapper around MSMQ’s APIs.	At its core, is a wrapper around MSMQ’s APIs.	Both technologies wrap MSMQ so you get all the benefits of a robust, stable, and time tested reliable messaging platform no matter which way you go.
Enables an object-oriented view of your application’s asynchronous communication plumbing.	Enables an object oriented view of your application’s business processes.	The WCF programming model is centered around your business operations. With it, you can stop managing your message transactions, setting message properties, searching for messages in a queue, checking for NACKS, retrying messages, etc. Instead you can start thinking of the world in terms of business operations (e.g. CreatePurchaseOrder) and focus on your business logic. Leave the tedium to WCF.
Enables you to write your own end-to-end message encryption/authentication.	Provides end-to-end message encryption/authentication for free.	SM encrypts messages while they’re on the wire and will enforce a queue’s ACL, which is great. If you want your messages encrypted on disk, however, or any authentication besides who is allowed to send to/receive from a queue, you need to write that yourself. With WCF Queuing however, you can easily enable message level security, ensuring all data is encrypted, even when in MSMQ’s store or traverses multiple hops. You can also decorate your business operations to declare which user groups/roles are allowed to invoke them.
Your only hosting option is to write your own service/executable.	Host your service in a custom service/executable or let IIS host it for you.	Need your application available all the time but still want to utilize resources efficiently? Want your app to recover when it encounters a critical failure? Host your service in IIS via Web Hosting and it will get activated when messages arrive in your queue and will be recycled if it encounters a failure (configurable of course).
Enables you to write your own poison message handling (but only if you’re down with PInvoking the MSMQ C API).	Provides poison message handling for free.	Ever had a message in stuck in a queue that you couldn’t process and had to build some complex retry/reject logic in your app to accommodate it? Or, worse yet, do you search for messages to receive from a queue to avoid this problem altogether? If so, WCF Queuing supports poison message handling out of the box — a huge win in the fight for robust distributed applications and against using a transport mechanism as a data store.
Enables you to write your own message correlation logic.	Provides message correlation for free.	So you’ve got a group of messages you want processed together or by the same receiver? With SM, you’ve got access to a message’s correlation ID but of course it’s up to you to do the correlating. With WCF Queuing, you can group your messages in sessions and WCF will ensure those messages are processed together.
Enables you to write your own transactional batching logic.	Provides transactional batching for free.	Want performance and transactional reads? Batch your reads together in large transactions and only abort in the relative few instances you need to. Of course you’ll need to write that logic yourself as well as the retry mechanism and make it configurable for tuning purposes if you use SM. WCF on the other hand supports transactional batching and its configuration out of the box.
Can create, delete, and generally manage MSMQ queues.	Cannot create, delete or manage queues.	*WCF Queuing can’t do everything SM can do; you still want to use it to create and manage your queues. So arguably you want to use WCF Queuing with SM, as opposed to instead of, but for the actual transmission of data, WCF is clearly the way to go.

 

Obviously these aren’t all of the comparison points to be considered, but they’re certainly the salient ones. When all is said and done, it’s pretty clear the value-add that WCF Queuing provides to your applications: focus on your business logic, end-to-end encryption/authentication, Web Hosting, poison message handling, message correlation, and batching, to say the least. 

So give it a try and let us know what you think. In fact, there’s no need to wait, WCF Queuing integrates seamlessly with your existing System.Messaging and MSMQ applications. If you’ve got a System.Messaging/MSMQ app sending messages, put WCF Queuing on the receiving side, or vice-versa. The Integration Binding makes it a breeze to start using WCF Queuing today.

—Justin Wilcox
MSMQ (and System.Messaging) Test Lead