Using MSMQ - System.Messaging versus WCF

Question

I have to port a VB 6.0 app to VB.Net (Framework 3.5). The application uses MSMQ heavily. I'm trying to figure out what are the advantages of using WCF over good ole System.Messaging. Are there any potential showstoppers when going with System.Messaging?

Answer 1

Going with WCF gives you a clear forward path. While I doubt System.Messaging is going anywhere (see System.Runtime.Remoting), new development will happen in WCF, and it gives you the opportunity to migrate to other technologies as they arise. It frees you from being tied to the specific transport implementation.

The WCF programming model is also very clean and pleasing.

Answer 2

You should check out the Motley Queue website. There is a good comparison on System.Messaging vs WCF. WCF is going to be much cleaner and easier to use.

Answer 3

I sort of disagree whether WCF is easier/cleaner than System.Messaging, which, let's face it, has a pretty simple API (overall) and is relatively simple to use, if that's all you care about. However, WCF does have some nice things, but it is not simple by any means.

As for whether you'll find any problems, well... that depends a lot on how your VB application is currently using MSMQ and what kind of data it is sending. You'll be using the MsmqIntegrationBinding binding, which helps somewhat, but you might have to pull some tricks to handle message deserialization successufully if your VB app doesn't send messages in a format WCF can deal out of the box with.

Answer 4

I personally love MSMQ, and would go with that.

The main 'gotcha' for me, was that you are limited to 4meg per message. If you're serialising a large object graph, it's a problem, but trivial to fix by just serialising to disk first, and sending the filename across.

MSMQ may not get "new features", as one of the other posters commented, but IMHO, it's stable, very scalable, and has all the features I need as-is.

Answer 5

I think this quote from the "Motley Queue" web site ("web": excellent link!) sums it up best:

*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. *

That is in a nutshell what WCF tries to accomplish - relieve you of a lot of plumbing and intricasies and let you concentrate on your business problems you want to solve.

My vote is in for WCF! :-)

Marc