O'Reilly - Java Message Service

Java Message Service
A message basically has two parts: a header and payload. The header is comprised of
special fields that are used to identify the message, declare attributes of the message, and
provide information for routing. The difference between message types is determined
largely by their payload, i.e., the type of application data the message contains. The
Message class, which is the superclass of all message objects, has no payload. It is a
lightweight message that delivers no payload but can serve as a simple event notification.
The other message types have special payloads that determine their type and use:
Message
This type has no payload. It is useful for simple event notification.
TextMessage
This type carries a java.lang.String as its payload. It is useful for exchanging
simple text messages and also for more complex character data, such as XML
documents.
ObjectMessage
This type carries a serializable Java object as its payload. It's useful for exchanging
Java objects.
BytesMessage
This type carries an array of primitive bytes as its payload. It's useful for exchanging
data in an application's native format, which may not be compatible with other
existing Message types. It is also useful where JMS is used purely as a transport
between two systems, and the message payload is opaque to the JMS client.
StreamMessage
This type carries a stream of primitive Java types (int, double, char, etc.) as its
payload. It provides a set of convenience methods for mapping a formatted stream of
bytes to Java primitives. It's an easy programming model when exchanging primitive
application data in a fixed order.
MapMessage
This type carries a set of name-value pairs as its payload. The payload is similar to a
java.util.Properties object, except the values must be Java primitives or their
wrappers. The MapMessage is useful for delivering keyed data.
2.1.3 Sessions and Threading
The Chat application uses a separate session for the publisher and subscriber, pubSession
and subSession, respectively. This is due to a threading restriction imposed by JMS.
According to the JMS specification, a session may not be operated on by more than one
thread at a time. In our example, two threads of control are active: the default main thread
of the Chat application and the thread that invokes the onMessage( ) handler. The thread
that invokes the onMessage( ) handler is owned by the JMS provider. Since the invocation
of the onMessage( ) handler is asynchronous, it could be called while the main thread is
31