Natively supported message types

This section outlines the messages types that are natively supported for Eclipse Amlen and provides an explanation of each type.

Eclipse Amlen natively supports the following type of messages:

  • IMA message

    An IMA message consists of a small header, a properties area, and a body (or payload) area. The physical representation of this message varies by component and protocol. The message header is very small an consists only of small fixed size items such as persistence, reliability, redelivery count, and message type. The engine allows any number of areas, but all messages in Eclipse Amlen create exactly two areas, properties and body. Each of these areas is or arbitrary length. The properties are stored in a concise format which is designed to minimize the size and allow for easy sequential read and append, but not for random access or editing. The system properties (such as the Topic name or JMS header fields) are kept along with the user properties. System properties have numeric IDs, and user properties have names. The body or payload of the message is just a blob, but there is a header field of message type which indicates how to interpret the body. The server does not interpret the body in any way if the source and destination protocols are the same. The message header within the engine is defined in the server_utils include file ismmessage.h .

  • MQTT message
    The MQTT message is defined by the MQTT protocol specification as the PUBLISH message. (See the MQTT protocol specification document to review the specification.) It consists of a single-byte header, an optional two-byte message ID, a topic name, and the message payload. The header is a single byte containing the qualities of service (QoS) (0-2), retain flag, and dup flag. The message ID is used for QoS>0 but is only used for communications between client and server. It is not really a part of the message. The topic is a UTF-8 string, and the body is a blob of bytes. When an MQTT message is received, the MQTT protocol adds the topic name as a system property into the message. The recipient of the message is de-coupled from the originator of the message. This is useful as the consumer of the data only receives the messages when they are interested in a particular type of message and can subscribe or unsubscribe at any point from a message feed without affecting the message sender.
    Note: A server can delete a retained message if it receives a message with a zero-length payload and the Retain flag set on the same topic.
  • JMS message
    JMS message consists of a number of header fields, user properties, and a body. The body is defined by its message type which is one of the header fields. The properties are keyword, type, value tuples. A number of the header fields are arbitrary length strings. JMS supports six message types or interfaces. In addition to the base interface, Message, five subinterfaces are also supported; BytesMessage, MapMessage, ObjectMessage, StreamMessage, and TextMessage. In Eclipse Amlen, all JMS text messages are a UTF-8 representation of the body string. Map messages and stream messages use the concise encoding that is also used for properties. All property names and string values are also in UTF-8.
    Note: Only use JMS ObjectMessages if you are certain that the message comes from a trusted source. Using JMS ObjectMessages from other sources exposes the environment in which you run the JMS client to denial of service or authorization takeover. As it is difficult to ensure that the sender is trusted in JMS, you might choose not to use JMS ObjectMessages. If you receive a JMS ObjectMessage, do not invoke getObject() on the message.