# EMS Extensions to JMS Messages

The JMS specification details a standard format for the header and body of a message. Properties are provider-specific and can include information on specific implementations or enhancements to JMS functionality. See EMS Message Properties for the list of message properties that are specific to EMS.

In addition to the EMS message properties, EMS provides a select number of extensions to JMS. These are:

- The JMS standard specifies two delivery modes for messages, PERSISTENT and `NON_PERSISTENT`. EMS also includes a `RELIABLE_DELIVERY` mode that eliminates some of the overhead associated with the other delivery modes. See `RELIABLE_DELIVERY`.
- For consumer sessions, you can specify a `NO_ACKNOWLEDGE` mode so that consumers do not need to acknowledge receipt of messages, if desired. EMS also provides an `EXPLICIT_CLIENT_ACKNOWLEDGE` and `EXPLICIT_CLIENT_DUPS_OK_ACKNOWLEDGE` mode that restricts the acknowledgment to single messages. See Message Acknowledgement.
- EMS extends the `MapMessage` and `StreamMessage` body types. These extensions allow EMS to exchange messages with TIBCO Rendezvous, which contains certain features not available within the JMS `MapMessage` and `StreamMessage`.

  TIBCO Enterprise Message Service adds these two extensions to the `MapMessage` and `StreamMessage` body types:

  - You can insert another `MapMessage` or `StreamMessage` instance as a submessage into a `MapMessage` or `StreamMessage`, generating a series of nested messages, instead of a flat message.
  - You can use arrays as well as primitive types for the values.

    These extensions add considerable flexibility to the `MapMessage` and `StreamMessage` body types. However, they are extensions and therefore not compliant with JMS specifications. Extended messages are tagged as extensions with the vendor property tag `JMS_TIBCO_MSG_EXT`.

    For more information on compatibility with Rendezvous messages, see Message Body.

Copyright © Cloud Software Group, Inc. All rights reserved.