IBM WebSphere Message Broker Reviews

We use the product for exposing services at the application level, integrating with various architectures like WebSphere, and handling static service creation.

One of the key benefits has been its ability to expose services and securely integrate applications within our architecture. It's been integral in maintaining a stable infrastructure despite its limitations with dynamic service creation and flexibility compared to newer technologies like Kubernetes. The main challenge has been scalability during peak usage times.

The product stability has been its standout feature. It's reliable for our day-to-day operations, ensuring fast and secure data integration across different systems.

There could be greater flexibility and agility in service creation for the product. As our business requirements evolve, we require more dynamic capabilities to adapt and scale our services accordingly.

I've been using IBM WebSphere Message Broker for about 15 years now in our company.

The product is stable.

We have encountered challenges with efficiently handling large message volumes during peak times. There's room for improvement in scalability to better manage such demands.

The initial setup can be complex and typically requires involvement from multiple engineering disciplines—network, middleware, and digital engineers—to ensure a smooth deployment and configuration.

IBM software can be costly, but having a contract has helped manage and potentially lower costs over time.

We evaluated Kubernetes as a more flexible solution for our service development needs.

The platform allows us to manage messages efficiently and route them across our services. I rate it a seven out of ten.

The solution is used in our company for customers in the banking and healthcare industry. Our organization works with banks of varying scale and diverse locations. IBM WebSphere Message Broker is used for integrating two different systems.

Our company uses the tool for a Finacle to SaaS system and JD to WMS communication. For pick and drop shipments or log master tasks, we are using IBM WebSphere Message Broker in our company. 

IBM WebSphere Message Broker is one of the best middleware solutions in the market. If I want to process more than 25 MB of business information in one go, I never face any challenges with IBM WebSphere Message Broker, but other competitor solutions like from Cisco won't be able to manage it smoothly. IBM WebSphere Message Broker exhibits the best performance in comparison to other tools in the market. 

The product's features are not being upgraded or enhanced by the vendor. The licensing cost of IBM WebSphere Message Broker needs to be reduced. Our company has to buy four to eight previews of the product for $4,90,000. For the aforementioned price involving limited transactions, our customers are often shocked and prefer to adopt an alternate middleware tool such as MuleSoft. 

I have been using IBM WebSphere Message Broker since 2005. 

I have never witnessed downtime in the solution, even for a few seconds. 

The product is not highly scalable, but I haven't faced any issues with horizontal or vertical scaling due to the lack of CPU and RAM specifications. In MuleSoft, if the CPU is using 70% space, then two more instances are auto-created, which hinders performance. 

The support for IBM WebSphere Message Broker is not up to the mark. I am aware that customers have to wait two or three months to get their issues solved. As a partner, if our company raises a ticket, it gets resolved in a very short span, but the service is not the same for other direct customers. 

The initial setup is straightforward. Majorly the product is deployed for being connected to WMS by accepting XML files. The setup process takes average time in comparison to others. For experienced professional, the maintenance of the product is effortless. 

The ROI for the product is often unrealized due to the massive licensing cost. 

It's a very expensive solution. 

Our company customers are gradually transitioning towards MuleSoft because they consider IBM WebSphere Message Broker outdated. In features comparison, MuleSoft might be a better tool as it offers an API database, gateway, and security features. 

I primarily use two previews of the product for Dev and two for QA as part of the production process. Whatever tools our company is using, the cost of a license in IBM WebSphere Message Broker is about 80% of all these software or tools. 

The message routing capabilities satisfy workflow efficiency. The product supports message formats of XML, JSON, and SSID, which are around 24 KB to 50 KB in size. The solution supports communication protocols like STTP and TCP. Features like DataGraph need to be introduced in IBM WebSphere Message Broker. 

Some of the clients of our organization are using an outdated version of IBM WebSphere Message Broker for which the vendor doesn't provide direct support anymore. For the aforementioned version, our company professionals can solve the queries on their own without seeking support from IBM.

During the installation of a prior version of IBM WebSphere Message Broker, sometimes I have to configure the failovers through the cluster, where issues arise, and I often seek help from the support team. The solution is being used by some medicine companies in our organization that receive sales orders from the EDR or JDE.

