My main use cases for IBM WebSphere Application Server are mostly web-oriented, involving Servlets, core Servlets, and Beans, which includes my personal projects.

The use cases for IBM MQ in my context involve working in tandem with WebSphere, where data is taken based on events. I notice that people are increasingly moving towards Kafka, especially here, as it performs similar functions to IBM MQ.

In my opinion, the best features of the WebSphere Application Server make it the ultimate product. There is nothing higher than WebSphere. The market has Tomcat, JBoss, and other low-level application servers, but then there is WebSphere. I prefer WebSphere particularly on AIX because it's a very powerful engine. AIX is a powerful engine, and I don't think there is any UNIX system which is better than AIX. I'm 100% confident about that. I have been working with AIX since my time as an IBMer in Europe and also here in the Royal Bank, where we have a huge forest of AIX machines, running WebSphere on many of them. I also have experience with WebSphere in Windows, which is also very good; from an administrative and development point of view, it's transparent. There is not much worry about having WebSphere on AIX or Windows.

I would assess the integration of WebSphere with third-party tools and services in terms of modernizing the IT infrastructure as very good. I was involved in an application where I integrated WebSphere with Node.js and also with Blue Prism. I executed many REST applications because at my core I am a developer. Although my title is architect, I am still a geek and a developer, and I started as a developer, so I carry that passion with me.

At the Royal Bank, I have benefited from WebSphere's high availability and clustering because the overwhelming majority of our environments are clustered with IBM HTTP Server in front. We have clusters not just with two WebSphere engines; some of them even have four or six WebSphere engines, all managed under IBM HTTP Server. Everything is federated.

From my perspective on the best features of IBM MQ, if given the choice between Kafka and IBM MQ, I would choose IBM MQ as it is by far the best. However, people opt for Kafka because it is open source and comes at no cost. This conveys my mantra that the best solution doesn't always align with being the right one, highlighting the significant difference between the best and the right.

Regarding the improvement of the WebSphere Application Server, WebSphere is at version 9.0.5.23, and last month they released another fix because they periodically put out fixes. Previously, there were very frequent version increases, but now they maintain the focus on 9.0.5 and its different releases. Oracle announced that 2030 will be the last year when Java 1.8.x will be supported, which raises questions about the future of WebSphere since it is based on Java J2EE 7 and Java SDK 1.8. I wonder what the future holds for WebSphere after 2030 since I have never seen any communication from IBM detailing this trajectory.

I have around eight years of experience with IBM products in general, as I was working with IBM Eastern Europe in Vienna before coming to Canada, and I worked with WebSphere, OS, even OS operating system, AS/400. At that time, it wasn't I5, I6; the name was AS/400. After coming to Canada in January 1998, I worked with IBM Canada in Steeles, Toronto, until 2002.

I would rate the support from IBM for their WebSphere Application Server as very good, although I have only called IBM for support two or three times in my life. Most of the time, I figure things out myself, so I would rate it a 10, with 10 being the best.

For IBM MQ support, I have only contacted support once in my life, and the experience was very good, so I can't complain. I would rate it a 10.

In my opinion, the initial setup of the WebSphere Application Server is not complex at all. I have been working with WebSphere since my time in Romania as part of IBM in Vienna, and now it is straightforward for me. While it might seem challenging at the beginning, once you get your hands on it, it becomes very straightforward.

The price of the WebSphere Application Server at the Royal Bank is influenced by our unique agreements with IBM, as it's a large establishment with numerous IBM products, including mainframes. I am not aware of the specific agreements, but it is similar to purchasing in bulk, where the pricing structure is not the same as buying a single item at a grocery store.

I still use IBM WebSphere Application Server, specifically the latest version which is 9.0.5, and I work with IBM MQ and Rational as well.

I have not had any experience with AppScan or other testing tools; I am not utilizing any tools besides Rational.

I have used management tools with IBM MQ, and I find them beneficial for optimizing message flows. I utilize these tools, but often rely on my instinct, as IBM MQ is built on Java, which I have extensive experience with.

Regarding high availability with IBM MQ, we also have IBM MQ in clusters. Having IBM MQ in a cluster is useful since the cluster setup means we have some form of high availability.

I rate this solution 10 out of 10.

The main use cases with IBM MQ recently would be more of a publish and subscribe mechanism where we have multiple subscribers for the same data which is getting published and that's where we have utilized it.

However, we are moving away from it because it has limited options for scaling up and down.

