Message Queue Forum

Ariel Lindenfeld
Sr. Director of Community
IT Central Station
Let the community know what you think. Share your opinions now!
DarrylPollockAs an architect, my first response is to ask what are your SLA’s for message delivery? They may determine the characteristics and thresholds of the characteristics when selecting a solution – such as resilience, robustness, throughput, scalability and error handling.
Surendranath CThis can be split into two aspects: - Features and Functionality - Quality of Service - Industry support Within the first, we would evaluate on: - Support for different Operating System Platforms - Availability of API across languages, in order of importance - Java, C#, Python, C++ - Conformance to standards - JMS API availability, Queueing standards - Availability of different addressing schema and messaging styles - Pub-Sub, Producer-Consumer - Integration and Inter-operability with different types of middle ware - Application Servers, TP Monitors - Connector availability across different technologies and platforms - with enterprise applications (CRM, ERP, Warehousing), packaged products - Banking platforms like Globus, Finacle, Telco apps like Amdocs, Arbor/BP etc - Ability to handle different formats - XML, JSON, SAP iDoc Against the quality of service parameters, the factors to evaluate are - Performance and scalability - Volumes in terms of number of queues, no of simultaneous messages per queue, number of subscribers/publishers supported - Availability of commonly agreed upon performance benchmarks - Security - Authorized access and access control across queues, confidentiality of messages, encryption capability. - Reliability - Reliable queueing, recoverability of messaging, ability to cluster and create fail-safe message queues, failure cutover timelines - Stability - little or no degradation over time the messaging server is in running state - Availability of administration tools to monitor size and performance of queues, ability to quickly identify and recycle lost or dropped messages, auto-healing capabilities Against industry support parameters, we would evaluate - Installed base in large enterprises across various business lines and geographies - Availability of developers - Participation in industry standard bodies like TOGAF etc
Pushparaj DholeSecurity, Stability, Reliability, Scalability and Performance
Rhea Rapps
Content Specialist
IT Central Station
One of the most popular comparisons on IT Central Station is IBM MQ vs RabbitMQ? Which of these two solutions would you recommend as a Message Queue soluton? Why? Thanks! --Rhea
Dave Mc AllisterI say RabbitMQ over IBM MQ. RabbitMQ has a number of things going for it, free to use, easy to set up and enjoys wide community backing. Since the team is part of Pivotal, it also has a solid backing and superb engineering. RabbitMQ (IMHO) also embases a more modern style of messaging queuing. While it might not meet certain other products in pure throughput, its ease, support for both on-premise, PaaS and public clouds make it the winner. And keep in mind that tens of thousands of companies use it in production. Go RabbitMQ. Leave that proprietary stuff behind (especially when the open source _is_ the better product).
Ashutosh AggarwalBoth have their Pros and Cons. It depends on what you are looking for exactly. Throughput - IBM then SOLACE then Rabbit MQ Features - IBM MQ 9 = Rabbit MQ, SOLACE lags a bit Support - IBM then Rabbit, you can go for SOLACE OEM support if you are Mr. Moneybags. It is easier to get support at the end application level for IBM MQ than Rabbit MQ for day to day running. Saying this from first hand experience. Debugging and maintenance resources are also more readily available for IBM MQ. If infra is stable, IBM MQ will give better persistence than anyone else in the market. I would go with IBM MQ.

Sign Up with Email