Questions Regarding Messaging

Q1: Pub/Sub and P2P are messaging models. IBM MQSeries and MSMQ are some MOM vendor. JMS is a Java API to access those MOM products. Is Pub/Sub implemented differently by using MQSeries from by using MSMQ? What are the major differences?
Q2: Does network have to be available for MOM systems?
Q3: P2P is a MOM model. Asynchronous is one of the attributes of MOM. However, it says in Monson-Haefel's "Java Messaging Service" that P2P can send and receive messages both synchronouly and asychronouly. It gets me confused.
Please help.

True JMS confuses me all the time and I have to go back to refer the specs every now and then.
This is what I understand:
JMS is inherently asynchronous meaning there is no dependency between sending and receiving a message.
However the consumer can exhibit synchronous behavior like it can block untill it receives a message or asynchronous through the onMessage method.
The only way a sender can exhibit synchronous is using temporary destinations.
Hope this helps.
-MM(SCEA)

Ans-1
JMS is an API the concrete implementation is provided by the vendor e.g., MQSeries provides its implementation in two Jar files available as part of MA88 package. As JMS user you need not concern yourself with the concrete classes or in other words the vendor. [yes the factory need to be specified]
-----------------------------------------------
Ans-2
Some MOM products such as IBM MQseries requires you to install a server which may be on the same m/c or different m/c. Now n/w connectvity has to be there between the producer and the middleware server but its not neccesary that the consumer is up and connected to the middleware server. E.g., the consumer may be a travelling salesman's application. So what happens to the message. A message has an expiry if it is not consumed within that time it gets removed and is made unavailable. As and when the consumer connects to the middleware it can accept/get the message(s).
-----------------------------------------------
Ans-3
The synchronous messaging model/API allow you to recv messaged synchronously i.e., when you invoke a recv the calling thread gets into a blocked state. Using this you can write a thread that can poll a queue for messages.
What if the Vendor provided you with an already implemented polling mechanism ? Its there the asynchronous model wherein you register a message listener on a reciever and your listener is invoked as and when a message is recvd. The idea is that now you don't have to write your own polling mechanism and there are other benefits which is out-of-scope of this discussion