In technology terms, messaging lets computer systems share information without requiring direct connections or awareness of each others location. Messaging is analogous to postal and shipping services. Just as you would hand letters or packages to a carrier and trust that they will get to where you want them to go, so it is with messaging — your applications hand off information to a messaging system that routes it to whatever other applications it needs to get to.
At its most basic, messaging involves the following participants:
- Publisher—the entity that sends or publishes a message (also called a producer)
- Message—the information the publisher wants to send. Messages often contain event data, but can also carry queries, commands, and other information.
- Messaging system—the infrastructure that transmits the message
- Subscriber—the ultimate receiver of the message (also called a consumer)
In an event-driven architecture (EDA), a message typically has a destination that separates the publisher from the subscriber. In
The following diagram illustrates event messages disseminating to multiple subscribers through a topic endpoint.
Message Types
The PubSub+ Platform supports three types of messages:
- An event message describes something that an application needs to tell other applications about. An event stream is a series of event messages published as events occur. Pricing streams and trade streams in capital markets are examples of event streams. Events and the messages that describe them are so closely tied together that we often use the terms event and message interchangeably in this documentation.
- A query is a message that retrieves information (for example, using HTTP GET and HEAD methods). A query requires a response.
- A command instructs another application to perform an action or change a state (for example, using HTTP POST, PUT, and DELETE methods). Commands, like queries, require a response.
Message Structure
A message has three parts: Header, Properties, and Body, as shown in the following diagram:
Header
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, Reply-to-Topic is only needed for Request-Reply messaging where the Replier needs to know where to send its responses.
Properties
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. In addition to API-defined standard properties, applications can also specify properties. An example of an application-specified property is an Order ID in an Order Management System used as a unique identifier to track all messages related to a given purchase.
Body
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, or maps. Regardless, producers and consumers must agree upon the payload format so that the data can be properly interpreted. Event messages use a schema to define the payload format.
Want to know more about messaging? Move on to Message Exchange Patterns.
Or jump ahead and learn What Are Event Brokers?