What is ActiveMQ used for?

Question

I looked it up and you send messages to it. But why? Why wouldnt you use a database? There must be feature ActiveMQ has that databases dont?

Answer 1

ActiveMQ, or in generall all Message Oriented Middleware (MOM) implementations are designed for the purpose of sending messages between two applications, or two components inside one application.

Essentially, MOM and databases share a common foundation in that they provide transactional and persistent data storage to can read and write from. The big difference is the usage pattern - where databases are very generic and optimized for complex searching over multiple tables, MOM are optimized for reading messages, one at a time, in a FIFO like fashion.

JMS, which is an API ActiveMQ implements, is an important corner stone in Java Enterprise applications. This makes messages share a rather common format and semantic, which makes integration between different application easier.

Of course, there are a lot of more detailed features that are only in ActiveMQ, wire protocols like OpenWire,STOMP and MQTT, JMS, EIP together with Apache Camel, message patterns like "request/reply" and "publish/subscribe", JMS Bridging, clustering ("network of brokers"), which allow scaling and distributions etc. You should read up on those topics a bit, if you are interested since they are rather large.

Answer 2

From Wikipedia

Apache ActiveMQ is an open source message broker written in Java together with a full Java Message Service (JMS) client. It provides "Enterprise Features" which in this case means fostering the communication from more than one client or server

Regarding your queries:

Why wouldnt you use a database?

You should use database for persistent data and not for temporary data. Assume that you have to send a message from Sender to Receiver. On Receiving the message, Receiver execute one operation ( receive , process and forget). After processing that message, you don't need that message at all. In this case, storing the message in persistent database is not a right solution.

I fully agree with @Hiram Chirino answer regarding inserting & deleting message in database if you use database instead of messaging system.

Benefits from this article and this article

1. Enterprise integration : Allowing applications built with different languages and on different operating systems to integrate with each other
2. Location transparency : Client applications don’t need to know where the service applications are located
3. Reliable communication – the producers/consumers of messages don’t have to be available at the same time
4. Scaling – can scale horizontally by adding more services
5. Asynchronous communication – a client can fire a message and continue other processing instead of blocking until the service has sent a response;
6. Reduced coupling – the assumptions made by the clients and services are greatly reduced as a result of the previous 5 benefits. A service can change details about itself, including its location, protocol, and availability, without affecting or disrupting the client.

There must be feature ActiveMQ has that databases dont?

There are many. Have a look at documentation page for more details. Have a look at use-cases too.

Have a look at this presentation to understand internals of ActiveMQ.

Answer 3

With RDBMS, when you process a row of data, you typically update a flag indicating that the row has been processed so that the processing is not repeated.

However, with Message Queue, you only have to acknowlege a message and the next consumer will process the next one.

The difference is the UPDATE statment in a RDBMS is a really slow operation compared to the acknowlege in activmeq.

Answer 4

Active MQ has great scheduler support, that means you can schedule your message to be delivered at a particular time. We have used this feature to send medication reminders to patient uploading their medication details in a health care scenario.

Answer 5

i would like to emphasize the following:

Decoupled : The systems are able to communicate without being connected. Queue lies between systems, one system failure will never affect other as communication is done through Queue. The systems continue to work when they are up.

Recovery support : The messages in Queues itself persisted. The messages can be restored later if Queue fails.

Reliable Communication : Consider a system that process client requests. In normal cases the system receives 100 requests per minute. This system is unreliable when number of request goes beyond average. In such case Queue can manage requests and it can push messages periodically based on system throughput without breaking it.

Asynchronous : Client server communication is non-blocking. Once client sent request to server it can do other operations without waiting for response. When response it received client can handle it anytime.

Answer 6

It is used to reliably communicate between two distributed processes. Yes, you could store messages in a database to communicate between two processes, but, as soon as the message is received you'd have to delete the message. That means a row insert and delete for each message. When you try to scale that up communicating thousands of messages per second, databases tend to fall over.

Message oriented middle-ware like ActiveMQ on the other hand are build to handle those use cases. They assume that messages in a healthy system will be deleted very quickly and can do optimizations to avoid the overhead. It can also push messages to consumers instead of a consumer having to poll for new message by doing a SQL query. This further reduces the latency involved in processing new messages being sent into the system.