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.

Table of Contents

• Background
• What Is Java Message Queue?
• Java Message Queue Core Components
• Java Message Queue Messaging Models
  • Point-to-Point (PTP) Messaging Model
  • Publisher/Subscriber (Pub/Sub) Messaging Model
• What Is Java Message Queue Used For?
• Advantages and Disadvantages of Using Java Message Queue
• When to Use Java Message Queue?
• How Does Java Message Queue Stack Up Against Kafka & RabbitMQ?
  • Comparison Chart: Java Message Queue vs Kafka vs RabbitMQ
• Bottom Line: Which One Is Better?
• Conclusion

Background

Most of us have at some point had to use the services of a broker when executing transactions. They act as the intermediary between the buyer and the seller. Whether it is buying shares from a securities exchange, buying real estate, or even purchasing a car, in everyday transactions brokers are prevalent across many business domains.

The broker’s main role is to make it easier for a transaction to occur. They can represent the buyer or the seller, but not both at the same time. For instance, a mortgage broker helps match borrowers to financial institutions offering the most affordable loans based on the borrower’s financial situation and interest-rate needs.

The broker concept is also applicable when integrating enterprise application systems that are made up of many heterogeneous software components that need to exchange information such as transactions and notification events. The broker in this case is used to implement or facilitate the round-the-clock messaging of data between the consumers and the producers.

The Message Broker achieves this by using a Message Queue to provide a persistent mechanism. A queue of messages is placed between two parts of the system in order for them to communicate with each other. The message is the data transported between the sender and the receiver. For example, one part of the system tells another part to start processing a task.

The architectural pattern of Message Brokers is often used in between microservices and/or for long-running tasks. The basic architecture is simple, producers create messages and deliver them to the Message Queue. Consumers connect to the Message Queue and subscribe to messages from the queue. Messages placed on the queue are stored until the consumer acknowledges them (i.e. consumer tells the message broker that the message has been received and handled).

In a nutshell, this way of handling messages:

• Facilitates asynchronous communication between applications.

• Minimizes the mutual awareness between the microservices.

• Decouples/detaches the sender from the receiver of a message.

• Creates a system that is easy to maintain and scale.

• Allows for different parts of an application to evolve independently and be written in different languages.

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

Advantages

• High Throughput: Since the Java Message Queue follows an asynchronous messaging pattern, you can expect better performance because the clients that are producing and consuming messages interact with the queue, and not each other. No clients will stall because they aren’t waiting for the completion of message consumption.

• Robust and Reliable: Messaging using the Java Message Queue is reliable as it ensures that a message is delivered to the intended consumer once-and-only-once. When duplicates can’t be tolerated, there are mechanisms in place to filter out duplicates.

• Fault Tolerance: The Java Message Queue can mitigate the errors that occur when some of the components in an application are unreachable since the messages are persisted in a staging area. Therefore, when the components recover and get back online, Java Message Queue can pick up from where it left without affecting other components.

• Break Up Apps: You can use it to decouple monolithic applications into small, self-contained applications. Instead of executing multiple functions within a single executable, you can have many programs that each perform a discrete function. This makes the system easier to test, debug, evolve and scale.

Disadvantages

• The Java Message Queue is Java-based, and this means that it can only be used to implement Messaging systems in Java-compliant applications only – it does not support other languages. In distributed N-tier applications that use multiple languages and frameworks, this can become an impediment.

• Java Message Queue has no specific message format which is a limitation.

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.

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 of 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 in minutes effortlessly in 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. 

Hevo has over 150+ Data Sources (40+ free Data Sources) from which you can migrate your data to a wide range of Desired Destinations: Data Warehouses or Databases like Google BigQuery, Amazon Redshift, Snowflake, Firebolt, PostgreSQL, or MySQL. Hevo features in-built data formatting and transformation capabilities to automatically prepare your data for analytics in minutes.

Visit our Website to Explore Hevo

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 first hand. You can also check 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.