Understanding Topics

To understand how messages flow from publishers to subscribers, you need to understand the role played by topics in the publish-subscribe model.

What Are Topics?

In an event-driven architecture (EDA), events are published to topics and endpoints can subscribe to one or more topics to attract events from publishers. Technically, Solacetopics are simply strings composed of one or more levels added as metadata in a message header that let publishers classify messages and let subscribers specify what they want to receive messages about. This publish-subscribe model enables event brokers to use topics as routing information to send event messages everywhere they need to go.

However, a topic is more than just a string providing routing info. You can also think of a topic as a hierarchical definition of the subject of an event message. A topic can both route events to the appropriate recipients and categorize and describe the event itself. A well-defined topic contains details specific to the instance of an event and subscribers can receive only the event instances that are relevant to them rather than receiving messages about all instances and then processing the payloads before discarding messages they don't need. A well-defined topic structure can make your topics smart.

Defining Topics

A Solacetopic is a string with the format a/b/c/.../n, where a, b, c and so on are levels in a hierarchy that you design to describe your events. For example, if you're publishing information for Example Airline (EA), you might need topics like flight/boarding/ea1234/jfk and flight/departed/ea321/yow to organize the events you're publishing. You can learn about the full syntactical rules, construction, and encoding in Solace Message Format Topics.

One or more topic levels can be defined using variables that are replaced with properties specific to the event when it occurs. Using variables allows topics to define the event itself and not just the category of the event. Variables could be used to include a location, an order id, and other data about the event within the topic. Both of the event instances for our airline, flight/boarding/ea1234/jfk and flight/departed/ea321/yow can be sent by an application using the topic flight/[status]/[flightNumber]/[origin].

To learn more about defining topics, you can Try PubSub+ Event Brokers and read about Topic Architecture Best Practices.

Topic Subscriptions

A topic subscription is a string used to attract published events. Topic subscriptions can contain wildcards to match with multiple topics. The * and > characters can be used as wildcards in topic subscriptions.

  • *

    • When * appears by itself at a level within a topic subscription, it indicates a wildcard match at that level. For example, flight/*/ea1234 matches the topics flight/boarding/ea1234 and flight/departed/ea1234.

  • >

    • The > character is used at the last level of a subscription to indicate a “one or more” wildcard match. For example, flight/boarding/> doesn't match the topic flight/boarding, but it does match flight/boarding/ea1234 and flight/boarding/ea321/yow/fra.

To learn more about wildcard rules and their use in topic subscriptions, see Wildcard Characters in Topic Subscriptions.

How Topics Describe and Route Events

Consider the following topic example. The brackets "[ ]" indicate a variable in the topic that is replaced in the message by data specific to the event:

flight/[status]/[flightNumber]/[origin]/[destination]

This example could result in an event topic of flight/boarding/ea1234/jfk/ord where:

  • flight indicates the type of event

  • boarding indicates the action that generates the event

  • ea1234/jfk/ord are properties of the specific event

This topic structure can be used by applications in the system to publish status information about any flight. Subscribing client applications can subscribe to only the events they need to receive. For example:

  • The crew for EA flight 1234 can receive all events related to their flight with the subscription flight/*/[flightNumber]/>

  • The ground crew at JFK can receive all boarding and taxiing events with an origin of JFK and all landing events with a destination of JFK with the following subscriptions:

    • flight/boarding/*/jfk/*
    • flight/taxiing/*/jfk/*
    • flight/landing/*/*/jfk

Using a rich topic hierarchy allows event brokers to intelligently route topics without deserializing, decoding, or interpreting the event. Event brokers don't need to understand the event, they just need to know how to act on the event's topic information. This hierarchy creates smart topics, which describe the event by using multiple, dynamic topic levels that subscribers can filter on to receive exactly the information they need.

How Rich Topic Hierarchies Benefit an Event Mesh

Smart topics and subscriptions serve various purposes within an event mesh and enable the following benefits when combined with a rich topic hierarchy:

Event Routing
The event mesh relies on an event's topic and consumer subscriptions to make routing decisions. Event brokers within a mesh can read the topic and match it to consumer's subscriptions, which describe what kind of data the consumer is interested in. The event topic allows the event broker to make routing decisions without the need for complex understanding of the data encoded in the event's payload.
Event Filtering
Consumers in an event mesh can use subscriptions to have fine-grained control over what data they receive. When combined with a rich topic hierarchy, it allows consumers to receive exactly the data required from the event mesh. Without this fine-grained filtering, consumers may need to discard some of the received data, or an intermediary process would need to re-publish the data to a more specific stream. This filtering is an example of how Solace topics are smart.
Event Access Control
Access control lists (ACLs) allow for administrative management of which events publishers are permitted to produce and which events consumers can receive. This management allows you to control the flow of data both into, and out of an event mesh. When combined with a rich topic hierarchy, you can precisely control the flow of data based on the description of the data in the topic. Lack of precise access control may enable rogue applications to consume privileged information or initiate restricted actions.
Event Handling Policy
You can define policies based on topic subscriptions that handle events within the event broker with respect to priority, eligibility for replay, and replication. The routing from a producer to a consumer can also be influenced using statically-defined bridging policies. With a rich topic hierarchy, administrators can ensure that the right messages are replicated, added to replay logs, etc.
To learn more about building a rich topic hierarchy, see Topic Architecture Best Practices.

More About Solace Topics

Our Solace Developer Advocate walks through how topics are implemented in Solace and how the PubSub+ event broker filters and routes messages based on subscriptions and wildcard characters. He also provides some examples for different types of use cases.

All About Solace Topics!

How and when clients receive event messages and the how event brokers interact with publishers and clients depends on the type of messaging used. Learn more under Message Delivery Modes.