Why JMS over Database?

Why JMS over Database?
 

1)      If there is no need to store the messages permanently then do NOT use a database.

2)      The main difference is a JMS message queue is a high performance highly concurrent load balancer designed for huge throughput; you can send usually tens of thousands of messages per second too many concurrent consumers in many processes and threads.

3)      One could say that just enable row level locking and grab next row using database for this instead of using JMS (a new abstraction layer). The reason database overkill is that this gets stored on hardware, so in case of a power failure your messages will be there with tx guarantee. This is overkill for a simple pipe operation.

4)      If you are looking for Asynchronous communications, Reliability and Loose coupling:

a)      Asynchronous communications : An application need to notify another that an event has occurred with no need to wait for a response.

b)      Reliability: Ensure once-and-only-once message delivery. With your DB approach you have to "reinvent the wheel", specially if you have several clients reading the messages.

c)       Loose coupling: Not all systems can communicate using a database. So JMS is pretty good to be used in heterogeneous environments with decoupled systems that can communicate over system boundaries.

5)      The JMS implementation is "push", in the sense that you don't have to poll the queue to discover new messages, but you register a callback that gets called as soon as a new message arrives.

6)      You don't need to write the code yourself (and possibly screw up the logic so that it's not quite as persistent as you think it is). also, third-party impl might be more scalable than simple database approach.

7)      You are not tied to a specific implementation, and can swap it out if your needs change in the future, w/out messing w/ your java code.

8)      The consumer of the message can be in a remote location. Exposing database for remote access is dangerous. You can workaround this by providing additional service for reading messages from database, that requires more effort.

9)      In general implementation via JMS will be simpler and take less effort than database route.