A JMS message has three sections:
• Header (some header fields are required)
• Properties (optional)
• Body (optional)
Header Fields
The header contains ten predefined fields that contain values used to route and deliver messages.
Properties
TIBCO Enterprise Message Service includes several vendor-specific properties in this area. TIBCO-specific property names begin with JMS_TIBCO.
Message Bodies
A JMS message has one of several types of message bodies, or no message body at all.
Message Persistence
JMS defines two message delivery modes, persistent and non-persistent. This mode is set by the message sender or publisher in the JMSDeliveryMode message header field. Non-Persistent messages are never written to persistent storage.
Persistent messages are logged to persistent storage when they are sent.
Messages with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.
File Locking
Each EMS server writes persistent messages to a store file. To prevent two servers from using the same store file, each server restricts access to its store file for the duration of the server process.
On Windows platforms, servers use the standard Windows CreateFile function, supplying FILE_SHARE_READ as the dwShareMode (third parameter position) to restrict access to other servers.
Character Encoding in Messages
TIBCO Enterprise Message Service clients can specify a variety of common character encodings for strings in messages. The character encoding for a message applies to strings that appear in any of the following places within a message:
• property names and property values
• MapMessage field names and values
• data within the message body
The EMS client APIs (Java, .NET and C) include mechanisms for handling strings and specifying the character encoding used for all strings within a message.
Message Compression
TIBCO Enterprise Message Service allows the message body to be compressed by the client before the message is sent to the TIBCO Enterprise Message Service server.
Message compression is especially useful when messages will be stored on the server (persistent queue messages, or topics with durable subscribers). Setting compression ensures that messages will take less memory space in storage.
When messages are compressed and then stored, they are handled by the server in the compressed form. Compression assures that the messages will usually consume less space on disk and will be handled faster by the EMS server.
Setting Message Compression
To set message compression, the application that sends or publishes the message must access the message properties and set the boolean property JMS_TIBCO_COMPRESS to true before sending or publishing the message. For example:
message.setBooleanProperty("JMS_TIBCO_COMPRESS",true);
Compressed messages are handled transparently. The client code only sets the JMS_TIBCO_COMPRESS property. The client code does not need to take any other action.
Message Acknowledgement
The specification defines three levels of acknowledgement:
• DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
• AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a client’s receipt of a message.
• CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message’s acknowledge method.
• Header (some header fields are required)
• Properties (optional)
• Body (optional)
Header Fields
The header contains ten predefined fields that contain values used to route and deliver messages.
Properties
TIBCO Enterprise Message Service includes several vendor-specific properties in this area. TIBCO-specific property names begin with JMS_TIBCO.
Message Bodies
A JMS message has one of several types of message bodies, or no message body at all.
Message Persistence
JMS defines two message delivery modes, persistent and non-persistent. This mode is set by the message sender or publisher in the JMSDeliveryMode message header field. Non-Persistent messages are never written to persistent storage.
Persistent messages are logged to persistent storage when they are sent.
Messages with the persistent delivery mode are always written to persistent storage, except when they are published to a topic that has no durable subscribers. When a topic has no durable subscribers, there are no subscribers that need messages resent in the event of a server failure. Therefore, messages do not need to be saved, and performance is improved because disk I/O is not required.
File Locking
Each EMS server writes persistent messages to a store file. To prevent two servers from using the same store file, each server restricts access to its store file for the duration of the server process.
On Windows platforms, servers use the standard Windows CreateFile function, supplying FILE_SHARE_READ as the dwShareMode (third parameter position) to restrict access to other servers.
Character Encoding in Messages
TIBCO Enterprise Message Service clients can specify a variety of common character encodings for strings in messages. The character encoding for a message applies to strings that appear in any of the following places within a message:
• property names and property values
• MapMessage field names and values
• data within the message body
The EMS client APIs (Java, .NET and C) include mechanisms for handling strings and specifying the character encoding used for all strings within a message.
Message Compression
TIBCO Enterprise Message Service allows the message body to be compressed by the client before the message is sent to the TIBCO Enterprise Message Service server.
Message compression is especially useful when messages will be stored on the server (persistent queue messages, or topics with durable subscribers). Setting compression ensures that messages will take less memory space in storage.
When messages are compressed and then stored, they are handled by the server in the compressed form. Compression assures that the messages will usually consume less space on disk and will be handled faster by the EMS server.
Setting Message Compression
To set message compression, the application that sends or publishes the message must access the message properties and set the boolean property JMS_TIBCO_COMPRESS to true before sending or publishing the message. For example:
message.setBooleanProperty("JMS_TIBCO_COMPRESS",true);
Compressed messages are handled transparently. The client code only sets the JMS_TIBCO_COMPRESS property. The client code does not need to take any other action.
Message Acknowledgement
The specification defines three levels of acknowledgement:
• DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate messages.
• AUTO_ACKNOWLEDGE, in which the session automatically acknowledges a client’s receipt of a message.
• CLIENT_ACKNOWLEDGE, in which the client acknowledges the message by calling the message’s acknowledge method.
The following describes the steps in message delivery and acknowledgement:
1. A message is sent from the message producer to the machine on which the TIBCO Enterprise Message Service server resides.
2. The EMS server acknowledges that the message was received.
3. The server sends the message to the consumer.
4. The consumer sends acknowledgement to the server that the message was received.
5. In many cases, the server then confirms acknowledgement to the consumer.
Acknowledgement from the consumer to the server prevents the delivery of duplicate messages.
Undelivered Message Queue
If a message is to be removed from the system in any way besides being properly consumed by a message consumer, the server checks the message for the JMS_TIBCO_PRESERVE_UNDELIVERED property.
When JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves the message to the undelivered message queue, $sys.undelivered. This undelivered message queue is a system queue that is always present and can not be deleted.
To set use of the undelivered message queue, the application that sends or publishes the message must set the boolean JMS_TIBCO_PRESERVE_UNDELIVERED property to true before sending or publishing the message. For example:
message.setBooleanProperty("JMS_TIBCO_PRESERVE_UNDELIVERED",true);
EMS Message Delivery Mode Extensions
JMS has PERSISTENT and NON_PERSISTENT delivery modes for both topic and queue. In addition to these modes, you can use Tibjms.RELIABLE_DELIVERY mode from TIBCO Enterprise Message Service.
PERSISTENT and NON_PERSISTENT delivery require the server to return a system message to the client application to ensure proper handling of messages. Using Tibjms.RELIABLE_DELIVERY as the JMSDeliveryMode precludes the TIBCO Enterprise Message Service server from sending this system message.
In reliable delivery mode, the client application does not wait for this system message—indeed, the server does not send it. Reliable mode decreases the volume of message traffic, allowing better usage of system resources, and higher message rates. You can set the delivery mode to reliable in one of two ways:
• Use a publish() or send() method that accepts a javax.jms.DeliveryMode as a parameter.
• Set the delivery mode for the message producer using the following expression:
No-Acknowledgement Message Receipt
TIBCO Enterprise Message Service provides a mechanism for not acknowledging the receipt of messages. In no-acknowledge receipt mode, after the server sends a message to the client, all information regarding that message for that consumer is eliminated from the server. Therefore, there is no need for the client application to send an acknowledgement to the server about the received message. Not sending acknowledgements decreases the message traffic and saves time for the receiver, therefore allowing better utilization of system resources. No-acknowledgement receipt mode is configured at the session level. Add the com.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE constant when you create the session. For example:
javax.jms.TopicSession session =
topicConnection.createTopicSession(
false,com.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE);
