Anatomy of a Message
In general terms, an event, along with a query or command, is a type of message:
- An event is something that has happened that your application needs to tell other applications about. Events can be thought of as streams of updates. Pricing streams and trade streams in capital markets are examples of event streams.
Events are so common that we often use the terms event and message interchangeably in this documentation.
Events always follow the publish / subscribe messaging model.
- A query is a message that retrieves information (for example, HTTP GET and HEAD methods). A query requires a response. Within a messaging system queries must be synchronous for the requesting application.
Queries can follow the point-to-point or request-reply messaging model.
- A command instructs another application to do perform an action or change a state (for example, HTTP POST, PUT, and DELETE methods. Commands, like queries, require a response, and must be synchronous for the commanding application.
Like queries, commands can follow the point-to-point or request-reply messaging model.
Solace PubSub+ supports all 3 types of messages in either synchronous or asynchronous mode from a sender, and either persistent or non-persistent quality of service (QoS).
A message has three parts: Header, Properties, and Body, as shown in the following diagram:
The header is the part of the message used by the event broker for routing messages through the system. Some header fields, such as Destination and Delivery Mode, are required, while others are optional. For example, the reply-to topic is optional, and is only needed for Request-Reply messaging, where the Replier needs to know where to send its responses.
In addition to the header fields, application-specific properties can also be included as part of the message. These application-specified properties are unmodified by the event broker, and can be used to facilitate communication between applications. Some APIs define their own standard properties. For instance, JMS has defined properties such as JMSXUserID and JMSXAppID which can be used to identify the user or application sending the message. Besides API-defined standard properties, applications can also specify properties. An example of an application-specified property might be an Order ID an Order Management System uses as a unique identifier to track all messages related to a given purchase.
The body of a message is often called the payload, or the attachment. It contains data in an application-specified format, and is transported unmodified by the event broker. The body is made up of raw binary data, or structured data such as text, streams, maps, or otherwise. Regardless, Producers and Consumer must agree upon the payload format so that the data can be properly interpreted.