Additionally, the licensing was one of the factors since it was a licensed copy and it cost us whenever we needed to scale up and down. That's where we are moving to Apache-based services such as Kafka.

The best features of IBM MQ were stability and straightforward application functionality. It has vendor support, which was a significant advantage. In case of any production issues, we definitely get vendor support, whereas with Kafka and others, we have to rely on open community and our research.

We have utilized high availability with IBM MQ through clustering in place, which was in the cloud. It was always available for us and worked very effectively. The only issue we encountered was related to scaling up and down, which required installing additional servers from a hardware perspective.

Regarding IBM MQ's transactional integrity and maintaining data consistency, it performs effectively and I never faced any issues with respect to transactions or data loss.

The management tools come along with Universal Messaging, so explicit implementation of other tools isn't necessary.

IBM MQ comes with all the necessary encryption options and security features that we need.

The main differences between these two products, both pros and cons, in my opinion, mainly concern the scale up and scale down capabilities, which are more impacting us.

Apart from that, I don't see any issues.

I have dealt with this product, IBM MQ Universal Messaging, for close to four years now. Previously it was Software AG before being taken over by IBM.

It has vendor support, which was a significant advantage. In case of any production issues, we definitely get vendor support, whereas with Kafka and others, we have to rely on open community and our research.

IBM MQ has limitations regarding scaling options. The licensing costs associated with scaling up and down were significant, which is why we are moving to Apache-based services such as Kafka.

The main differences between these two products primarily concern the scale up and scale down capabilities, which are more impacting us. Apart from that, I don't see any issues.

I would rate their support as nine out of ten so far.

We are moving away from it because it has limited options for scaling up and down. The licensing was one of the factors since it was a licensed copy and it cost us whenever we needed to scale up and down. That's where we are moving to Apache-based services such as Kafka.

I work as an integration architect who helps integrate applications, handling data passing to SAP CRM, SaaS-based applications, databases, or Databricks applications. In integration, I am familiar with IBM MQ and Kafka. Regarding IBM MQ, it is IBM Universal Messaging tool, which is similar to what MQ is. I have rated this solution 9 out of 10.

My use case for IBM MQ is that it's a middleware solution for our enterprise.

The features of IBM MQ that have proven most effective for ensuring message delivery reliability are the stability of the system, the resilience and the product, which is definitely of top quality in this segment. This is a product which is very common, and many competent products are there, but it's time-tested, very stable, highly resilient, and has all the features to troubleshoot even if something goes wrong. It's the best from all perspectives.

The areas of IBM MQ that have room for improvement are its compatibility with the public clouds, specifically its compatibility with Azure or AWS, as there is definitely a lot of scope for improvement there.

In our organization, we have been using IBM MQ for around 10 years, but we moved it to cloud two and a half years ago. The product has been in use for the last 10 years on-premises, and recently, for two and a half years, we have been using it on cloud.

We used a direct service from IBM for the deployment of IBM MQ in our environment. It is not a third party, but it is a service taken from IBM itself. There is an IBM subsidiary IT team in the Middle East who has helped us.

I would rate the technical support from IBM as seven out of 10.

The reason for this rating is due to the turnaround time, which is an important factor. IBM follows a practice of raising a ticket and has specified turnaround times to get back to us. Though usually, if it is high priority or top priority, they turn around faster, even for medium or low priority issues, their turnaround time is not as good to complete our project. We cannot hold on to the project for a long time just to wait for IBM to fix the issues. Our project will have its own timelines, so we expect turnaround times for medium and low priority incidents or tickets to be better than what IBM is currently offering.

I did not use a different solution before IBM MQ. For the last 10 years, we have been using this solution, so I don't remember what was there 10 years back.

The initial setup of IBM MQ was complex on cloud. If it had been on-premises, it would have been very simple. On cloud, it is complex, and we had to take help from IBM itself for that.

We used a direct service from IBM for the deployment of IBM MQ in our environment. It is not a third party, but it is a service taken from IBM itself. There is an IBM subsidiary IT team in the Middle East who has helped us.

I have seen an ROI from IBM MQ in terms of its role as a tool for integration platforms; however, it does not directly relate to any cost or revenue. It does not have functional features, as it's a product which integrates the external systems with internal systems or among the systems themselves, making it an essential technology component required to integrate multiple systems.

The price of IBM MQ is definitely on the higher side. There are many market-competitive products, but this is a top product in the market and messaging middleware software, so the cost is high.

