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.

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.

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.

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.

The tool is expensive.

I have been working with the product for four years.

The tool is scalable.

IBM MQ is stable.

The tool's support is not cheap and fast. You can't expect a resolution from support.

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.

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.

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.

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.

IBM MQ is the standard for financial industry messaging. As far as I know, it is the best in class.

Standard, most reliable messaging infrastructure software.

The most valuable feature of IBM MQ is it has all the features necessary for contemporary messaging, not only for the financial industry but for any application.

IBM MQ has developed into some newer solutions. It has a message broker, it is now on the cloud, it has containerization, that has high availability features

IBM MQ may not be as convenient for Java programmers as Active MQ, for example, because Java programmers prefer Java, even though it is slower.

IBM MQ could improve by adding more protocols or APIs for a standard application, such as MuleSoft.

I have been using IBM MQ for approximately 15 years.

IBM MQ is stable, performs well, and is highly reliable. They guarantee message delivery.

The scalability of IBM MQ is good. There are cluster, container, and broker features available. It scales well horizontally and vertically.

Most of our company is using IBM MQ in my company.

The support from IBM MQ is good. They have always helped with my problems, but sometimes it can take them a while for a resolution. Sometimes you might find a bug in a one-year span of using the solution, but they will provide a fix within a matter of weeks.

N/A

The initial setup of IBM MQ can be straightforward if you have the documentation, it is step-by-step and straightforward.

IBM MQ is an expensive solution compared to other solutions. However, if you pay less you will not receive the same experience or features.

N/A

It may not have all the APIs, features, or protocols that the newest systems have, but in performance and reliability, it is the best.

The amount of people needed to maintain the solution depends on the company and how they want to maintain it. When I was working for a bank I supported 300 MQ managers with approximately 150 systems running. However, for the basic use of the solution, you do not need many people. If you add more features, such as broker and clustering you will need more people for maintenance.

My advice to others is this solution is the best there is. For maintenance, you will probably need fewer people to maintain it than other solutions because of its reliability. The features are probably the most extensive in its class.

I rate IBM MQ a ten out of ten.