The JMS model

JMS defines a generic view of a message passing service. 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.

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(R) 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(TM) 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:

The generic JMS interfaces are subclassed into more specific versions for point-to-point and publish/subscribe behavior.

The point-to-point versions are:

When using JMS, always write application programs that use only references to the interfaces in javax.jms. All vendor-specific information is encapsulated in implementations of:

These are known as administered objects, that is, objects that can be built using a vendor-supplied administration tool and 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.