Multicasting, Messaging, ActiveMQ vs. MSMQ?

Question

Hi all,

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

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

Answer 2

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 3

I suggest you have a look at TIBCO Enterprise Messaging Service - EMS, which is a high performance messaging product that supports multicasting, routing, supports JMS specification and provides enterprise wide features including your requirements suchas fire-forget and message persistence using file/database using shared state.

As a reference, FEDEX runs on TIBCO EMS as its messaging infrastructure.

http://www.tibco.com/software/messaging/enterprise_messaging_service/default.jsp

There are lot other references if i provide, you'd really be surprised.

Answer 4

There are so many options in that arena...

Free: MantaRay a peer to peer fully JMS compliant system. The interesting part of Mantaray is that you only need to define where the message goes and MantaRay routes it anyways that will get your message to it's detination - so it is more resistant to failures of individual nodes in your messaging fabric.

Paid: At my day job I administer an IBM WebSphere MQ messaging system with several hundred nodes and have found it to be very good. We also recently purchased Tibco EMS and it seems that it will be pretty nice to use as well.

Paul/

Answer 5

Take a look at zeromq. It's one of the fastest message queues around.