Kandy Software, Inc. » onMessage() http://www.kandysoftwareinc.com Thu, 20 Jan 2011 04:03:54 +0000 en hourly 1 http://wordpress.org/?v=3.1.3 JMS Internals http://www.kandysoftwareinc.com/tech-articles/jms-internals http://www.kandysoftwareinc.com/tech-articles/jms-internals#comments Thu, 14 Feb 2008 02:35:26 +0000 admin http://www.kandysoftwareinc.com/?p=101 [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:
    1. Connection Factory: Client uses this object to create a connection with a provider.
    2. 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.

  1. NON_PERSISTENT mode

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

  2. PERSISTENT mode

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

  1. StreamMessage This message is composed of Java primitive values. It is written and read sequentially
  2. MapMessage This message contains a set of key-value pairs where keys are Strings and values are Java primitive types
  3. 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.
  4. ObjectMessage This message allows for transfer of a Serializable Java object.
  5. 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.

]]> http://www.kandysoftwareinc.com/tech-articles/jms-internals/feed 0