Multicasting, Messaging, ActiveMQ vs. MSMQ?

Question

I'm working on a messaging/notification system for our products. Basic requirements are:

• Fire and forget
• Persistent set of messages, possibly updating, to stay there until the sender says to remove them

The libraries will be written in C#. Spring.NET just released a milestone build with lots of nice messaging abstraction, which is great - I plan on using it extensively. My basic question comes down to the question of message brokers. My architecture will look something like app -> message broker queue -> server app that listens, dispatches all messages to where they need to go, and handles the life cycle of those long-lived messages -> message broker queue or topic -> listening apps.

Finally, the question: Which message broker should I use? I am biased towards ActiveMQ - We used it on our last project and loved it. I can't really think of a single strike against it, except that it's Java, and will require java to be installed on a server somewhere, and that might be a hard sell to some of the people that will be using this service. The other option I've been looking at is MSMQ. I am biased against it for some unknown reason, and it also doesn't seem to have great multicast support.

Has anyone used MSMQ for something like this? Any pros or cons, stuff that might sway the vote one way or the other?

One last thing, we are using .NET 2.0.

Answer 1

I'm kinda biased as I work on ActiveMQ but pretty much all of benefits listed for MSMQ above also apply to ActiveMQ really.

Some more benefits of ActiveMQ include

• great support for cross language client access and multi protocol support
• excellent support for enterprise integration patterns
• a ton of advanced features like exclusive queues and message groups

The main downside you mention is that the ActiveMQ broker is written in Java; but you can run it on IKVM as a .net assembly if you really want - or run it as a windows service, or compile it to a DLL/EXE via GCJ. MSMQ may or may not be written in .NET - but it doesn't really matter much how its implemented right?

Irrespective of whether you choose MSMQ or ActiveMQ I'd recommend at least considering using the NMS API which as you say is integrated great into Spring.NET. There is an MSMQ implementation of this API as well as implementations for TibCo, ActiveMQ and STOMP which will support any other JMS provider via StompConnect.

So by choosing NMS as your API you will avoid lockin to any proprietary technology - and you can then easily switch messaging providers at any point in time; rather than locking your code all into a proprietary API

Answer 2

Pros for MSMQ.

• It is built into Windows
• It supports transactions, it also supports queues with no transactions
• It is really easy to setup
• AD Integration
• It is fast, but you would need to compare ActiveMQ and MSMQ for your traffic to know which is faster.
• .NET supports it nativity
• Supports fire and forget
• You can peek at the queue, if you have readers that just look. not sure if you can edit a message in the queue.

Cons:

• 4MB message size limit
• 2GB Queue size limit
• Queue items are held on disk
• Not a mainstream MS product, docs are a bit iffy, or were it has been a few years since I used it.

Here is a good blog for MSMQ