An Easy Guide to Java Message Queue: Compared With Kafka & RabbitMQ

Java Message Queue, RabbitMQ, and Kafka are all messaging technologies used to facilitate asynchronous communication in distributed systems. They all serve the same basic purpose but can go about their jobs differently.

This post seeks to help message queue administrators, application developers, and other parties who are interested in using Java Message Queue, RabbitMQ, or Kafka to understand and differentiate the technologies, concepts, architecture, capabilities, and features behind these products.

What Is Java Message Queue?

Java Message Queue is a messaging service that is used to create, send and receive messages from one application to another. It provides reliable, highly scalable, loosely coupled, asynchronous communication for microservices, distributed systems, and serverless applications. Processes running on different hosts on the same network, or loosely connected through the internet, can connect to the service to interact with each other. Java Message Queue offers all the features required by large-scale enterprise deployments.

Java Message Queue Core Components

There are 8 core components that make up a Java Message Queue application:

1. Provider – A provider, also known as a Message-Oriented-Middleware (MOM), is an interface for sending messages. It describes the objects sent and the objects involved in the conversion. It also provides control and admin features.
2. Client – A client is a Java application that is either producing or receiving messages.
3. Producer/Publisher – A producer is a client (source system) that creates and sends messages.
4. Consumer/Subscriber – A consumer is a client (destination endpoint) that receives messages.
5. Message – A message can be anything you like, but usually it’s texts or bytes organized in some agreed format.
6. Destination – In between the producer and the consumer is the queue that facilitates the communication. This is what is referred to as the destination.
7. Queue – If your message needs to be received by only one consumer, you need to use a queue. A queue guarantees delivery to one and only one client. If more than one consumer is connected to the queue, only one consumer gets the message. It’s first come first served.
8. Topic – If your message needs to be received by any and all consumers listening, you need to use a topic. A topic is a special type of queue that guarantees delivery to all consumers subscribed to the topic.

Java Message Queue Messaging Models

There are two types of messaging models supported by the Java Message Queue.

1. Point-to-Point Messaging Domain
2. Publisher/Subscriber Messaging Domain

Point-to-Point (PTP) Messaging Model

In the Point-to-Point (PTP) style of messaging, one message is delivered to one receiver only. The model is built around the concept of a Queue which is used as a Message-Oriented Middleware (MOM).

Messages are stored in the queue by the producer application and the consumer retrieves the messages from the queue. This facilitates the storage and forwarding of messages to the consumer application in an asynchronous decoupled manner.

In the PTP model, the message is delivered to the receiver only once. Once received and acknowledged by the consumer, it will then be removed from the queue. 

Publisher/Subscriber (Pub/Sub) Messaging Model

In the Publisher/Subscriber (Pub/Sub) pattern, you have the sender (publisher), the receiver (subscriber), and multiple queues called Topics. The publisher can send one message and it will be delivered to all the subscribers of the Topic just like broadcasting. 

Here, a Topic is used as a Message-Oriented Middleware (MOM) that is responsible for storing and delivering messages. The message will be removed from the queue only when all the subscribers have successfully read the message or when the retention policy expires.

What Is Java Message Queue Used For?

Java Message Queue has multiple use cases.

• The Java Message Queue can be used to develop distributed applications that follow an asynchronous messaging design pattern. It defines an Event Bus that buffers the messages between the sending and receiving process. This allows for non-blocking IO, where the current processes of the client application are not blocked while waiting for the downstream consumer to process the message. 
• It can be used as a Message-Oriented Middleware (MOM) that allows for transactions or event notifications to be sent and received over distributed software applications that are spread across multiple operating systems and networking protocols.
• It can be used as a cache if required. When building a distributed system, caching is often a primary consideration for capacity planning. Its features allow the Java Message Queue to be used as a caching technology.
• It provides well-defined rules for Application-to-Application Messaging such as syntax, semantics, load balancing, and failover.
• It provides a standard mechanism for applications running in a Java environment to interact with asynchronous messaging systems.
• It provides a client interface for both Pub/Sub and P2P messaging models.

Advantages and Disadvantages of Using Java Message Queue

Advantages	Disadvantages
High Throughput: The asynchronous messaging pattern enhances performance, allowing clients to interact with the queue directly, and avoiding delays caused by waiting on other clients.	Java-Only Compatibility: Limited to Java-compliant applications, posing a challenge in distributed applications with multiple languages and frameworks.
Robust and Reliable: Ensures once-and-only-once message delivery with mechanisms to filter duplicates when needed.	No Specific Message Format: Lacks a standardized message format, which can be a limitation in certain use cases.
Fault Tolerance: Stores messages persistently, ensuring recovery from failures without impacting other components.
Decouples Monolithic Apps: This breaks down monolithic applications into smaller, self-contained components, making systems easier to test, debug, evolve, and scale.

When to Use Java Message Queue?

When the time comes to choose a Message Processing API, Java Message Queue is a superior choice when compared to tightly coupled APIs such as REST and RPC in the following scenarios:

• Where a high degree of independence between the application’s components is needed. The components should share nothing such that changes in design or implementation in one component have no impact on the others that collaborate with it. This eliminates the risk of cascading failures when replacing or updating the components.
• When you want to eliminate the risk of a single point of failure in the application. The application should continue functioning normally regardless of whether all its components are up and running.
• Where your business model requires an eventual-consistency guarantee in the system such that the system can still perform other activities as it continues to wait for I/O to complete.
• Where applications need to communicate in many-to-many, one-to-many, or many-to-one architecture.
• Where you have background jobs or long-running processes that don’t require immediate feedback.

