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?
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.)
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:
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?)
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..
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.)
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.
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.
VMS (using C) - it's very robust –
Ashien 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!
Redis is another hot breed on this platform. Check with their Set based queueing implementation and also Pub/Sub pattern. It looks promosing
© 2022 - 2024 — McMap. All rights reserved.