Introducing Important Terms

In technology terms, messaging enables computer systems to share information without requiring direct connections or any awareness of each other's physical location.

A helpful analogy for messaging is the postal and shipping service. Just as you hand letters or packages to a mail carrier and trust that they will deliver them to the correct address, applications hand off information to a messaging system, which takes care of routing that data to all recipient applications.

At its most basic level, messaging relies on the following participants:

Producer

The domain logic, service, or business application where an event actually originates (e.g., an e-commerce platform where a customer places an order). It represents the business context and source of truth for the event.

Publisher

The technical component, client library, or infrastructure interface responsible for serializing, routing, and transmitting the event message to the event broker or messaging channel.

Note

In daily practice, Producer and Publisher are very frequently used interchangeably, and in most team discussions, mixing them up causes no issues at all. However, distinguishing between them can be useful in system architecture to separate business logic (where the event happens) from infrastructure logic (how the event is delivered).

Message

The information the publisher wants to send. Messages often contain event data, but they can also carry queries, commands, and other types of information.

Messaging System

The underlying infrastructure that transmits the message.

Consumer (or Subscriber)

The ultimate receiver of the message.

Destination

A destination is generally a queue or a topic endpoint. While a queue receives and stores messages directly, a topic endpoint is a durable entity that subscribes to a topic and captures matching messages persistently, both are managed by event brokers.

An event message describes something that an application needs to inform other applications about, with a continuous series of these messages published in real time referred to as an event stream, such as pricing or trade streams in capital markets. Because events and the messages describing them are so tightly coupled, the terms are frequently used interchangeably.

In contrast, a query is a message designed to retrieve information from another application and strictly requires a response, this pattern is sometimes called request-reply. Similarly, a command instructs another application to perform an action or modify its state and likewise expects an acknowledgment or response from the receiving system.

A message consists of three distinct parts: Header, Properties, and Body.

Header

The header is used by the event broker to route messages through the system. Some header fields are required, such as Destination and Delivery Mode, while others are optional. For example, a Reply-to-Topic field is only needed for request-reply messaging where the replier must know where to send its response.

Properties

Beyond the header fields, a message can include application-specific properties that remain completely unmodified by the event broker to facilitate seamless communication between systems. These properties fall into two main categories: API-defined standard properties, which are established by specific messaging protocols, such as JMSXUserID or JMSXAppID in JMS to identify the sending user or application, and custom application-specified properties created directly by software systems, such as CorrelationKey or Order ID, used by an Order Management System to track all messages associated with a particular purchase.

Body

Also called the payload or attachment, the body contains data in an application-specified format. It is transported unmodified by the event broker and can consist of raw binary data or structured data (such as text, streams, or maps). Producers and consumers must agree upon the payload format so the data can be properly interpreted, with event messages relying on a schema to define this format.

An event broker is a piece of middleware that serves as the central messaging infrastructure in an Event-Driven Architecture (EDA). It acts as an intermediary between producers and consumers, facilitating the exchange of event messages across various communication patterns. When a producer application publishes an event, it sends the message directly to the event broker, which evaluates the destination and routes it to all subscribing clients.

Event brokers can be deployed in several physical or virtual form factors:

• Hardware appliances

• Software installations

• Software-as-a-Service (SaaS)

Modern event-driven landscapes can incorporate multiple broker types simultaneously. For example, an EDA might combine Solace software or hardware appliance brokers with Kafka event brokers. Within this ecosystem, SAP Integration Suite, advanced event mesh offers dedicated event broker services to handle enterprise messaging requirements.

To understand how an event broker works, imagine a smart digital distribution hub operating behind a food delivery application. When a customer places an order for a pizza and taps payment, the ordering system acts as a producer and emits a single OrderPlaced event. Instead of the customer's phone needing to make individual calls to the restaurant, locate a driver, and update loyalty points, it simply publishes that single message to the event broker. Upon receiving the event, the broker checks its internal routing rules to identify all subscribed consumers and instantly delivers copies of the message to the restaurant kitchen to start preparation, the driver dispatch system to assign a courier, and the rewards service to credit customer points. By managing all filtering, queuing, and delivery in the background, the event broker allows the originating device to move on immediately while ensuring that every interested system receives the update simultaneously in real time.

