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.

Answer 2

In Java EE there are basically 3 mechanisms for dealing with asynchronicity:

1. JMS
2. The CDI event bus
3. @Asynchronous annotated methods of stateless session beans

ewernli already gives a very good explanation of what advantages JMS has. It's a very fully featured system, but all these features do cost a little in overhead and in complexity of e.g. managing the administrative objects involved.

In addition the JMS spec hasn't been updated for nearly a decade. It still being really useful shows the great deal of foresight that went into the design of the API, but at times it can feel a little arcane. The way in which administrative objects like destinations have to be defined, the way that you need to obtain a connection, create a session, etc, it all feels a little low-level, old and arcane. Receiving messages though has been greatly simplified with message driven beans, but sending has not.

Then, for some legacy bizarre reason, web modules are forbidden to listen to JMS destinations. Of course there is no rationale for that anymore, but it's in the ancient J2EE 1.3 and later specs. Compliant application servers still uphold this rule, but they all provide vendor specific configuration to allow it anyway. This however makes your application less portable.

A subset of the use cases for which JMS was historically used is very simple event based programming within a single application. For that the CDI event bus is arguable better suited now, as it's a simpler, more modern and an overall more lighter weight approach.

Another subset of use cases for which JMS was used is simply doing any work asynchronously. For that people sometimes used to make an MDB which would then just unwrap the parameters from the message and call some stateless session bean's method directly passing in those parameters. In this case the messaging paradigm is absolutely not needed and just calling an @Asynchronous annotated method is a simpler and more direct approach.