32

If you want to use a queuing product for durable messaging under Windows, running .NET 2.0 and above, which alternatives to MSMQ exist today? I know of ActiveMQ (http://activemq.apache.org/), and I've seen references to WSMQ (pointing to http://wsmq.net), but the site seems to be down.

Are there any other alternatives?

Thomas Lundström
  • 1,573
  • 1
  • 13
  • 18

8 Answers8

19

May not be "best practice" advice here... but based on real life needs and experience: we have distributed system, 60 boxes running each 10 clients all do task X, and they need to take the next task from a queue. The queue is being fed from one other "client"...

We had used inter process communication, we used MSMQ, we tried service broker... It just doesn't work in the long term because you are giving away the control of your application to Microsoft. It works great as long as your needs are satisfied. it becomes hell when you need something not supported.

The best solution for us was: Use a SQL Database table as the queue. Don't reinvent the wheel there, since you will make mistakes (locks). There is info out there on how to do it, it is very easy and we handled over 200K messages per 24H (with 60x10 = 600 concurrent reads and writes to the queue). That is in addition to the same SQL server handling the rest of the application stuff...

Some reasons why MSMQ doesn't work:

  1. When you need to change the logic of the queue to not FIFO, but something like "the oldest RED message" or "the oldest BLUE message" you can't do it. (I know what people will say, you can do it by having a red queue and a blue queue.. .But what if the number/types of queues is dynamic based on the way the application is administrated and changes daily?)

  2. It adds a point of failure and deployment nightmare (the queue is a point of failure and you need to deal with setting the right permissions on all boxes to read/write messages etc' in Enterprise software you pay in blood for these type of things). SQL server... all clients are writing/reading already from the DB, it is just one more table..

jpaugh
  • 5,719
  • 4
  • 33
  • 83
csmba
  • 3,983
  • 3
  • 29
  • 42
  • 15
    Using SQL Server isn't a replacement for all of the features of MSMQ though. MSMQ done right means each of your 60 boxes can work while the central server is offline (so long as enough messages were delivered to keep them busy). For your scenario (distributing work in an online scenario) SQL made sense, but I'm not sure it's a general "Alternative to MSMQ". – Paul Stovell Apr 25 '11 at 06:44
  • 2
    It's a queue, why would you want a none FIFO queue? That's what a queue is. – Liam Jun 19 '14 at 09:31
  • 3
    Not to mention that 200k messages in 24 h is nothing in some systems. – zaitsman Jan 02 '15 at 13:10
  • @csmba I edited Q to queue, since MQ is short for *message queue*. ([Q](http://memory-alpha.wikia.com/wiki/Q) is something different altogether ;-) – jpaugh May 30 '17 at 17:37
11

I can't begin to say enough good things about Tibco EMS - an implementation of the Java JMS messaging spec. Tibco EMS has superb support for .NET clients - including Compact Framework .NET on WinCE. (They also have C client libraries too.)

So if you're building a heterogeneous distributed application involving messaging code running on Windows, Unix (AIX/Solaris), Linux, or Mac OS X, then Tibco EMS is the ticket.

Check out my article here:

Using JMS For Distributed Software Development

I used to work at Microsoft and did some implementation with MSMQ while there. But you know, Microsoft just concerns itself with Windows. They depended on 3rd parties to provide MSMQ clients to other platforms. My encounter with Tibco EMS was a much better experience. It was very evident that Tibco understood messaging much more so than Microsoft. And Tibco put the effort into supporting diverse client bindings themselves. That is why they eventually changed the product name from Tibco JMS to Tibco EMS (Enterprise Messaging Service).

And I did build heterogeneous software systems around Tibco EMS. Rolled C# .NET Winform clients interacting with Java/JBoss middle-tier via Tibco EMS messaging. (And also have WinCE industrial embedded computers that use the Compact Framework .NET Tibco client.)

Links To My JMS Writings

RogerV
  • 3,588
  • 4
  • 25
  • 32
10

The RabbitMQ framework seems to have been overlooked here. If folks still care, it does have a .NET 2.0 code base and it comes with a WCF binding similar to netMsmqBinding. The binding naturally requires at least .NET 3.0 and it has more features than the built-in netMsmqBinding. On top of it all, it is Mono friendly. Its worth a look.

Sixto Saez
  • 12,435
  • 4
  • 38
  • 49
7

What about SQL 2005's service broker?

wonea
  • 3,987
  • 17
  • 71
  • 134
Ubiguchi
  • 2,996
  • 1
  • 22
  • 24
3

Why not use ActiveMQ? :)

James Strachan
  • 9,018
  • 32
  • 30
3

If cost isn't an issue (there is also an Express SKU) then take a look at the 800,000 pound gorilla. WebSphere MQ (MQ Series). It runs on practically any platform and supports so many different queue managers and messaging patterns it really isn't appropriate to list them here.

MotoWilliams
  • 1,428
  • 1
  • 12
  • 21
  • And it may be worth explicitly pointing out: IBM provides a .NET Client library for WebSphere MQ. Any .NET app cann enqueue a message, and another app on another platform (say, a Java app on a mainframe) can then dequeue it. – Cheeso May 11 '09 at 15:40
  • We use Websphere MQ on `VMS` (using `C`) - it's very robust – Matt Feb 07 '11 at 11:36
1

If high availability is important Amazon SQS is worth looking at. There's not much additional overhead if messages come from different physical locations. Cheap and scalable!

Patrick McEvoy
  • 672
  • 6
  • 10
1

Redis is another hot breed on this platform. Check with their Set based queueing implementation and also Pub/Sub pattern. It looks promosing

asyncwait
  • 4,345
  • 4
  • 35
  • 51
  • Redis (at the time of writing) isn't currently officially supported on Windows. – aryeh Aug 14 '11 at 00:23
  • @Aryeh You're too shy with your downvotes! But there is a [Windows port](https://github.com/MSOpenTech/Redis) now, so no downvote from me. – jpaugh May 30 '17 at 17:41