Clarification re: JMS/Messaging

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.
TIA.
rt.

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

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.

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 - http://www.ftponline.com/javapro/2002_03/magazine/features/kjones/default.aspx.
Cheers,
rt.
[Andrew: Moved full stop outside of URL]
[ March 30, 2004: Message edited by: Andrew Monkhouse ]
[ March 30, 2004: Message edited by: Andrew Monkhouse ]

HI Richard
The URL should be read without "." at the end.
JMS