How Does Java Message Queue Stack Up Against Kafka & RabbitMQ?

RabbitMQ is an Open-source Message Broker Software that uses the AMQP standard. It has features that support highly available queues that can handle millions of messages with no perceivable dip in the publish/consume rates. Just like the Java Message Queue, RabbitMQ is a Message Broker that’s well suited to handle asynchronous messaging in distributed systems.

Apache Kafka on the other hand is an Open-source Stream/Message Processing Platform. Kafka is the leading Event Streaming Platform framework in the market. It’s a distributed system that can scale horizontally to handle millions of messages per second. Kafka can be used as a message bus, log aggregator, or storage system.

Comparison Chart: Java Message Queue vs Kafka vs RabbitMQ

Parameter	Java Message Queue	RabbitMQ	Kafka
Messaging Model	Supports one-to-one and pub/sub	Supports the AMQP model which has: direct, topic, fan-out, and header-based models	Supports pub/sub and queue-based messaging styles via topics
Push/Pull Mechanism	Uses a push-based model where messages are delivered to all consumers	Uses a push-based model	Supports a pull-based model where downstream consumers have to poll for the messages every time
Design Model	Uses a smart broker/dumb consumer model. The broker continuously delivers messages to consumers and tracks the delivery status	Uses the smart broker/dumb consumer model	Uses a dumb broker/smart consumer model. Producers do not monitor the messages that are consumed rather it’s the responsibility of the consumers to consume the messages that are intended for them
Data Flow	Producers send messages to the queue or topic directly	Producers send messages to the exchange, then the message is relayed to a queue or another exchange	Publishers send messages to the topic and the subscribers pull the messages from the partition
Data Types	Supports 5 message types: Message, TextMessage, BytesMessage, ObjectMessage, StreamMessage, MapMessage	Supports the binary data type	Uses key-value pairs
Payload Size	The maximum message size is 1280 MB	Limited to 128 MB	Limited to 1 MB
Storage	Provides in-memory or disk-based storage	Stores messages in the node’s data directory	Messages are stored in the node’s filesystem
Message Retention	Acknowledgment based – once the message is read it’s permanently deleted	Acknowledgment based	Policy-based – messages are stored for a defined amount of time regardless of whether they are received by the consumers or not
Order of Messages	Uses a FIFO approach where the order of messages received is not guaranteed; timing-dependent	FIFO approach; messages are consumed in the exactly the same order that they were delivered	Brokers determine which message to read first. There is a guaranteed order and the ability to replay the message stream
Performance	Performance of the queue and topic degrades with the inclusion of additional consumers	Performance of the queue and topic degrades with the inclusion of additional consumers	Does not allow down with the addition of new consumers
Scalability and Availability	You cannot scale horizontally and there is no replication	Less scalable and moderate availability	Highly scalable due to replication of partitions. You can auto-replicate messages without compromising the simplicity of the system by adding new nodes to the cluster to scale horizontally
Filter Method	You can use message selectors to set desired filters	You can use message selectors to set the desired filters	There is no filtering mechanism to ensure that messages are picked up by consumers that match a certain criteria
Delivery Guarantees	Exactly once message delivery guarantee	Exactly once delivery guarantee	At least once delivery guarantee although you can use the Kafka Streams API to create subscriptions with exactly-once delivery
Programming Style	Imperative	Imperative	Reactive

Bottom Line: Which One Is Better?

Fundamentally, Java Message Queue and RabbitMQ are both broker-centric. They’re mainly concerned with delivery guarantees between producers and consumers. Therefore, short-lived messages are preferred over durable messages. On the other hand, Kafka has a producer-centric approach, based around distributing messages into durable partitions with cursors.

Use Java Message Queue or RabbitMQ if any of the following use cases apply to your application:

• Data consistency guarantees for each message.
• Complex routing to consumers.
• Support for both pub/sub and point-to-point request/reply messaging capabilities.
• Support legacy protocols, like AMQP and MQTT.

And you should use Kafka if your application has any of the following requirements:

• Event sourcing-based business logic.
• Stream Processing Pipelines.
• Stream history replay using an archive.
• Streams with very high throughput.

Discover the key features and use cases of JMS queue to optimize your messaging infrastructure.

Conclusion

In the end, using a broker-centric or producer-centric approach to stream messages between your applications depends on your business requirements. Java Messaging Queues provide message-oriented middleware (MOM) systems to eliminate the requirement for the simultaneous presence of client and server. It simplifies the development of business applications that asynchronously send and receive business data and events. This article demonstrated the main components at work, the many forms of Java Message Queue, and the benefits and drawbacks of utilizing Java Message Queue.

When it comes to syncing data from your commonly used applications, companies often find themselves in a quandary: buy an ETL solution or build one in-house? Fortunately, using the Hevo Data ETL Platform, you can set up and run a pipeline effortlessly in minutes with just a few clicks. Hevo dramatically cuts deployment time from months to minutes. Set it up once, and Hevo will automatically manage all of your pipeline activities and future updates.

Why not try Hevo and see the magic for yourself? Sign Up here for a 14-day free trial and experience the feature-rich Hevo suite firsthand. You can also check out our unbeatable Hevo pricing and make a decision on your best-suited plan.

Have any questions or opinions on Java Message Queues? Do let us know in the comment section below. 

Frequently Asked Questions