File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes Clarification re: JMS/Messaging Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "Clarification re: JMS/Messaging" Watch "Clarification re: JMS/Messaging" New topic

Clarification re: JMS/Messaging

Richard Tandoh

Joined: Mar 26, 2004
Posts: 8
Hi All
I'm a bit unclear re: JMS/Messaging and was wondering if someone
could help me out.
According to Richard Monson-Haefel's JMS book, p2p messaging supports
both synchronous and asynchronous messaging. Is this the same for
pub/sub or is pub/sub inherently asynchronous?
Also, in the same book, a number of references are made to the fact
that p2p offers 'guaranteed delivery' - the implication being,
whereas pub/sub doesn't. If this is the case, why are durable
clients only available in the pub/sub domain?
Finally, in Paul Allen (Chapter 8), he recommends using synchronous
messaging to provide a credit card authorization facility. Is this
an appropriate use of messaging? IMHO this a scenario where a RPC
would be better.
Dani Mazzuca
Ranch Hand

Joined: May 21, 2003
Posts: 70
Hi Richard,
I didn't read the book. However:
1) All JMS messages are async, i.e., the sender sends the messages and doesn't block for the answer. What they call "sync" and "async" is the way you receive the messages. You can receive them using "receive" (sync) or you can use "listeners" (async). You can use both, sync and async receiving for both, queue and topic. As far as queue and topic, the differences are that in queue, you are able to have almost one receiver. Also you can send the message to the queue, and after that, read them, without having the receiver to be connected at the time the messages arrived. Topic can have multiple receivers of the same message, however, they must be connected at the time the messages arrive. With a topic-durable option, you can have a Topic, that relax this last condition, in that, the receiver can register to the topic, but after that, it can quit, and can read the messages in a later connection (provided it will use the same ID and subscription name)
2) I think that if you are using a Topic (not durable), and at the moment the message is delivered, the client is not "online", you loose the message. To avoid this, you use durable topics, or queues.
Dani Mazzuca
D. Rose
Ranch Hand

Joined: Apr 25, 2003
Posts: 215
Hi Dani - Nice explanation!
Hi Richard,
I think advantage of synchronous messaging for credit card processing is that connecting disparate ( credit card application may be running on different platform/environment) systems via messgaing allows loose coupling of systems. RPC gives rise to tight coupling between systems.
Richard Tandoh

Joined: Mar 26, 2004
Posts: 8
Thanks for the help guys; much appreciated.
I'm much happier about JMS-related concepts now.
For the benefit of others, I also found this very lucid article over the weekend -
[Andrew: Moved full stop outside of URL]
[ March 30, 2004: Message edited by: Andrew Monkhouse ]
[ March 30, 2004: Message edited by: Andrew Monkhouse ]
Sujatha Kumar
Ranch Hand

Joined: Jan 05, 2004
Posts: 134
HI Richard
The URL should be read without "." at the end.

I agree. Here's the link:
subject: Clarification re: JMS/Messaging
It's not a secret anymore!