Applications and devices that publish or consume events connect to the event broker as clients, each using an assigned client username. To manage these connections securely, event brokers rely on two primary administrative configurations: Client Profiles, which govern technical connection properties and resource limits for connected clients, and Access Control List (ACL) Profiles, which dictate authorization levels by controlling the specific topics a given client is permitted to publish to or subscribe from.

In an Event-Driven Architecture, topics serve as the foundational mechanism for categorizing and routing event messages between publishers and subscribers. Technically, a topic is a text string composed of one or more hierarchical levels embedded in a message's header metadata. In a publish-subscribe model, publishers tag messages with these topic strings to classify their content, while subscribers use them to specify which messages they wish to receive, allowing event brokers to rely on this metadata as routing instructions. Beyond basic technical routing, however, a topic acts as a hierarchical definition of an event's business context, such as its location, action, or related entity. This well-defined structure enables "smart routing," allowing subscribers to create precise subscriptions for only the specific event instances relevant to them, which eliminates the need for downstream applications to consume every message and inspect payloads before discarding irrelevant data.

Topics typically follow a hierarchical structure where individual levels are separated by a forward slash (/). The general pattern moves from broad to specific (from general context to granular detail).

A widely used standard pattern looks like this:

<Company> / <Domain> / <Object> / <Action> / <Version> / <Details>.

1
acme/logistics/truck/telemetry/v2/germany/truck-104

Because of this clear hierarchy, consumers can use wildcards (placeholders) to precisely filter only the messages they want to receive:

acme/shop/order/created/v1/eu/*

Subscribes to all newly created orders in Europe (regardless of the order ID).

acme/shop/order/*

Subscribes to every order-related action (created, cancelled, shipped, etc.).

acme/logistics/truck/telemetry/>

Subscribes to all truck telemetry data across all remaining levels.

In event-driven architecture, guaranteed messages ensure that events are reliably delivered from producers to consumers at least once, preventing data loss even during network failures or system outages. Guaranteed messages are stored in endpoints on the event broker. There are two types of endpoints:

• Queues: A queue is an endpoint configured with topic subscriptions that clients can use to publish and consume messages. Queues can subscribe to multiple topics and receive all messages matching those subscriptions. They can provide exclusive access to a single consumer or share access among multiple consumers to distribute the workload.

• Topic Endpoints: A topic endpoint attracts messages published to a single topic that matches its specific subscription. Any topic endpoint with a matching subscription will receive those incoming messages.

Queues are much more flexible than topic endpoints and represent the recommended approach for most applications. They support multiple topic subscriptions and offer extensive configuration options to suit diverse application needs. Topic endpoints are generally intended for use only with JMS applications.

Queues on an event broker function similarly to queues in standard message queuing systems:

1. Producers send guaranteed messages to the event broker.

2. The messages are stored in the queue and delivered immediately if consuming clients are online and connected, or retained in the queue until the consumer connects.

3. The consumer acknowledges the message once it finishes processing it.

4. The event broker deletes the message from the queue.

Queues can be either durable or non-durable:

• Durable queues exist until explicitly deleted by an administrator. They collect messages regardless of whether clients are online or offline. When offline clients reconnect, they receive all the messages accumulated during their absence.

• Temporary (or non-durable) queues are tied to the lifecycle of the client connection and ensure message persistence while clients are actively online. Temporary queues and topic endpoints last only as long as the client's session remains connected. If a client disconnects, the event broker automatically removes the temporary queues, and messages do not accumulate while the client is offline.

Message replay enables an event broker to resend messages to new or existing clients upon request, even hours or days after the broker initially received them. Replay can be executed on either a queue or a topic endpoint. When message replay is enabled, event brokers store guaranteed messages in a dedicated replay log. These messages are retained until the log reaches capacity, at which point the oldest messages are purged to clear space for new incoming ones.