I would not recommend the product to others as its becoming obsolete and they can rather choose a middleware solution from Amazon or Azure. But I would overall rate the product a nine out of ten. 

We primarily use the solution as an integration platform to integrate disparate systems at the bank.

The solution has improved our organization by centralizing all our integrations.

The documentation, performance, stability and scalability of the tool are valuable.

The solution can be improved by making the product lightweight, as it is currently a weighty product.

We have been using this solution for 15 years and are currently migrating to the newest version on OpenShift.

The solution is stable and I rate the stability a nine out of ten.

The solution is scalable and I rate the scalability a seven out of ten. We have over 100,000 customers utilizing it and 10 engineers who develop on a day-to-day basis.

It is the first time we have implemented ESB or middleware.

The initial setup is a bit complex, so installation, setup and configuration require expertise to be done correctly. I rate the initial setup a seven out of ten. The implementation strategy was phased out, and we had the first few applications integrated and then we slowly implemented additional ones. The integration project took approximately eight months.

We initially implemented the solution in-house and then recruited two people who handle maintenance to assist.

We have had a good return on investment and I rate the ROI a six out of ten.

The licensing costs are a bit costly. I rate it a seven out of ten, with one being affordable and ten being expensive.

We implemented the solution 15 years ago but recently compared it with MuleSoft and TIBCO.

I rate the solution a seven out of ten.

I'm using this tool for my application. We configure it according to my application. For any new applications that are being onboarded, we engage this tool so that they interconnect and the datas are flowing as required.

For the last engagement, I had the latest version. I keep updating them for the bank standards, which should be the current version minus two. We look at the IBM website and use the versions for our application. We update frequently.

For my previous engagement, the initial project, it was almost 40-plus people who were using this application. For the current engagement, more than eight people are using it.

Message Broker is valuable because most of the applications are using MQ. Even in my current engagement, the few applications which I audit to onboard the bank are using MQ.

There is some lag in the GUI. There have been some performance issues and maybe it's because of the application data.

I have been using this solution for more than 10 years.

It's scalable.

We raised requests to IBM a couple of times. They were good enough at solving our problems. We felt like the associate who was trying to solve the problem wasn't that knowledgeable.

I also worked with IBM DataPower. When we have a connection from one organization to the other organization, there is very sensitive data to be passed from one organization to another organization.

Setup is very easy. We had proper documentation for setup, so it didn't take much time. It's quite easy when you have all the commands and everything in place, like if you know the downstream and upstream. Setup takes a maximum of two or three hours, and I can set up the complete application.

I would rate this solution 7 out of 10. 

My advice is to make use of the tool 100%. I have seen many people who aren't using it properly. There's a lot more to configure and monitor. I see they use 60% of what it gives. I advise people to just see the options and use everything and that will create a wonderful product for them.

We use IBM WebSphere Message Broker as an Enterprise Service Bus, integrating with different applications.

The most valuable feature of IBM WebSphere Message Broker is the ability to facilitate communication with legacy systems, offering a multitude of great capabilities. For example, if there is a mainframe system in place with a web service serving as the front end. In that case, the solution enables efficient protocol transformations to convert all request payloads into a format that the legacy systems can accept, rendering the integration and transformation processes seamless and highly effective.

I know that Message Broker was a very tightly copied product with another IBM product, that is, IBM MQ. I would like to have a little bit more decoupling from the IBM MQ because it should not be a prerequisite for IBM WebSphere Message Broker usage.

The goal is to minimize dependency and avoid frequent releases of a new version of the solution. Ideally, it is preferred to have a single version of the solution that can be sustained for a period of two to three years with only minor upgrades rather than a complete overhaul.

I have been using IBM WebSphere Message Broker for approximately 10 years.

The stability of the IBM WebSphere Message Broker is good.

I rate the stability of IBM WebSphere Message Broker a ten out of ten.

IBM WebSphere Message Broker is highly scalable.

I rate the scalability of IBM WebSphere Message Broker a ten out of ten.

I have on occasion reached out to the support from IBM WebSphere Message Broker. I have only used them for a few isolated instances occurring over a period of one to two months.

