MQ is the middleware, which takees the files from an upstream system to a downstream system or the downstream system to an upstream system.
IBM MQ and IBM MQ Advanced (software)
IBM SoftwareReviews from AWS customer
-
5 star0
-
4 star0
-
3 star0
-
2 star0
-
1 star0
External reviews
External reviews are not included in the AWS star rating for the product.
Unlocking Seamless Communication: Exploring IBM MQ
Reliability Redefined:
At the core of IBM MQ's appeal is its unwavering reliability. With a robust architecture designed to withstand the rigors of enterprise-level demands, IBM MQ ensures message delivery with precision and consistency. This reliability instills confidence, allowing businesses to orchestrate intricate workflows with minimal risk of data loss or disruption.
Scalability and Flexibility:
In an era marked by exponential data growth, scalability is paramount. IBM MQ rises to the challenge, offering scalable solutions that adapt effortlessly to evolving business needs. Whether handling a surge in message volume or accommodating new applications, IBM MQ empowers organizations to scale their messaging infrastructure seamlessly, without compromising performance or stability.
One of the best MQ service
One stop solution for all queuing needs
Best Messaging queue for Banking domains applications
Best Queue Manager
Best Queue management tool in the market
It also offers a simple and fast integration process to ensure quick implementation.
Smooth and reliable experience with RABBIT MQ
Has great system integration features
What is our primary use case?
What is most valuable?
The system integration is good.
What needs improvement?
The pricing needs improvement.
For how long have I used the solution?
I have been using IBM MQ for six years.
What do I think about the scalability of the solution?
The scalability is a nine out of ten.
How was the initial setup?
The initial setup is complex.
What other advice do I have?
Overall, I would rate it an eight out of ten.
Which deployment model are you using for this solution?
We have the tool in the corporation, but without qualified labor.
Can work in clusters and scales horizontally
What is our primary use case?
I was part of a small team that tested and used the IBM infrastructure in a QA environment. My activities included configuring and creating test environments and finding solutions to monitor the infrastructure.
What is most valuable?
Using a message queuing solution, we had a banking solution that integrated multiple branches and interbank systems. Different systems for credits, debits, CRM, and others communicated through this message queue solution. It wasn't just about communication; for instance, a CRM application needed to collect information from various banking systems, such as account balances, properties, contracts, and credit cards.
These systems were separate, and the message queuing solution combined information from all of them into one message. When a request was made from a workplace for information about a person or company, the message queue infrastructure routed the request to all connected systems, ensuring the workplace did not need to be aware of all configuration details.
The product's most valuable feature is its ability to work in clusters. This allows for creating a cluster of message brokers, providing horizontal scalability. Another important feature is the extensive command-line interface, which allows for comprehensive monitoring and management of the system. This enables the creation of complex scripts to configure, making it a complete and very powerful tool.
What needs improvement?
The tool is expensive.
For how long have I used the solution?
I have been working with the product for four years.
What do I think about the stability of the solution?
The tool is scalable.
What do I think about the scalability of the solution?
IBM MQ is stable.
How are customer service and support?
The tool's support is not cheap and fast. You can't expect a resolution from support.
How was the initial setup?
The setup of message queues in an enterprise trade system is complex, especially when dealing with hundreds of message brokers and thousands of message queues. Configuring such a large infrastructure isn't straightforward and requires tools for testing, validating, and identifying missed components.
We manage a large configuration file, likely an XML file containing thousands of lines. Many teams update this file to reflect changes in their systems. It can be split into multiple smaller files to manage this file, but this complicates maintaining a single point of truth and requires validating all combinations. Systems communicate with each other using these components, needing a common protocol.
What was our ROI?
The benefits of using IBM MQ include buffering your transaction flows, which is useful if you have spikes. For example, it can handle this increased load if you normally have 100 messages per second but expect 10,000 the next day. You can also build clusters of message brokers to scale horizontally.
What's my experience with pricing, setup cost, and licensing?
The license for IBM MQ is commercial and not cheap. You get a multi-platform solution, which is important because it lets you connect systems on mainframes, personal solutions, Unix, Linux, etc.
What other advice do I have?
Applications produced and consumed messages, with the IBM infrastructure serving as the transport and storage for these messages. Messaging was based on IBM MQ, and several other IBM products were involved, though I can't recall their exact names. These products were used for transforming messages, validation, and routing. The infrastructure could route, validate, split, and combine messages.
I rate the overall product a ten out of ten. Our goal was to measure the performance of the integrated system, not just individual components. This involved external systems as well. We used various command-line tools, such as IBM MQ, to collect detailed information about processes and systems. Measurements had to be aligned with configurations, meaning we couldn't use a universal solution. Instead, we had to adjust based on specific requirements and configurations.