The approximate number of end users in our organization using IBM MQ is roughly 30.

I would recommend IBM MQ to other people.

I do not wish to disclose my organization's name or email because this does not represent the organization's viewpoint officially.

I rate IBM MQ overall as a seven on a scale from 1 to 10, when 1 is the worst solution, and 10 is the best solution.

We use it for payment processing and to send these payments abroad in another country.

We use it for the production environment, and we consider it stable enough, which is why we continue to use this product.

The biggest advantage is that it's a reliable enough product which we use, and it's a highly documented product. We can learn it slowly, so we have experienced users and experienced staff to use this product.

We suppose it's secure because we use secure tools within the frame of this product, such as TLS 1.3 and so on. Its scalability is enough for our purposes, and that's all we can say about it.

Currently, we have some disadvantages; it's a bit difficult to use IBM ID to access support from the IBM site. To get nice support from IBM, we need to use IBM ID, and it's a bit complicated to integrate it with IBM support.

Support can be better because sometimes we need explanations for some behaviors of the product, and it's not easy to reach the proper person in IBM support.

They could add some new features into IBM MQ to make it better. A graphical user interface in addition to MQ Explorer could be useful, but we are satisfied with MQ Explorer as well.

We have been using it in general for about 10 years.

We have some experience with installations, and it's difficult. We need to state that it requires some experience and knowledge. We have required experience, having used this product about 10 years.

Its scalability is enough for our purposes, and that's all we can say about it.

Support can be better because sometimes we need explanations for some behaviors of the product, and it's not easy to reach the proper person in IBM support.

I cannot compare with other products, and I cannot give exact answers regarding whether it's expensive or cheap, as I don't know the costs of other products in this group. For us, we pay for it, and we rely on this product, and it's okay.

It's possible to get some training, but the cost of this learning is expensive. It costs some money, but we have required experience and knowledge because we have been using it for about 10 years.

It's possible to get some training, but the cost of this learning is expensive. It costs some money, but we have required experience and knowledge because we have been using it for about 10 years.

I cannot compare with other products, and I cannot give exact answers regarding whether it's expensive or cheap, as I don't know the costs of other products in this group. For us, we pay for it, and we rely on this product, and it's okay.

I'm just a user, representing Raiffeisen Bank, and it's clear.

We use WebSphere MQ, which includes some tools such as ActiveMQ, IBM MQ, and VMware.

Today, we don't use AI for our purposes, but if we find any useful AI features for this product, we might use them later because we can't evaluate their reliability for our needs right now.

On a scale of 1-10, I rate IBM MQ a nine.

Primarily used for IBM MQ data transfers.

As a user of IBM MQ, I use it for data transfers, configuring the queues and similar tasks. I do not work with it beyond those functions.

It is primarily used for data transfers within the applications. That encompasses the most critical features and functionality for me.

The biggest advantage of IBM MQ is its reliability.

IBM MQ is reliable and includes important security aspects.

IBM MQ is still in a premature state. It is in a research phase, so it is very early to make specific suggestions about improvements.

The stability of IBM MQ rates at eight or nine out of ten.

The scalability of IBM MQ rates at eight out of ten.

Scalability and sustainability could be examples for IBM MQ.

Any product of this nature should be scalable and sustainable. It depends on how the product evolves, how it has been implemented in the organization, and how we manage it.

I found the information about IBM MQ on the website to be good.

I am just a user of IBM MQ conducting research and reviewing it.

Being a user of IBM MQ, I do not have detailed knowledge about the specifics. The support team handles those aspects.

We are informed about issues with IBM MQ periodically. However, we do not necessarily receive complete information about why certain things were not working, as it is outside of my purview.

From a sustainability perspective, there might be room for consideration regarding IBM MQ. Otherwise, it performs well.

My final rating for IBM MQ is nine out of ten points, where ten is the best.

The use case for IBM MQ is for message transfer between banks and SWIFT, and message transfers within applications in banks. These are the most used cases.

IBM MQ is more reliable and secure than other software. There is a saying that for the last 30 years IBM MQ has never been hacked. It is more secure and reliable. Whenever the configuration is done, I do not have to touch it again. It works fine, it is stable, and its communication is to the point and accurate. All performance-related aspects are better.

Performance-wise, it is scalable, and other features such as DR, DC, replication, and active passive mode are complex to configure, but it remains scalable.

The pricing model for IBM MQ could be more flexible for clients.

