JMS Message Structure

A JMS message has three sections:• Header (some header fields are required)• Properties (optional)• Body (optional)

Header FieldsThe header contains ten predefined fields that contain values used to route anddeliver messages.

PropertiesTIBCO Enterprise Message Service includes several vendor-specific properties inthis area. TIBCO-specific property names begin with JMS_TIBCO.

Message BodiesA JMS message has one of several types of message bodies, or no message body atall.

Message PersistenceJMS defines two message delivery modes, persistent and non-persistent. Thismode is set by the message sender or publisher in the JMSDeliveryMode messageheader 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 persistentstorage, except when they are published to a topic that has no durablesubscribers. When a topic has no durable subscribers, there are no subscribersthat need messages resent in the event of a server failure. Therefore, messages donot need to be saved, and performance is improved because disk I/O is notrequired.

File Locking

Each EMS server writes persistent messages to a store file. To prevent two serversfrom using the same store file, each server restricts access to its store file for theduration of the server process.

On Windows platforms, servers use the standard Windows CreateFile function,supplying FILE_SHARE_READ as the dwShareMode (third parameter position) torestrict access to other servers.

Character Encoding in MessagesTIBCO Enterprise Message Service clients can specify a variety of commoncharacter encodings for strings in messages. The character encoding for a messageapplies 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 bodyThe EMS client APIs (Java, .NET and C) include mechanisms for handling stringsand specifying the character encoding used for all strings within a message.

Message CompressionTIBCO Enterprise Message Service allows the message body to be compressed bythe client before the message is sent to the TIBCO Enterprise Message Serviceserver.

Message compression is especially useful when messages will be stored on theserver (persistent queue messages, or topics with durable subscribers). Settingcompression ensures that messages will take less memory space in storage.

When messages are compressed and then stored, they are handled by the serverin the compressed form. Compression assures that the messages will usuallyconsume 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 messagemust access the message properties and set the boolean propertyJMS_TIBCO_COMPRESS to true before sending or publishing the message. Forexample:message.setBooleanProperty("JMS_TIBCO_COMPRESS",true);

Compressed messages are handled transparently. The client code only sets theJMS_TIBCO_COMPRESS property. The client code does not need to take any otheraction.

Message AcknowledgementThe specification defines three levels of acknowledgement:• DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicatemessages.• AUTO_ACKNOWLEDGE, in which the session automatically acknowledgesa client’s receipt of a message.• CLIENT_ACKNOWLEDGE, in which the client acknowledges the messageby 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 theTIBCO 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 wasreceived.5. In many cases, the server then confirms acknowledgement to the consumer.Acknowledgement from the consumer to the server prevents the delivery ofduplicate messages.

Undelivered Message Queue

If a message is to be removed from the system in any way besides being properlyconsumed by a message consumer, the server checks the message for theJMS_TIBCO_PRESERVE_UNDELIVERED property.

When JMS_TIBCO_PRESERVE_UNDELIVERED is set to true, the server moves themessage to the undelivered message queue, $sys.undelivered.This undelivered message queue is a system queue that is always present and cannot be deleted.To set use of the undelivered message queue, the application that sends orpublishes 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 ExtensionsJMS has PERSISTENT and NON_PERSISTENT delivery modes for both topic andqueue. 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 systemmessage to the client application to ensure proper handling of messages. UsingTibjms.RELIABLE_DELIVERY as the JMSDeliveryMode precludes the TIBCOEnterprise Message Service server from sending this system message.In reliable delivery mode, the client application does not wait for this systemmessage—indeed, the server does not send it. Reliable mode decreases thevolume of message traffic, allowing better usage of system resources, and highermessage 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 followingexpression:

No-Acknowledgement Message Receipt

TIBCO Enterprise Message Service provides a mechanism for not acknowledgingthe receipt of messages.In no-acknowledge receipt mode, after the server sends a message to the client, allinformation regarding that message for that consumer is eliminated from theserver. Therefore, there is no need for the client application to send anacknowledgement to the server about the received message. Not sendingacknowledgements 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 thecom.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE constant when you create thesession. For example:javax.jms.TopicSession session =topicConnection.createTopicSession(false,com.tibco.tibjms.Tibjms.NO_ACKNOWLEDGE);