I rate the support from IBM WebSphere Message Broker a nine out of ten.

Positive

The initial setup of IBM WebSphere Message Broker is simple. Setting up the environment and doing penetration tests would take approximately a couple of weeks to completely test them. Approximately, 10 working days.

The solution is expensive.

Taking into account the technical aspect of IBM WebSphere Message Broker as a stand-alone solution, it has proven to be extremely stable and of high quality. However, in comparison to its industry competitors, such as MuleSoft or other ESB solutions, the issue with IBM is that they frequently release new versions of the solution, resulting in the need for updates that must be done frequently, thus causing an increase in license costs due to the support of older versions, ultimately leading to required upgrades. Consequently, IBM is falling behind its competitors in this area.

We would rate this solution a ten out of ten.

We have a large number of use cases for this product. It is built into the underlying infrastructure for most of our applications.

We only use the basic features, but the most valuable one for us is the Publish-subscribe pattern.

My biggest complaint about this product is the price. The cost is a significant reason why we're looking at other products right now.

Technical support is very slow and needs to be improved. Significant improvement is needed, especially when dealing with a tier-one client.

They are just now looking at Cast for their streams product, so they are a bit behind when it comes to technology. I no longer look to IBM for new technology.

We have been using the WebSphere Message Broker for more than 10 years.

We have had some issues in terms of stability.

I would say that a lot of our organization is running on this solution, although the scalability isn't perfect. I would rate the scalability a seven out of ten.

Our in-house software engineers are responsible for deployment and maintenance.

The price is very high and it's the main reason that we are searching for alternatives.

We are looking at replacing our IBM solution with RabbitMQ. It is currently being used in part of our business and we are thinking about expanding it to the whole enterprise.

There is also the option of Kafka, although you really have to understand your use case before engaging with it.

My advice to anybody who is looking at WebSphere Message Broker is to fully consider their use case. In general, I suggest looking for another product because there are better options available in terms of both cost and usability.

I would rate this solution a seven out of ten.

IBM WebSphere Message Broker can be used for routing, data transformation, and enrichment. It can be used for routing and data.

It's a routing solution. Irrespective of protocols, we can route the source through the destination.

All the features of the solution are important.

Stability and pricing are areas with shortcomings that need improvement.

I have been using IBM WebSphere Message Broker. Also, I am using the solution's latest version.

It is a stable solution.

It is a scalable solution.

I didn't get a chance to contact IBM's support.

The setup phase is taken care of by our admin team. We have already set up the solution locally. So when we give them BAR files, they deploy them. The time taken for deployment depends on Jenkins. They will create a pipeline. They will deploy it in a higher environment. In the local environment, we have a bash script is there, and we can just enter it for deployment.

The setup is easy.

At an enterprise level, only two or three administrators are required for deployment and maintenance.

A separate and dedicated team is there for the installation part. I'm the developer, and based on the requirement, I can give BAR files fail to those involved in deployment, and they will deploy it through a pipeline.

Though I did not evaluate other options before choosing IBM WebSphere Message Broker, we recently moved to App Connect.

I would definitely recommend the solution to those planning to use it.

I rate the overall solution an eight out of ten.

My primary use case of this solution is as an application server as well as everything else related to the whole suite from IBM.

The most valuable features are the product's straightforward development and deployment, and its nice graphical user interface.

When choreography is necessary, the product doesn't work. IBM has to take a different approach to maintain the software as a service solution. The price could also be lowered.

I've been using this solution for about seventeen years.

The scalability depends on how you build it, but it's easy to scale if you do it right.

The tech support is good, I have had no issues with it.

The initial setup is relatively straightforward, depending on how knowledgeable the person in charge is.

This product is expensive.

If you have access to resources, it's not hard to learn to use this product. However, today I probably wouldn't go for Message Broker because of the cost structure, support, and the whole ecosystem around IBM. I would rate this solution as five out of ten.

We had different use cases such as point-to-point, and public subscribers. We have some APIs building business Message Broker and we have divisions such as the legacy mainframe. 

We pretty much use everything. Most of the integration is done with Message Broker.

Working in retail we get a lot of traffic on Black Fridays and Cyber Mondays, and during that time, whatever serves have been deployed we want to scale them vertically. 

