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:
- 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
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:
- QueueConnectionFactory
- TopicConnectionFactory
- Queue
- Topic
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.