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

Question

Hi everybody,

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.

Answer 2

So you decided to hammer together a database based message queue on your own instead of using an existing messaging system. Sure it will work, but I would ask why you even bothered with an entity bean, you have no state to maintain, or updates to make to the table, so you could just make db calls directly from a servlet (if web based) or a stateless session bean. All of which are still poor substitutes for an actual messaging system.

I realize that I didn't actually answer the question, but I thought I would point out that the existing solution seemed to be a case of, I have a hammer and now every problem looks like a nail.