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 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
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.
uj24330_