JMS Internals
[print_link]
Introduction
This article discusses JMS architecture and various components within a JMS system. Message models and messaging styles are explained. The article also discuses synchronous and asynchronous message consumption.
JMS Architecture
JMS (as defined in JMS specification version 1.1) is a set of interfaces and associated semantics that provides a common way for Java programs to create, send, receive and read an enterprise messaging system’s messages. In this context messages are asynchronous requests, reports or events that are consumed by enterprise applications, not humans. They contain precisely formatted data that describe specific business actions.
A JMS application is composed of the following parts:
- JMS Clients: These are Java programs that send and receive messages. For example, Message Driven Beans.
- Messages: The information transferred between the clients.
- JMS Provider: The messaging system that implements JMS specification. JBossMQ is an example.
- Administered Objects: These are pre-configured JMS objects used by the clients. There are two types of administered objects:
- Connection Factory: Client uses this object to create a connection with a provider.
- Destination: Client uses this object to specify the destination of messages it is sending or the source of messages it receives.
Message Model
Messages are lightweight entities that consist of a header and a body. The header contains fields used for message routing and identification. The body is the payload which clients exchange.
| Header used in JBossMQ |
Header { jmsDestination : QUEUE.KSIDemoQueue jmsDeliveryMode : 2 jmsExpiration : 0 jmsPriority : 4 jmsMessageID : ID:29-12015475384804 jmsTimeStamp : 1201547538480 jmsCorrelationID: null jmsReplyTo : null jmsType : null jmsRedelivered : true jmsProperties : {JMS_JBOSS_REDELIVERY_COUNT=2} jmsPropReadWrite: false msgReadOnly : true producerClientId: ID:29 } |
| Header used in WebSphere 5.1 |
JMSType: null JMSDeliveryMode: 2 JMSExpiration: 0 JMSPriority: 4 JMSMessageID: ID:414d5120445149434d5320202020202046f2d24b2001c001 JMSTimestamp: 1201106363820 JMSCorrelationID:null JMSDestination: queue:///QUEUE.KSIDemoQueue JMSReplyTo: null JMSRedelivered: false JMS_IBM_PutDate: 20080123 JMSXAppID: Websphere MQ Client for Java JMS_IBM_Format: MQSTR JMS_IBM_PutApplType:28 JMS_IBM_MsgType: 8 JMSXUserID: mqm JMS_IBM_PutTime: 16392943 JMSXDeliveryCount:1 |
Header fields are discussed below.
Header field |
Description | Set by |
JMSDestination |
This field contains the destination to where the message is being sent. | Send Method |
JMSDeliveryMode |
JMS supports two message delivery modes.
In this mode, the JMS container does not persist the message. A JMS provider failure can cause a NON_PERSISTENT message to be lost. A JMS provider will deliver these types of messages at most once. The provider may lose the message but it must not deliver it twice. In this mode, the JMS container insures that a message will be delivered to the client. A failure within JMS container will not cause the message to be lost. In this mode the messages will be delivered once and only once. |
Send Method |
JMSMessageID |
Each message in a JMS container is assigned a unique ID. This field is used to identify a specific message. All IDs begin with ID:. | Send Method |
JMSTimestamp |
This field contains the time a message was handed off to a provider to be sent. It is in the format of a normal Java millis time value. | Send Method |
JMSCorrelationID |
This field can use to link one message with another. As an example, a response message can be linked with a request message by populating this field with request message’s JMSMessageID. ID can be a provider specific message ID or spplication specific string or an array of bytes (byte[]).
|
Client |
JMSReplyTo |
The client populates this field to denote where a reply message has to be sent.Messages sent with a JMSReplyTo value are typically expecting a response although a response is not madatory. | Client |
JMSRedelivered |
If the field is set to true, it is an indication to the consuming application that the message may have been delivered in the past and that the application should take extra precautions to prevent duplicate processing. | Provider |
JMSType |
Clients can classify messages and set this field to denote that this message belongs to a specific category. For e.g., a call center system can label messages as ‘Tech Support’ or ‘Sales’ etc. This field can be used with selectors described later. | Client |
JMSExpiration |
This denotes the expiration time of a message. The expiration time is calculated as sum of this value and the current GMT value. Expired messages are destroyed. If this is set to 0, the message never expires. | Send Method |
JMSPriority |
JMS defines ten priority levels. Levels 0-4 are considered normal and levels 5-9 are expedited. Generally high priority messages are delivered ahead of lower priority messages but this behavior is vendor specific. | Send Method |
In addition to these properties, a client can set and get additional properties via setXXXProperty() and getXXXProperty() methods. JMS reserves JMSX property name prefix for JMS defined properties. Most of these JMSX properties are dependant on a JMS provider.
JMS provides five forms of message body. All messages extend Message interface.
- StreamMessage This message is composed of Java primitive values. It is written and read sequentially
- MapMessage This message contains a set of key-value pairs where keys are Strings and values are Java primitive types
- TextMessage This is the commonly used message form. This message body contains a java.lang.String. For e.g., clients and exchange XML data using this type.
- ObjectMessage This message allows for transfer of a Serializable Java object.
- BytesMessage This message is composed of bytes.
The difference between StreamMessage and BytesMessage is that StreamMessage preserves the type information of Java primitive types whereas BytesMessage does not.
Pages: 1 2
Leave your response!