Вы находитесь на странице: 1из 3

JMS Message Structure

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.

TIBCO Enterprise Message Service includes several vendor-specific properties in
this area. TIBCO-specific property names begin with JMS_T IBCO.

Message Bodies
A JMS message has one of several types of message bodies, or no message body at

Message Persistence
JMS defines two message delivery modes, persistent and non-persistent. This
mode is set by the message sender or publisher in the JMSDe l i ve ryModemessage
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

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 Crea teF i l efunction,
supplying F ILE_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

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_T IBCO_COMPRESS to true before sending or publishing the message. For
message . se tBoo leanProper ty ( " JMS_T IBCO_COMPRESS" , t rue ) ;
Compressed messages are handled transparently. The client code only sets the
JMS_T IBCO_COMPRESS property. The client code does not need to take any other

Message Acknowledgement
The specification defines three levels of acknowledgement:
• DUPS_OK_ACKNOWLEDGE, for consumers that are tolerant of duplicate
• 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 acknow ledge 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
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

When JMS_T IBCO_PRESERVE_UNDEL IVERED is set to true, the server moves the
message to the undelivered message queue, $sys .unde l i ve red.
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_T IBCO_PRESERVE_UNDEL IVERED
property to t ruebefore sending or publishing the message.
For example:
message . se tBoo leanProper ty ( " JMS_T IBCO_PRESERVE_UNDEL IVERED" , t rue ) ;

EMS Message Delivery Mode Extensions

JMS has PERS ISTENT 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

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 =