EDUCBA

Home Software Development Software Development Tutorials Top Differences Tutorial Kafka vs JMS

Kafka vs JMS

Updated May 16, 2023

Kafka-vs-JMS

Difference between Kafka vs JMS

The following article provides an outline on Kafka vs JMS. Apache Kafka is an open-source stream-processing software developed by LinkedIn (and later donated to Apache) to effectively manage their growing data and switch to real-time processing from batch-processing. It is written in Scala and Java and is based on the publish-subscribe model of messaging.

Start Your Free Software Development Course

Web development, programming languages, Software testing & others

On the other hand, JMS (Java Messaging Service) is a Java message-oriented middleware API for sending messages between two or more clients. It was developed to remove the tight coupling between producers and consumers.

Head to Head comparison between Kafka Vs JMS (Infographics)

Below are the top 12 differences between Kafka Vs JMS:

Kafka-vs-JMS-info

Key Differences Between Kafka vs JMS

Let us see some of the major key differences between R and R squared.

Kafka and JMS are designed for different purposes. Kafka is a distributed streaming platform that offers high horizontal scalability. Also, it provides high throughput and that’s why it’s used for real-time data processing. JMS is a general-purpose messaging solution that supports various messaging protocols. Kafka is way faster than JMS. It can handle millions of messages per sec.

Kafka ecosystem consists of the following elements:

  1. Kafka Producers
  2. Kafka Consumers
  3. Kafka Brokers
  4. Kafka Partitions
  5. Kafka Topics
  6. Zookeeper

JMS comprises of the following elements:

  1. JMS provider
  2. JMS client
  3. JMS Producers
  4. JMS Consumers
  5. JMS queue
  6. JMS topic
  • JMS supports both message queues and publishes/subscribes messaging systems. Kafka, on the other hand, is based on publish/subscribing but also incorporates certain advantages of message queues.
  • JMS guarantees that a message will be delivered, but with Kafka, there is a probability (however low it is) that a message might not get delivered. Message loss in Kafka can happen in the following scenario:

It can happen while consuming messages in parallel. Assume a situation where there are two consumers x and y and two messages A and B to be processed in parallel.

x successfully processes the message A and commits the offset, but y couldn’t process message B successfully. Message A has a larger offset in comparison to message B and Kafka saves the latest offset. Thus, message B is never re-processed and hence lost.

  • It’s fairly easier to implement exactly-once message delivery in JMS than it is in Kafka. Duplicate message delivery in Kafka can happen in the following scenario:

The consumer has consumed the messages successfully and then committed the messages to its local store, but it crashes and couldn’t commit the offset to Kafka before it has crashed. When the consumer restarts, Kafka will deliver the messages from the last offset.

  • In Kafka, a message is basically a key-value pair. The payload of the message is the value. Key, on the other hand, is generally used for partitioning purposes and must contain a business-specific key in order to place related messages on the same partition.

In JMS, a message consists of metadata (headers and properties) and body (which is the payload).

Kafka vs JMS Comparison Table

Let’s discuss the top 12 comparisons between Kafka Vs JMS

Kafka

JMS
1. It is a distributed system meant for processing huge amounts of data.

It has the following use cases:

  •  Messaging
  •  Website Activity Tracking
  •  Metrics
  •  Log Aggregation
  •  Stream Processing
  •  Event Sourcing
  •  Commit Log
 1. It is a traditional messaging system that deals with a small amount of data.

It has the following use cases:

  •  Transactional Messaging
  •  Web Chat communication for customer service.
  •  Debug logging on the backend.
  •  Dynamically Configuration and Controlling Clusters.
  •  RESTful API to messaging using HTTP
2. Kafka initially didn’t support transactions, but since its 0.11 release, it does support transactions to some extent. 2. It has transaction support. If you want to use transactions, you have the following transaction options:

  • Transacted Session
  • Message-driven beans with
  • Message-driven beans with BMTD
3. Kafka producers don’t wait for acknowledgments from the Brokers. So, brokers can write messages at a very high rate resulting in higher throughput. 3. It maintains the delivery state of every message resulting in lower throughput.
4. In Kafka, it’s the responsibility of the consumers to consume all the messages they are supposed to consume. 4. In JMS, it’s the responsibility of the producers to ensure that messages have been delivered.
5. It can ensure that messages are received in the order they were sent at the partition level. 5. It cannot ensure that messages are received in the same order they were sent.
6. Kafka doesn’t have any concept of filters at the brokers that can ensure that messages that are picked up by consumers match a certain criterion. The filtering has to be done by the consumers or by the applications. 6. There is something called JMS API message selector, which allows a consumer to specify the messages it is interested in. So, the work of filtering messages is up-to-the JMS and not the applications.
7. It is a pull-type messaging platform where the consumers pull the messages from the brokers. 7. It is a push-type messaging platform where the providers push the messages to the consumers.
8. It is highly scalable. Due to replications of partitions, it offers higher availability too. 8. It is not possible to scale horizontally. There is also no concept of replication.
9. It doesn’t slow down with the addition of new consumers. 9. The performance of both queue and topic degrades as the number of consumers rises.
10. It includes checksums to detect corruption of messages in storage and has a comprehensive set of security features. 10. It doesn’t provide checksums to detect corruption of messages out of the box.
11. It is a reactive programming style. 11. It is an imperative programming style.
12. Messages can be re-read as they are not deleted once consumed. 12. Messages cannot be re-read.

Conclusion

We have seen that Kafka and JMS have different use cases. A company will go for Kafka if it has to process a huge amount of data in real-time and can bear message loss to some extent. Whereas, JMS would be the proper choice if it cares about one-time delivery and messages are valuable (like in financial transactions).

Recommended Articles

This has been a guide to Kafka vs JMS. Here we discuss their introduction, key differences, and comparison table. You may also have a look at the following articles to learn more –

    1. R vs R Squared
    2. ActiveMQ vs Kafka
    3. DDL vs DML
    4. iPhone vs Android