MQ

So you’ve heard of IBM MQ, or maybe had heard it once in the past under one of its earlier names, WebSphere MQ or MQSeries, but you don’t really know what it is, what it does, or why it would be relevant now? Or maybe you know some about it, but simply think it is legacy and isn’t important or relevant in today’s world of cloud and containers? Apache Kafka is getting lots of press these days, and is a great tool. However, do not make the mistake of thinking that Kafka is the first messaging or only messaging solution. This article will explain exactly what IBM MQ is, what it does, and explain exactly why it is even more relevant now than ever. 

What is Messaging?

So let’s start with explaining exactly what messaging means, since it is an overloaded term. When we talk about messaging, we are referring to message-oriented middleware (MOM). Message-oriented middleware is software (or hardware) infrastructure supporting sending and receiving messages between distributed systems. This allows applications or services, the messaging endpoints that send and/or receive messages, to be on heterogeneous platforms, with different operating systems, different application languages, different processors, and span different network protocols. The middleware creates a distributed communications layer that insulates the application developer from all of these details and complexities, and allows applications to interact with one another. Rather, simple interfaces are used to communicate. In addition, the middleware offers administrative capabilities and tools to ensure reliability, security, and potentially other capabilities such as high availability.

Typically, messaging supports asynchronous communication between the endpoints. Message queues are typically supplied by the messaging middleware to support the asynchronous exchange of messages. A message queue might reside in memory or on disk storage. Messages stay in the queue until the time they are processed by a service consumer. Through the message queue, the applications can be implemented independently, not needing to know anything about each other (other than the way messaging is implemented, meaning if A sends a message to B, does B send a reply to A?).

A good way to understand messaging vs. developing applications that directly communicate with each other is to consider the old fashion telephone system vs. modern phone systems with voice mail. In the old days, the only way for someone to “make a call” and talk to someone else on the telephone was for a telephone operator to “plug” the two connections together, and thus, allowing communication between the two parties.

However, now, not only is the operator not there “wiring” connections together, but when you make a call, it is okay if the other party is not available, as you can leave a voice mail “message” that the other party will receive when they are ready for it, completely independently. This is the key difference between what messaging provides in asynchronous communication versus synchronous between two applications.

This leads to the idea of loose coupling. When tightly coupled, there are so many dependencies on the communication between the two applications, including each server, each application, the network between the two, etc. Many mechanisms for communicating between applications require that both applications are available at the same time. With loose coupling, it is okay if the receiving server is down when the sending server receives the message, and it is okay if the sending server is down or unable to respond when the receiving server reads the message. Loose coupling provides true messaging independence. Reducing the requirements for simultaneous availability reduces complexity and can improve overall availability. Messages can be sent to specific applications or distributed to many different applications at the same time.

Plus, then when one application needs to send messages to multiple other applications, your application gets very complicated very fast, with an ever increasing number of dependencies, and a connection diagram might look like this!

So messaging offers several messaging styles.

Point-to-point

Applications send messages to a queue and receive messages from a queue. Each message is consumed by a single instance of an application. The sender must know the name of the destination, but not where it is. The destination can be a single endpoint, or a list of endpoints referred to as a destination list. Note a distribution list is still point-to-point, as all endpoints are still named.

Publish/Subscribe

Applications subscribe to topics. When an application publishes a message on a topic, the pub/sub broker sends copies of the message to those subscribing applications. The publisher does not know the names of subscribers, or where they are.

Apache Kafka

Apache Kafka is an alternative messaging system, that uses publish/subscribe to support event stream-processing. It is based on an abstraction of a distributed commit log. It is based on an open source project. Kafka is highly complementary to IBM MQ. For a complete understanding of the two, including use cases, read “Why enterprise messaging and event streaming are different,” by Callum Jackson, Katie Stanley, and Dale Lane.

What is IBM MQ?

That can be answered many way, but I like what a colleague wrote recently: “IBM MQ is one of the greatest software solutions ever – that’s my opinion and likely the opinion of thousands of others.” This is an accurate statement. Many IBM MQ users love MQ and absolutely rely on it. IBM MQ provides proven enterprise-grade messaging for more than 90% of the top 100 global banks, healthcare, airline, and insurance companies, among many others.

IBM MQ is one of the most trusted message-oriented middleware products available today. It has been used by companies to reliably exchange messages across disparate platforms for over 25 years. In many ways, it is the defacto standard for business critical, enterprise messaging. MQ runs some of the most critical applications on the market, including within highly regulated industries ranging from Healthcare to Banking and Finance.

IBM MQ provides assured once and only once delivery of messages, allowing application developers to concentrate on their application code and not have to worry about dealing with communications code. Rather, they use a simple, standardized API across all platforms to send or receive messages.

Whether you’re in the cloud, on mobile, on-premises, or in the Internet of Things (IoT), IBM MQ messaging simplifies, accelerates and facilitates security-rich data exchange. High performance, stability, and assured message delivery are the main reasons IBM MQ is the preferred messaging backbone for dynamic heterogeneous environments. IBM MQ fits into every form factor, from containers to mainframes, from hardware appliances to managed cloud services and from stand-alone solutions to complete integration platforms.

The power of IBM MQ is its flexibility combined with reliability, scalability, and security. This flexibility provides a large number of design and implementation choices. Making informed decisions from this range of choices can simplify the development of applications and the administration of an IBM MQ messaging infrastructure.

Applications that access an IBM MQ infrastructure can be developed using a wide range of programming paradigms and languages. These applications can run within a substantial array of software and hardware environments. Customers can use IBM  MQ to integrate and extend the capabilities of existing and varied infrastructures in the information technology system of a business.

Simply put, the ability for IBM MQ to reliably deliver a message once and only once, with transactional integrity, is why it is used for truly critical messaging solutions. For example, when you withdraw money from your bank account, you certainly only want the message with that debit to be processed only one time, and not multiple times.

Is Messaging Still Important?

To many, this is an important question. To those that use messaging, it is not a question at all. Simply, messaging is more important today than it has ever been.

IBM MQ has always been about being everywhere, providing a consistent messaging solution across your enterprise. This holds just as true today, but the landscape has been changing.

Handling events is also growing in importance, as organizations do things like look to communicate between microservices.

And yes, in the messaging landscape, supporting event streaming is becoming a highly desirable capability.

The number and types of components making up a typical enterprise has exploded in recent years. In the early 2000’s it was common for an enterprise to have all of its applications and systems located within their own data center(s), under their own control. Today, however, you have multiple public clouds, private clouds, mobile applications, SaaS applications, Internet of Things and Edge communications, plus your legacy systems – all needing to exchange information.

Messaging connects those applications in the most flexible, highly available and scalable way. For business critical communication, with applications and systems across our enterprise, within our data centers or clouds, need to be able to communicate reliably, securely and simply. Technologies such as HTTP and REST APIs provide one option; however, this often lacks the quality of service required for business critical communication, such as exactly once delivery.

Conclusion

So yes, messaging is certainly an extremely critical part of most companies strategy today. It provides the critical bridges between all of our systems, regardless of where they are, what OS or what cloud, and what language the applications are written in, enabling simple but powerful and secure messaging between them. Providing a completely reliable, with once and only once delivery, messaging solution, able to asynchronously deliver the world's critical messages, is not only obviously still a critical need, but is exactly what IBM MQ provides its customers.

To learn more, see https://www.ibm.com/products/mq or go directly to an excellent IBM MQ website with details on MQ and offering some hands on options at https://developer.ibm.com/gettingstarted/ibm-mq/.