Kafka Vs. Java Messaging Service (JMS)

Enterprise applications need to share information with one another. And they do this by sending messages to one another. A vast number of messages are sent and received by different applications or databases.  (Learn more about using message queues such as Kafka)

Therefore, the question that begs is, how do these messages arrive at their destinations without getting lost or incorrectly delivered?

Enter the message broker.

The broker’s primary function is to facilitate the sending of data messages between two systems — the consumer and the producer.

For ease of understanding, let’s consider the following scenario.

Let’s assume you would like to purchase a new home. Where do you start looking? You need a go-between between yourself and the seller.

Enter the real estate agent who acts as a broker between the two parties and facilitates the congruent purchase and sale of the house. 

Similarly, both enterprise applications — the software that sends the message and the application that consumes (or receives) the message — require a broker or go-between to ensure the message is correctly sent and received. When millions of messages are simultaneously transmitted and received between the producer and the consumer from different systems, managing these message volumes is challenging. Hence, the need for a broker to ensure that the messages are correctly sent and received.

That begs the question: What is a message broker, and how does it manage the sending and receiving of messages?

By way of answering, let’s first consider the two most popular message brokers: Apache Kafka and Java Messaging Service (JMS). Once we have an insight into each broker, the final step is to look at the differences between the two and why you should use one or the other.

Message Broker Architecture

Before we look at these two products, let’s briefly look at what the message broker architectural patterns should look like.

The message broker’s primary function is to validate, transform, and route messages between applications as it mediates between the applications sending and receiving messages from and to each other. 

While mediating the conversations between the different applications, the message broker also facilitates the decoupling of endpoints between itself and the software applications it serves. In other words, the broker architecture is structured so the different layers or application components can execute independently of each other while still interfacing with each other. This architecture “separates a system’s memory access and instruction cycle processes from execution-stage processes by implementing a data buffer.” 

Apache Kafka: When, What, and How? 

Answering the “what” part of this section is best achieved by looking at what the Apache Kafka website has to say about the message broker:

“Apache Kafka is an open-source distributed event streaming platform used by thousands of companies for high-performance data pipelines, streaming analytics, data integration, and mission-critical applications.” 

Upsolver describes it as a “durable message broker, [or message bus,] that enables applications to process, persist, and re-process streamed data with a straightforward routing approach that uses a routing key to send messages to a topic.” 

In other words, Kafka is a topic-based system that utilizes a near real-time, low-latency, high-throughput data stream processing platform capable of managing real-time data feeds. 

The Kafka Architecture

The Kafka producer’s primary mechanism of collecting messages from external systems utilizes a pull-type method in that the producer pulls the messages from different enterprise systems or servers.

Then the consumer subscribes to a particular topic category and will consume the data, sending it to the message’s intended recipient. Thus, multiple consumers can subscribe to a single topic, and a single consumer can subscribe to multiple topics, a many-to-many relationship: many consumers and many topics. 

If we drill down into the Kafka cluster, we find the following architecture. 

Succinctly stated, for every Kafka message broker, there is any number of different topics. Each topic is subdivided into many partitions that stream the messages from the left to the right (old to new), writing each message to the consumer.

Kafka Vs. RabbitMQ

It might be worth looking into our previous article on RabbitMQ vs Kafka. RabbitMQ was released in 2007. It is a general message broker supporting protocols like STOMP, MQTT, and AMQP and was a fundamental part of providing messaging functions between SOA applications.

Even though RabbitMQ is currently being used for streaming use cases, Kafka is a purpose-built message streaming service that provides better functionality than RabbitMQ does.

Java Message Queue: What is JMS?

The Java Messaging Service (JMS) is a Java-based API and the first enterprise-level messaging API that gained widespread traction. It is a messaging standard that contains Java components used to send, receive, and read messages.

Its primary function and purpose are to send messages between two or more clients. Congruently, it controls communications between different components in a distributed application to make it loosely coupled, asynchronous, and reliable.

JMS was designed to simplify the process of developing business applications “that asynchronously send and receive business data and events.“ It is supported by a wide range of enterprise messaging products and supports both point-to-point queuing and publish-subscribe messaging models. 

The Java Messaging Service has an additional function in that it allows Java applications access to enterprise messaging systems. The JMS is considered Message-Oriented Middleware (MOM), a low level of abstraction that runs below layers such as database and application adapters, business process automation, and event processing. In summary, MOM is an essential driver for integrating multiple intracompany operations as it facilitates the combination of individual business components into a flexible and reliable system. 

The following diagrams provide a visual overview of the JMS MQ models — point-to-point and publish-subscribe message queues (MQ).

The Point-to-Point JMS MQ

The Publish-Subscribe JMS MQ

It is essential to note that, juxtaposed with the Kafka model, the JMS MQ utilizes a push mechanism as its primary message collection method. In other words, any application that is capable of pushing messages to a message queue can interface with the Java Messaging Service. 

The JMS MQ uses the imperative programming construct. It is the “oldest programming paradigm.” In other words, a computer program falling under this ambit comprises a set of clearly-defined sequential instructions. Once these instructions have completed running, the state of the variables is changed.

Kafka Vs. JMS: Why?

The individual Kafka and JMS descriptions provide insight into why it is preferable to use Kafka as a message queue solution rather than JMS. Because JMS has been around longer than Kafka, it is still utilized in specific use cases, including when you only need to process a small number of messages per day.

As described by the Kafka architecture diagrams above, Kafka is a near real-time data streaming solution. Therefore, it is useful for systems such as financial processing, IoT, and real-time maintenance solutions.

For instance, the processing of financial transactions requires real-time messaging to block fraudulent transactions as they occur. Another example is the IoT industry. One typical IoT construct: Each room in a building has many devices, including smoke detectors. These devices are linked to a central server and send messages to the server, requiring the server to make almost instant messages based on the messages received.  What happens if one of the detectors picks up the start of the fire? The device sends a message to the server, requiring the server to open the building’s fire suppression sprinklers. If the server takes too long to receive, process, and respond to the message, the fire will quickly spread, causing untold harm, including the loss of life. 

By way of contrast, the JMS MQ is not near real-time. While its message processing is asynchronous, it also uses the imperative programming paradigm, which can be substantially slower than the Apache Kafka method.

Final Thoughts 

Both JMS and Kafka are top-rated message management solutions. However, it is often considered preferable to use a more up-to-date platform and architecture in the form of Kafka. Before deciding what product to use, it is essential to consider the merits of each use case. As highlighted above, there are still use cases for JMS MQ, albeit few.