The JMS model

JMS defines a generic view of a message passing service. It is important to understand this view, and how it maps onto the underlying WebSphere MQ transport.

The generic JMS model is based around the following interfaces that are defined in Sun's javax.jms package:

Connection: Provides access to the underlying transport, and is used to create Sessions.
Session: Provides a context for producing and consuming messages, including the methods used to create MessageProducers and MessageConsumers.
MessageProducer: Used to send messages.
MessageConsumer: Used to receive messages.

Note that a Connection is thread safe, but Sessions, MessageProducers, and MessageConsumers are not. The recommended strategy is to use one Session per application thread.

In WebSphere MQ terms:

Connection: Provides a scope for temporary queues. Also, it provides a place to hold the parameters that control how to connect to WebSphere MQ. Examples of these parameters are the name of the queue manager, and the name of the remote host if you use the WebSphere MQ Java client connectivity.
Session: Contains an HCONN and therefore defines a transactional scope.
MessageProducer and MessageConsumer: Contain an HOBJ that defines a particular queue for writing to, or reading from.

Note that normal WebSphere MQ rules apply:

Only a single operation can be in progress per HCONN at any given time. Therefore, the MessageProducers or MessageConsumers associated with a Session cannot be called concurrently. This is consistent with the JMS restriction of a single thread per Session.
PUTs can use remote queues, but GETs can only be applied to queues on the local queue manager.

The generic JMS interfaces are subclassed into more specific versions for "Point-to-Point" and "Publish/Subscribe" behavior.

The point-to-point versions are:

QueueConnection
QueueSession
QueueSender
QueueReceiver

A key idea in JMS is that it is possible, and strongly recommended, to write application programs that use only references to the interfaces in javax.jms. All vendor-specific information is encapsulated in implementations of:

QueueConnectionFactory
TopicConnectionFactory
Queue
Topic

These are known as "administered objects", that is, objects that can be built using a vendor-supplied administration tool and can be stored in a JNDI namespace. A JMS application can retrieve these objects from the namespace and use them without needing to know which vendor provided the implementation.