What is Messaging?
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
- Topic endpoints are used when the message is intended to be consumed by more than one subscriber. The following diagram illustrates event messages disseminating to multiple subscribers through a topic endpoint.
- Queues are used when the message is intended to be consumed by at most one subscriber.
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.
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, 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?