Message Routing and Topics: A Thought Shift

I started my engineering career with a messaging middleware company out of the Bay Area, California, that came around just when CORBA was being retired, giving rise to MoM and other middleware technologies. Integration problems were classified as internal (EAI) vs. external (B2B) integrations. Terms like Enterprise Dial-Tone and Enterprise Bus were coined to define the problem and exemplify integration solutions. Fun time, indeed! 

We created a broker supporting concepts like Territories, Gateways, Adapters, and Visual Designer to design integrations, which I am proud to have been a part of. Performance was measured by message throughput, i.e., messages routed per second through the broker.  With constraints of the day around CPU power, storage, and memory, we were tinkering with TCP windows, swap and page size, memory-mapped IO, all the tricks around multi-threading, and whatnot to get the best performance. 

Fast forward! Today, I am with Solace as a developer advocate. After dabbling with many technologies and roles, I was fortunate to return to the integration domain where I started. A lot has changed — memory, storage, and CPU are cheaper and available on demand. Cloud technologies have also disrupted this domain; we now have Infrastructure as a Service (IaaS). Scaling, load balancing, and DR responsibilities have been delegated to the cloud service providers. We are currently looking at Integration Platforms as a Service (iPaaS) where the entire integration service stack can be built, deployed, and scaled in no time with ease. This is a monumental shift — nothing less would justify in words.

This article reflects my observations from the MoM perspective and transformation to real-time, event-driven messaging after joining Solace. I use the terms Events and Messages, Payload and Content interchangeably. 

There is one thing that caught my attention and fascination simultaneously. The central theme of a real-time enterprise integration is message routing. Almost all messaging systems employ an intelligent, interest-based subscription mechanism that ensures the routing of messages to interested parties. The intelligent part of routing is built with rules around the Event type (name) and the content. Routing decisions based on an Event type name are straightforward because they are easily accessible and available without unpacking the payload. However, a routing based on filtering rules on the content would require unpacking and evaluating the rules to determine a match. This directly impacts message throughput and performance. Content-based message routing (CBR) is performance-penalizing and not the best choice for real-time messaging scenarios where latency costs good decisions. In the early days of integration, content-based routing was considered essential. Almost all messaging systems based their routing on this principle — from Biztalk Server, webMethods Broker, and Integration Servers from JBoss; Oracle to IBM.

JMS came along and standardized the message exchange interactions with a specification; almost all the vendors followed suit and extended their support. Here came Topics with a simple definition of "a type of destination in a 1-to-many model of distribution." Topics focused on the context in which the message originated, like systems, applications, and microservices. A Topic can also be treated as a destination helping to identify consumers at run-time based on their subscription.

Almost all of the integration products of the day (both past and present) took the notion of Topic as a literal string. Sure, there is nothing wrong with that. Often, it embodied the business context captured in the carried message.

How do the following topic names look?

Looks great, but do they talk to you about the business context? I don't think so :)

They are just literal strings. Why not have them capture the business context at a granular level? Why not use taxonomy in naming, describing, and classifying the data carried in the message? Better than a plain string — sounds good, right? In any business scenario involving data exchange, pumping packets alone won't cut it. Intelligent and efficient message routing matters when the need for real time and speed is the ask. 

In an ideal world, a messaging broker would never need to open the payload — it could be simply passing messages between producers and consumers based on subscription. Not all consumers are equal; they may be built to handle subsets of messages even if they are of the same class. For example, a tax calculation service would need to process the message differently based on the country or region the message is originating from. 

Almost all modern brokers don't open the message payload for any purpose — in other words, topic-based routing has become the preferred mechanism over traditional content-based routing. However, the content might influence the decision on how the message is processed or the type of service to be invoked. This creates the dilemma of inspecting the payload for specifics at the cost performance. Here is where the notion of Hierarchical Topics comes to the rescue.

Fortunately, MQTT-based brokers adopted the hierarchical representation of topics from the get-go. Only a handful of brokers adopted the hierarchical topics in the enterprise realm. Solace Broker pioneered this and made it super-charged with support for multiple protocols, language APIs, and advanced concepts like DMR, Event Portal, and Event Mesh. 

Here are a few examples of hierarchical topics where critical information is captured as levels in the hierarchy.

• A foreign-exchange trading platform could build its messaging system based on a hierarchy that captures elements like application, feed, type, source, and target currencies.

• A manufacturing platform could organize its messaging topics with information around company, department, system, version, type, and product.

• A payments platform could organize its messaging topics with information around an application, type of transaction, bank-id, transaction number, and store-id.

In essence, you can see the reflection of a topic taxonomy representing the business terms that users and applications are familiar with. With the topic levels delimited by a separator ('/' in this case), the topic string is now contextual and human-readable.

The benefits of such a hierarchical scheme don't stop there. Now we can use wild cards at any level to capture a broader range of message topics in a subscription.

1. Single-Level Wildcard: *

A single-level wildcard * replaces one topic level. Here is an example from the payments processing system.

2. Multi-Level Wildcard: >

The multi-level wildcard covers many topic levels. The > symbol represents the multi-level wild card in the topic. A multi-level wildcard must be placed as the last character in the topic and preceded by a forward slash.

The literals at each level are treated as strings — hence, wildcard usage on datatypes like latitude/longitude coordinates and other custom identifiers would also benefit from this simplicity. 

A subscription with this topic would capture ALL the messages from vehicles plying in the geographic region bounded by coordinates of 45.3°N to 45.4°N and -75.7°W to -75.8°W.

With support for versioning, topics can be altered dynamically without affecting the existing subscribers and overall architecture. It is as simple as creating a new version of the topic, promoting the desired field as a topic level in the hierarchy, and updating subscriptions (wildcards may come in handy depending on the change).

My fascination with Hierarchical Topics stems from the ability to route messages intelligently without opening the payload. This is fundamental to accomplishing real-time, low-latency message exchange.

For more information on Hierarchical Topics, check out the four-part blog series that dives into details of flexible event filtering and dynamic routing, and a quick intro video.