Use cases of ActiveMQ

Introduction

ActiveMQ is a form of Message Oriented Middleware (MoM), which offers message-oriented application integration across various languages, including C#, Java, Python, Ruby, etc. In this article, we are going to discuss use-case-based scenarios to demonstrate how ActiveMQ can be used.

As an MoM, ActiveMQ solves a range of problems faced while developing applications. It can be surprising to know, but wherever message communication is involved in the architecture of a software application, ActiveMQ can be used there irrespective of its programming language.  

Types of Messaging Styles

There are two styles of messaging supported by ActiveMQ:

1. Point to Point: in the Point to Point messaging style, we can send messages in any order using Queues. The producer’s message is sent to the consumer using the queue. Each message delivered to the queue is delivered only once to a single consumer.

2. Publish/Subscribe: in the Publish/Subscribe messaging style, we call our producers “publishers” and consumers “subscribers.” Here, we use Topics to shepherd messages between producers and consumers. To receive messages, consumers need to subscribe to the topic. Once our consumers are registered to the topic, every time the producer sends a message, all consumers receive it.

Use cases of Point to Point Messaging Style

Case 1

Let’s imagine we have two applications: App A and App B. App A is a legacy application developed using Java and EJB. App B is developed using Python and Django. 

Here both the applications are developed using different languages and no common endpoints to communicate among themselves. However, the client requires a design change to establish a message communication system between the applications.

Flowchart displaying Case 1’s process

According to the new change, you have to process a particular request in App A and then send the processed request to App B for further processing. After this, the data would need to be stored in a database.

But the problem here remains that there are no common endpoints for App A and App B. To solve this problem, we can use ActiveMQ and a message queue. After App A processes a request, it can send the processed request to the message queue. The same processed request can be used by App B for further processing and then database storage.

Case 2

A classic example of point to point messaging would be an order queue in an e-commerce website’s product ordering system. Each order is sent to the order queue as a new product order. 

Flowchart displaying Case 2’s process

Imagine we have multiple devices using an app, with various user or end systems making orders on our e-commerce websites. Suppose we have a sale, and due to excessive requests, the server crashes. This causes all of the orders made during that time to be lost. 

A situation like this can be a huge issue and can hamper the reputation of your e-commerce site. In this case, we can use a message queue to store all the purchase orders and process them later. This will ensure that no purchases made during your server crash are lost. We develop this using ActiveMQ. 

Use cases of Publish/Subscribe

Case 1

Imagine having a digital channel application with a lot of subscribers. Your business requirement is to send a notification to all of your subscribers every time you upload a new video to your channel, as this would help boost your video’s view count. 

Flowchart displaying Case 1’s process

To fulfill this requirement, we can use ActiveMQ’s Topics feature. We can have the channel as our “producer” and the subscribers as “consumers.” Every time a new video is uploaded, our application sends a message to the ActiveMQ Topic, directing it to send a copy of the message to all our subscribers, who are the “consumers” in our message broker. 

Case 2

Let’s imagine we have a web application that stores appointment details and all other necessary information of all patients at a hospital. The application was built using old and outdated technology. Recently, we created a mobile application for your patients to view their reports and check their doctors’ availability. 

Flowchart displaying Case 2’s process

Now, you want to send notifications to your users whenever a new doctor joins your organization, as well as whenever you open a new department. These notifications need to be sent to both, the users of the Web application and the mobile application. 

To do this, we can again use ActiveMQ Topics. The admin of our web application will send a message about the required notification to the Topic using the Admin Module. Through this, the clients using the web application and the mobile application will receive the notification without any backend fuss. The Admin Module acts as the “producer,” and the client applications act as “consumers.”

Conclusion

ActiveMQ and MoM can be used for many cases as messaging solutions come in handy to solve many problems. Whether you have a problem establishing communication between heterogeneous applications or replacing RPCs used as a communication medium in your existing distributed application, ActiveMQ can solve the problem. 

ActiveMQ also supports multiple messaging protocols like AMQP, Web Sockets, Stomp, OpenWire, and MQTT and is open-sourced, thus a viable alternative to other commercial MOMs. If you need enterprise-level support, however, there are several commercial companies out there that offer such services for open source software, including  HYTE, Total Transaction Management (TTM), or Yupiik.