What is common and useful uses of JMS and Message Driven Beans?
+5
A:
Asynchronous communication: The caller returns quickly, and can continue its work (without creating a new thread) and the message can be processed later. Messages can be stored, and even when the server fails, they can continue to be processed, once the server starts up again. Messages can be distributed to multiple machines (optionally based on rules).
Callers and callees can be decoupled (the caller doesn't have to know, who will consume the message, and how many message consumers there are).
It can have enormous performance advantages compared to synchronous communication. Such a messaging middleware can be crucial for services that have to handle lots of messages per second (think of Twitter for example). But it's not restricted to human readable messages.
Chris Lercher
2010-03-13 17:25:13
Very good answer! +1
Pindatjuh
2010-03-13 17:27:19
Do you think uses of JMS and MDB is bulky? or this is only my opinion.
den bardadym
2010-03-13 17:34:53
It really depends on what you want/need to do. Bulkiness of usage may be a small factor compared to the functional differences anyway. JMS (with or without MDBs) should certainly not be the default choice to use for everything. It all depends on whether you need the functionality or not. BTW, e.g. HornetQ provides an alternative API, that is somewhat less "bulky".
Chris Lercher
2010-03-13 17:42:05
Very interesting. I dont know that exist others ways to use MBD without JMS.
den bardadym
2010-03-13 18:10:03
+3
A:
Another reason to choose JMS and MDBs is guaranteed delivery. A synchronous, point to point call fails if the receiver is unavailable, but a queue can be set up to guarantee delivery, handle retries or transactional failures, use error queues for messages that are "poison", etc.
There are two transmission models built into JMS: point-to-point using queues and publish/subscribe using topics. Each has its own advantages.
The downside of JMS and MDBs is speed of response. You might like the decoupling, but if you block and wait for a response it'll certainly be slower than a direct remote method invocation, because there are two network trips involved instead of just one.
duffymo
2010-03-13 17:30:38