Regarding improvements in IBM MQ, I cannot specify any issues because whatever requirements exist, I find them available since it is a very old product with all necessary features. I am not encountering any missing features in IBM MQ.

Feature-wise, everything required is available in IBM MQ. The pricing is consistently high, which is known in the market. In that scenario, pricing could be more competitive compared to other vendors.

The pricing model for IBM MQ could be more flexible for clients.

I have been working with IBM MQ for 3 years.

I would rate the stability for IBM MQ as nine out of ten.

While not easy, IBM MQ is scalable. Performance-wise, it is scalable, and other features such as DR, DC, replication, and active passive mode are complex to configure, but it remains scalable.

I would give technical support from IBM an eight out of ten.

The response time for IBM MQ support could be better because when we are using IBM MQ and something goes wrong, support is required as the resource availability of the IBM product is very limited.

Some of my customers are now using IBM MQ. Previously they were using Kafka, but after using IBM MQ, they decided to move to IBM MQ and remove Kafka because IBM MQ is more reliable and more performance friendly than Kafka.

The initial setup for IBM MQ is very simple.

For security, scalability, and performance, I suggest IBM MQ. However, customers have budget constraints and other considerations including application portfolio and requirements. There are alternatives such as Apache MQ and RabbitMQ. The choice depends on the budget, requirements, and priorities regarding security, performance, or budget. We can suggest the best solution, but if the customer cannot afford it, they might opt for the free option, RabbitMQ, or Apache MQ. It ultimately depends on the price and application needs.

It depends on the application regarding what company size can use IBM MQ. If a small or medium company uses a complex application where security is measured, with multiple applications, they can use it. For enterprise level, it is mandatory if they require it because IBM MQ is a requirement product, not a day-to-day product. If you want the best solution then choose IBM MQ. I cannot suggest that small companies need it and enterprise companies do not need it. I rate this solution nine out of ten.

We deal with financial and non-financial transactions, and most of the financial transactions that interact with backend vendor systems are done via IBM MQ. It is manager-to-manager communication, and the transaction load is huge. That is one aspect where we need IBM MQ to communicate with backends.

With the setup that we have, financial transaction messages are not lost. We are primarily looking for a 100% quality of service in terms of non-repeating the message and message delivery. These are financial transactions, so we do not want to lose the message at any cost. That was the main reason why we have IBM MQ. Additionally, when dealing with posting financial messages to backend vendor systems, most of the revenue gets generated.

I extensively worked on IBM MQ some time back, but not at this point in time. We are dealing with IBM MQ client applications mostly, so I don't see any enhancements needed for the IBM MQ layer.

I never used ActiveMQ or Amazon MQ. I have been using IBM MQ for the past fifteen years. It was my first message-oriented middleware, and I have been using the same middleware. I did not get an opportunity to explore other message-oriented middleware available in the market.

No mentions of deployment issues in the transcript.

MQ is just a message staging engine and not a processing engine. Usually, processing engines would be either DataPower, API Gateway, API Connect, or ESB. The transaction is always guaranteed with IBM MQ, which is the main reason I have been working with it for fifteen years while dealing with financial transactions or messages. The message availability is always guaranteed.

The implementation utilizes multi-instance managers. As it is a container version, we can vertically scale it. In our environment, we do not have horizontal scaling for IBM MQ, but as demand increases, we would just vertically scale it.

Right now, I am not working on IBM MQ extensively, and we do not delve into any of its PMRs, so the support should be good. With containerized flavors of these products, we are having a tough time dealing with PMRs because the versions are new to IBM. However, for non-containerized flavors running on blade, VMware, or appliances, they are pretty good. I would give them a rating of eight for their overall service.

The setup is very straightforward, and it's not complex, even with container flavors. It's very easy with the advent of OCP operators shipped with CP4I. You can create a manager in less than a minute's time. It's not challenging at all.

We have a huge team that maintains the infrastructure of the entire stack and manages applications deployed on top of IBM MQ and other solutions. But just for infrastructure, even for a production-ready data center, it shouldn't require more than a couple of resources.

The kind of workload we have deals with posting financial messages to backend vendor systems, and most of the revenue gets generated. There are definite cost savings and return on investment.

IBM MQ is pretty reasonable when compared to IBM ESB. We do not take advanced security licensing for our transactions.

I would rate the solution ten out of ten because I have been working on it for the past fifteen years. The message availability and transaction guarantee with IBM MQ is the main reason. I would rate it a ten overall.