java - Why choosing JMS for asynchronous solution ? Why is it better than a simple entity bean?

Question

In most projects I have participated, the choice of an asynchronous solution has been a source of much discussion ...

Each time a single entity bean was enough to manage a queue: we just store a message (ticket) in a table and a processing cron unstacks the queue. This simple solution has the advantage of being very simple, it's based on the transactional context of the database and we can manage the state of the received message during its execution.

I therefore ask the following questions:

1) What interest we have to use JMS? What are the benefits of JMS ?

2) In which situation prefering JMS versus entity bean ?

Thank you for your responses and feedback!

Answer 1

1) What interest we have to use JMS? What are the benefits of JMS ? 2) In which situation prefering JMS versus entity bean ?

You approach works well as long as there is only one consumer. Otherwise it will require a locking scheme so that the same message is not delivered twice, etc. This is what JMS offers out of the box: transacted production and consumption with the JMS broker managing all the delivery issues with multiple consumers/producers.

Other advantages of JMS are quality of service and management, e.g. redelivery attempt, dead message queue, load management, scalability, clustering, monitoring, etc.

JMS also support publish-subsribe or point-to-point.

It's a bit like comparing a JDBC statement to insert one row in database vs. a full-fledge ORM. Both work to insert a row in the db, but the ORM will provide a lot more, plus you don't re-invent the wheel to deal with low-level issues... (the analogy is not that great but well)

I suggest you look at the FAQ.