We can create multiple nodes within the service itself and when we are not using it, we can stop all of those nodes.

Most of what we have is on MQ for communication, and it integrates well with MQ.

Before the cloud, it was very easy for us to build and it was quick to integrate.

Integration and mapping are easy, which is a major advantage. 

It integrates with MQ.

Scaling up and down is easy for us using execution groups and nodes.

It is easy to set up and deploy.

If you want to connect to the database, it provides solutions in India, but you have to purchase it separately. They are not mature enough and we have difficulties using them. They are expensive and not worth the money we are spending on them.

I feel with IBM, when you want certain functions or features, you have to continuously purchase add-ons.

Scalability needs improvement, it was easy to scale before microservices and Docker.

Technical support is good but they could have a better response time.

I think that they should provide us with some kind of capabilities that can be deployed. For example, if they have integration nodes that can be deployed separately instead of having a new, big server that has different components, to give us the capabilities to deploy everything on our own instead of building them up together. It would benefit us when it comes to scaling and building.

We have been using this solution for seven years.

We started with Version 7 and now we are at 10. 

We are planning to use Version 11 and move to the cloud. It's still in process.

I would say that it's pretty stable, we have quite a bit running on it. It depends on how we configure it or what kind of infrastructure we are providing. For example, if we migrate from an old version to the new version and it's not done properly, you will experience it crashing every time. We had to build properly around it to achieve the proper results.

If it is being used with a simple deployment or as a server, without doing a proper configuration, then it may not work well.

It was scalable before microservices and Docker. It is now looked at differently. With the new version of Message Broker, it's promising to get capabilities that we can use.

We have a team of 10 to 15 developers, senior developers, and leads who are using this product.

Technical support is really good.

I would rate them an eight out of ten because it goes from level one, two, or three and sometimes it takes time, based on the priority of the ticket that we are creating.

Previously, we were using Profusion. It was along the same lines as IBM WebSphere Message Broker. We ran into many different issues and at one time, we were running two solutions, Message Broker and an Oracle solution. Oracle has a database with different capabilities. It records every question that comes in. It was very difficult to maintain, and it just kept crashing and consumed the memory.

It has so many issues, we stopped using it and went with IBM WebSphere Message Broker.

If you compare it with the previous versions, this was pretty straightforward and easy to set up.

There are always additional fees.

It's a good solution but it's questionable now that microservers have come into it. I can't really comment on whether I would recommend this solution for those who are looking to implement this solution, because everyone has their own use case.

I would rate IBM WebSphere Message Broker an eight out of ten. I had a good experience with this solution, and have not had any issues that we could not fix or handle.

We are system integrator and solution provider and this is one of the products that we implement for our clients.

It comes with a development tool and we use it to develop integration flows. I am normally working with financial companies when using this solution. They use it for communication between heterogeneous applications at the backend. 

Message Broker has a broad set of application adapters that are used to integrate a very large list of applications.

Performance-wise, this solution is really stable and reliable.

The size of the container used in the deployment is still a bite large and I think it should be improved and become lighter.

It would be useful to make container deployment easier .

I have been working with IBM WebSphere Message Broker for the past seven(7) years.

This is a very reliable and stable solution that is used for a very large number of transactions. It has been on the market for about 20 years, so it is mature.

This product is scalable.

I have been in contact with technical support and I find them to be good. Sometimes when I raise a ticket, it is just to get extra support to provide guidance for a feature that has been improved or discontinued.

Given the stability of this product, it is rare that one opens a support case because of a defect in the code.

I am familiar with some other solutions that have a fancier toolkit and are easy to use, but with IBM, it is more stable, reliable, and trusted. At the same time, it is more expensive than other products on the market.

The most recent version is really easy to install and configure, which will take about one day. The deployment is a simple drag-and-drop, so deploying it will take two days at the maximum.

This product is more expensive than competing products.

We compare other options for our customers and we look at the pros and cons of each solution. Normally, customers decide based on their budget, the features, and the expected workload. In most cases, I recommend IBM.

This is a good solution and when I have a customer that needs something with this capability, it is the first option that I suggest to them.

I would rate this solution an eight out of ten.