12

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!

ajeanson
  • 2,580
  • 4
  • 19
  • 17
  • Because sometimes people don't want to use EJB – matt b Jan 19 '10 at 21:57
  • 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. – Robin Jan 19 '10 at 20:22

2 Answers2

13

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.

ewernli
  • 38,045
  • 5
  • 92
  • 123
  • Thanks for your reponse. I agree with you about having to reinvent the wheel with an entity bean and having to manage locking pattern in a multithread environnement. Ok, let's read the FAQ ! – ajeanson Jan 19 '10 at 20:47
  • Note that I am not saying that JMS is *the* solution neither. Using JMS can complexity some aspect of the solution (e.g. dealing with distributed transactions, configuring the queues, managing messaging errors, etc.). If you have *one* consumer per queue and the *non-functional* issues are not a concern, then one table and a thread may well do the job. I've seen both approach and both worked. – ewernli Jan 19 '10 at 21:32
8

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.

Arjan Tijms
  • 37,782
  • 12
  • 108
  • 140
  • The CDI Event Bus is not asynchronous. – Luke Dec 19 '13 at 19:44
  • @Luke you're right. My answer as stated is not correct. What I meant to say is that the CDI event bus is a simple replacement for JMS for those cases where it's used for eventing (which are indeed not asynchronous) and that `@Asynchronous` is for those cases where just some asynchronous behavior is needed. Let's see how to best update it ;) – Arjan Tijms Dec 20 '13 at 23:28
  • @Luke by that time CDI 2.0 introduced asynchronous events – irieill Jun 30 '23 at 05:00