IBM WebSphere MQ is deployed on a Windows machine, as well as almost all of our infrastructure. Windows services read and write to the MQ server - this is the way that we interact with it. All the messages that we put on the queue are also stored in an SQL Databases. A Windows service reads that message from the SQL Database storage and puts it on a queue on a certain channel; these Windows services are running indefinitely, on a loop so any message is read instantly.
The solution is very easy to work with.
The solution is very stable, it also offers transaction management and support.
The solution offers very good integration with other services. It's one of the great advantages of the service.
We have had it for a long time now - version 7.1, which is not the latest.
The admin interface of MQ Explorer that is used to interact with the server seems a little bit dated. It makes it somehow difficult to interact with it. It needs a major update to make it more modern and easy to navigate, maybe a web version.
The solution isn't free. There are other solutions, like RabbitMQ, which are open source and absolutely free to use. This open source solution we use it for non-critical processes.
IBM offers a special version that you need to get if you want to transfer files, especially large files. Maybe it should be included in any version.
We've been using the solution for a very long time. It's been at least a decade - about ten years.
The stability of the solution is good. We've never run into any issues.
IBM MQ offers clustering. We don't have this yet, as it hasn't been implemented, however, I know that you can install it in a cluster of servers.
My understanding is RabbitMQ is also easier to scale. I'm unsure as to how well IBM can scale in comparison.
I've never contacted technical support in the past. I can't speak to their level or service due to the fact that I've never directly dealt with them.
We're also using RabbitMQ. While IBM is more stable, RabbitMQ is easier to work with.
We've been trying to change our architecture, and RabbitMQ is more appropriate for us as it's easier to put together with microservices.
While I was part of the process for implementing RabbitMQ, which was very simple and straightforward, in the case of IBM, I didn't install it myself. Unfortunately, I cannot explain how easy or difficult it was as I was not part of the experience. My understanding is it's not too difficult.
In terms of maintenance, we have two people from the support team handling that aspect. They can restart the server or look into the queues. They aren't working in shifts, however, if there are issues, one of them is normally available to troubleshooting.
In comparison, for RabbitMQ, we had only one developer that installed it and created the publishers, workers etc. I believe the support will be the same as for IBM. In both cases, there aren't too many people needed for maintenance.
I'd recommend the solution. It's a very stable solution and very resilient.
If there is not essential data that needs to be transported between services, then I would go for a RabbitMQ, because it's easier in style, and it's free to use. On top of that, you can have it to wrap around everything in a straightforward way.
That said, I'd rate the solution nine out of ten. We've used it for a number of years and it's always worked very well for us.
The methodology and the way in which the platform has been produced as a standard is most valuable. There are so many different versions of it now, but the actual basic functionality and the simplicity of it have made it far easier to be implemented in so many different instances. When I worked with the OS/2 or PS/2 machine environment, the messaging mechanisms were based upon IBM MQ. It is so versatile, which is the main reason that I'm a fan of it.
There are things within the actual product itself that can be improved, such as limitations on message length, size, etc. There is no standardized message length outside of IBM. Each of the implementations of the MQ series or support of that functionality varies between various suppliers, and because of that, it is very difficult to move from one to the other. We have IBM MQ, but we couldn't use it because the platform that was speaking to MQ didn't support the message length that was standard within IBM MQ. So, we had to use a different product to do exactly the same thing. So, perhaps, there could be more flexibility in the standards around the message queue. If we had been able to increase the message queue size within the IBM MQ implementation, we wouldn't have had to go over to another competing product because the system that was using MQ messaging required the ability to hold messages that were far larger than the IBM MQ standard. So, there could be a bit more flexibility in the structuring. It has as such nothing to do with the IBM implementation of MQ. It is just that the standard that is being put out onto the market doesn't actually stipulate those types of things. As a result, rather than following the recommendations and the standard that was within the IBM MQ implementation, some suppliers say that we need the ability to have longer message lengths than they've implemented, but that's the way it is. Other than that, I'm very pleased with it as it is. It is good at doing what it does. I love the actual implementation, and I've used it a lot.
I've been using IBM MQ since it came along. We've got a lot of different platforms. We have IBM MQ. We have had BizTalk, IMMQ, WebSphere, and WebLogic platforms, but we're moving very much into the cloud.
The support that we have goes through third-party vendors. In the past, their support has been very good, but I can't say anything about it today. About 15 years ago, in the companies I was working with as a consultant, we had very good support. We were working very closely with IBM, and IBM implemented the PS/2 and OS/2 operating system together with Microsoft. The implementation there in terms of the connectivity was an implementation of the IBM MQ series in the OS/2 operating system, PS/2 environment. The support we received for that work back in the late '80s was fantastic.
The initial setup is usually left to other people to do. I've never actually done the installation and setup of it myself. It has been other people with a bit more deep technical knowledge who have done the implementation and actual installations. It was a very long time ago when I received the first set of CDs where we were going to be doing the installation of it, but I don't have that deep technical knowledge of the implementation as such.
I think it's pretty reasonable, but I'm not so too sure of the current pricing strategy from IBM. We use many bundled services, and most often, we go through a service provided by some other third-party implementation. So, I can't really give an honest opinion about that.
I would rate IBM MQ an eight out of 10.
Our use cases for IBM MQ involve share markets.
In this organization, we are not using many of the features because we have a very small infrastructure. In my previous organizations, I used many of the components including AMS. However, here, we are just using it as a messaging solution and not any of the other components.
The MQ appliance has very good performance.
The user interface should be easier to use.
The user interface should be enhanced to include more monitoring features and other metrics. The metrics should include not only those from the IBM MQ point of view but also CPU and memory utilization. These kinds of features would be really helpful when we have a large infrastructure. Right now, this limits us from using the product.
In general, the user interface should be more catchy, to entice users.
IBM should promote the use of the MQ appliance because the speed and performance are superior when compared to traditional ways of using the product.
If IBM were to release as least some limited features for MQ as open-source, then it would be great because people will migrate to this solution instead of choosing open-source products like Apache Kafka or RabbitMQ.
I have been working with IBM MQ for almost 13 years across different organizations. I began working with version 5.3 and am currently using version 9.
The stability is absolutely perfect when it is running on AIX. However, I have experienced some issues with certain Linux distributions. With AIX, I have not had any problems with IBM MQ. With other flavors of Linux, there is some instability whereby the MQ configuration parameters are not giving the proper information. From this, I have concluded that the stability of MQ depends on the Linux distribution that it is running on.
The number of users in my current organization is six or seven. This is the number of applications that we have. This is not an extensive use of the product but we do plan to increase usage in the future.
In my previous organization, our use was more extensive. We had between 700 and 710 users.
This product scales and the number of users depends on the industry, as well as the financial strengths that the organization has.
The technical support from IBM is always reachable.
Internally, we provide technical support to our users. This is possible because our team is only six or seven users.
This initial setup is not complex at all. Deploying it was very easy.
Limited staff is required to maintain this solution because of its stability.
The licensing fees are paid quarterly and they are expensive. This is something that I have heard from all of the organizations that I have worked with.
I have evaluated Apache Kafka and RabbitMQ because of the open-source features and benefits. The open-source aspect is an advantage. I have found that not many users choose IBM MQ, even though it is stable, because of financial constraints.
If IBM were to release MQ or at least some limited version as open-source, it would become more popular. People would choose it instead of implementing other products, or other streaming solutions. This is what people are trying to do with DevOps.
IBM MQ is much more stable than these other products, although the rest of them work well with cloud providers such as AWS.
Overall, this is a good product. The only thing that I found complex was to build the user interface with the latest versions of IBM MQ. It was a little bit tricky to do.
I would rate this solution an eight out of ten.
The solution is primarily used for business transactions. It's used for financial transactions as well. Those are the two main use cases. We exchange information with our in-house applications before we supply information to our customers and so on.
The messaging queue is the main feature that we use. We use other products like publish and subscribe, which are very useful to us as well.
We can share data and other people can subscribe to it.
The solution is very stable.
The solution can scale well.
We've found the installation to be extremely straightforward and well laid out.
It's easy to maintain, easy to administer, and easy to see what's going on there. Overall, it's a good product.
Technical support is excellent.
The way the solution provides us with the product and the way we use it gives us what we need. We don't actually have any issues with it.
There could be a better front-end GUI interface for us, where we can see things more easily. However, apart from that, it works well.
The pricing is definitely could be cheaper. Also, the support model, even though it's very good, could be cheaper as well.
I've been working with the solution for about 25 years or so. It's a good amount of time. I have a lot of experience.
The product offers good stability. There are no bugs or glitches. It doesn't crash or freeze. It's very reliable in terms of performance.
The product scales well. If a company would like to expand, it can do so. It's not a problem.
It's hard to say who exactly is working on the solution at this time. We have around 30,000 people working on it, in some way or the other.
We've got to keep using it for the foreseeable future. We don't see any reason not to as it provides us with a good solid platform. We have no reason to change anything.
We have found the technical support to be very good. They are responsive and knowledgeable. They are also very friendly. We are satisfied with the level of support we receive. As soon as we raise any issue, they get in touch with us and sort it out. It's great.
We did not previously use a different solution. We started with IBM MQ a long, long time ago and we stuck with it.
The initial setup is not complex. It is a very simple installation. I've been provided with instructions that make the whole solution extremely easy to download and install.
The entire process is very fast. It only takes about 30 minutes to deploy.
We have different departments that can handle deployments. We have about 100 people on our team that can handle this type of assignment.
This is a licensed product. We do pay for it.
While, of course, it would be better if it was cheaper, the service they provide with it, including the maintenance facilities they provide, is very good. We're quite happy. Most people have to use what IBM provides, however, it could be a cheaper license.
We're just a customer and an end-user.
I'd recommend the solution to any organization.
I'd rate it ten out of ten. It really provides everything we need.
In our company, it's the main hub for our whole CRM solution. MQ manages things through the Broker.
I like the whole idea. But the first things are its simplicity and its robustness. Compared to any other product, it's the most robust I've worked with. And it's extremely easy to manage.
The worst part is the monitoring or admin, especially in the ACE or Broker. There is always a problem of transparency. In MQ you can observe any process and you know exactly what's going on behind the scenes, but with the ACE or Broker, it's a problem monitoring the HTTP inputs. It's like a black box.
The reason that I'm emphasizing monitoring is that I used to work for the company that produced the administration and monitoring tools for IBM. There was a lot of competition and a lot of confusion in the market. When I moved to this company I actually used my previous experience and wrote my own tools. I am not much of a C# programmer, so I was struggling a bit. I know the concepts, but I was missing some straightforward support from IBM. They were selling it as a part of Tivoli, but you needed to implement the whole Tivoli infrastructure. If you had some other monitoring provider it was a bit of a pain. That is my concern here.
I've been certified as an MQ specialist since 1997 so I have about 23 years' experience in this field. I've been using it since version 2.0. Currently, I'm in production support and supporting version 9, mainly.
It's stable. I'm working for a FT 500 company, a global company employing about 60,000 people, and we've been using this product ever since I joined the company in 2003. We haven't had a single major performance issue or crash.
It's scalable. We have gradually increased our usage over time.
I am satisfied with the support from IBM. To be honest, I used to be an IBM trainer for this product, so I know people there. The only issue I have is that if the product goes out of service, it's difficult to get PMR (Problem Management Report) for it. In production, a lot of businesses tend to stick with the older versions.
I've been doing it for over 20 years, so it's straightforward to me. Beginners might struggle with the initial settings, like user rights and the basic stuff, but setting up MQ is fine.
Before joining this company I was mainly consulting for various companies in Germany, and I noticed the core problem was always that in projects where MQ was implemented, they were targeting too low on the management food chain. You need that to go as high as possible because it changes the whole paradigm, your ways of thinking. A lot of the implementations were bad because they were partially patching some problems at the bottom level. The whole strategy was never oriented to messaging. My suggestion would be to be aware of that. Go global from the start. Don't address things partially.
There is a team of four people who supervise all MQ activities here.
I would rate IBM MQ at 10 out of 10, but ACE or Broker are between eight and nine, because of the lack of transparency.
The primary use case of this solution is for the general merchandising and retail market.
From the infrastructure point of view, it's a great improvement and it's more flexible to the latest hardware. Also, it is flexible for whatever is coming or whatever is available for on-premises and cloud integrations.
The most valuable features are RDQM and queue sharing.
There has been a lot of improvement in architecture. It handles better with the new architecture such as Cloud, and Cloud-on-premises integrations.
Also, how Kubernetes can be deployed is helpful.
I would like to see message duplication included. We don't have a mechanism for duplicating a message.
There is a different model where you can have multiple subscribers and not publish the stored data to multiple subscribers.
Duplication is the most important for sending the same data for different applications.
We have been using IBM MQ for 15 years.
We are using 9.0.0.6 and in the process of upgrading to 9.02.
In terms of stability, IBM has proven to be very rare. It's a very stable product.
We test in very large volumes.
We tested ActiveMQ and it's nowhere close to IMB MQ.
Scalability is an area that has improved a lot. The scalable data is different.
The way the cluster handles and cluster load balancing is different than what it used to be.
Now with the uniform clusters, it's much better. There is a lot of competition especially with messaging. With streaming, people are using it for messaging also.
It's very flexible to scale.
We have been using it for a long time. We have a team of 15 people who are using this solution. There are more than 5,000 integrations that are using this solution in all platforms, such as Mainframe, Windows, and Cloud environments.
Tech support is very good. I guess other support groups if someone is looking for ADP accounts it lacks but in general technical support is good.
I would rate them a nine out of ten.
Previously, we did not use any other product. I am not familiar with other technologies.
I'm learning and doing some experiments, but we have found a product for the volume we have.
The initial setup is straightforward, it's easy.
If someone knows its basic structure, it is easy, but the open-source is much easier than IBM MQ because you just have to install it and start working on it. With IBM MQ you have some installation procedures.
The open-source version needs route access which could be security compliance and could be complex.
IBM is expensive.
I would recommend this solution and suggest you start using it if you have the budget. It's very stable and robust. It's a proven technology, so no one needs to worry about that.
It all relies on the budget, that where all of the problems are. People want to use open-source, and businesses do not have a budget.
It's a good product to use.
I would rate IBM MQ a nine out of ten.
We develop applications for 20 companies in the insurance industry. We have about 20 different product systems that use the same MQ layout.
We are also using it for testing and educational purposes.
Our customer base is in the closed market of Switzerland and Liechtenstein.
We just switched versions from 8.0.0.6 to 9.1.
Most European companies have MQ, though we just added it four years ago. MQ changes the way people think about their applications. E.g., they are more integrated. We see synergies with the tool, but there is a long path to changing people’s minds.
The MQ layout is quite easy.
It is very stable. We don't have many issues.
We have had an issue with the migration. Most of our applications are running on Java and WebSphere. We have a project to get rid of an old .NET application since we are experiencing a loss in connection during the migration to 9.1. The problem appears to be more on the .NET side than the MQ side though.
The technical user interface is outdated in terms of the language used. I think this is inherited from the mainframe. This is more of an engineering issue. It is running on a Windows platform, and I don't like having Windows being the backbone of our company.
I don’t like legacy view of MQ.
Four years.
We don't have a problem with stability.
We have not had any large scalability issues. The business that we have is not that big. In Switzerland, we have around 3,000 people working with all our systems. We don't have that many transactions. For our 20 customers, we have four servers in production with two on standby and two that are active. We need scalability mostly to run large printing jobs for MQ, where we need disk space. Overall, we don't have any scalability issues.
This solution has improved and influenced the communication between different applications, then standardized that communication. Before, we had a lot of different interfaces, which were partly handwritten. Now, we have two or three manned technology with MQ that are automated. Therefore, we are focusing and reducing the amount of technology.
For some special parts, we also had something previously in place. We ran around 100 to 1000 PDFs in a batch mode.
We have a standardized way in describing our servers, services and rights because we have our own infrastructure. We just generate the MQSC scripts, then push it to the right server.
The time it takes to deliver a new integration varies. From our point of view, we are really fast, but we do not develop applications on our own. We are a type of project management and system provider company. This means that most applications are written by different companies. E.g., we have IBM as a software supplier.
Two people from our company maintain the solution along with a consulting company that we have. All this is done part-time.
Our costs haven't increased but they also have not improved.
We are happy with it. I would give it an eight (out of 10).
We are not using containers.
We have various strips statements, and we use IBM MQ to pass those strips statements to different systems within our organization.
Encryption and the fact that we have not had any data loss issues so far have been very valuable features. IBM MQ is well encrypted so that we are well within our compliance and regulatory requirements, so that is a plus point as well.
I would like to see their cloud feasibility with other vendors. I know that they are very much tied to their own cloud right now, but I don't know how they are supporting AWS and Azure.
With IBM products, there's less marketing. If they do more demos and more seminars on their products, it will be very useful. On a given day. I get seminar invites for many vendors and products, but for IBM, I may get an invite once or twice a year.
Documentation is easily available to people who know about IBM products. However, if you're not familiar with the products and because there are no popups about seminars and product news, you will not be able to easily find the documentation. So, I think that there's a gap in IBM's marketing, which needs to be improved.
It's been a pretty reliable and well structured solution so far.
It's very good and scalable. Currently, we use it within the EMEA and APAC regions, and we have a few regions in the Middle East as well. We haven't had any issues so far in terms of scalability because we started with APAC. Usually, we start with only London and then slowly start extending to Europe and APAC regions. So, it's scalable because we started with one region, and now, we already have four or five regions.
We have a middleware team of 45 to 50 people in APAC and EMEA who use IBM MQ, but the usage is not limited to the team. We have users across all our venous functions everywhere because this is for backend transmissions connectivity. We use Message Queue everywhere.
At the moment, there are no plans to increase usage, but I think we'll soon be looking to do so. By the first quarter of 2022, we will be moving most applications to the cloud. We know that IBM MQ is very well supported in the cloud and that it will be easier. Right now, our infrastructure is very much on-premise dependent, and we have some legacy dependencies there. So to get to the cloud for us is a big journey, and once we are at that stage, then we'll be able to look into increasing usage.
We setup IBM MQ about four or five years back. I think the setup now would be much easier than the one we did then.
IBM MQ was the first product that I got introduced to when I started my journey with IBM. This is my 14th year in this industry, and I see that this application is still very much useful and applicable. So I always recommend IBM MQ, and this is one of the most popular IBM products.
I would rate it at seven on a scale from one to ten.
