What is ActiveMQ used for - can we apply messaging concept using a Database?

Question

I looked it up and it used to send messages between 2 systems.
But why? Why wouldn\'t you just use a Database?
There must be some feature that ActiveM

Answer 1

ActiveMQ, or in general 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 is optimized for reading messages, one at a time, in a FIFO like fashion [Queue].

JMS, which is an API ActiveMQ implements, is an important cornerstone in Java Enterprise applications. This makes messages share a rather common format and semantic, which makes integration between different applications 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

Suppose you have an application which is being used at multiple locations at the same time. Also suppose your application has to handle 1000s of request per minute or something like that so normal db operations cannot handle such operations, Activemq acts as the message processing it takes all the messages into queue , so even if one of your application crashes at one location the other location won't be affected.

Answer 4

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 acknowledge a message and the next consumer will process the next one.

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

Answer 5

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 [MOM] like ActiveMQ on the other hand are built 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 the new message by doing a SQL query.
This further reduces the latency involved in processing new messages being sent into the system.

Answer 6

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.