- Azure Service Bus Topologies (current)
- Azure Service Bus Topologies with Forwarding (next)
- Azure Service Bus Topologies of NServiceBus
- Azure Service Bus Topology migration with NServiceBus
Once you start using Azure Service Bus, you are immediately confronted with queues, topics, subscriptions, and rules. Not only do you have to understand what operational capabilities each of those entities incorporate but you also have to come up with an optimal way of “stitching” them together to create a topology that will satisfy your needs. A good topology allows decoupling senders from receivers and publishers from subscribers by efficiently exchanging messages between clients connected to Azure Service Bus.
To better understand what a topology represents let’s look at the following simple scenario. We have a publisher called
Publisher and a subscriber called
Subscriber. The publisher publishes
EventB. The subscriber is interested in receiving
EventB whenever they are published. The entities that are involved to map the above publisher and subscriber scenario form a topology. There are different possibilities to create a topology that represents the above scenario, and each has its benefits and drawbacks that I will not dive into in this article.
As a common baseline, we probably want to have a queue for all the messages for the subscriber and a queue for all the messages for the publisher. For all directed messages to the subscriber or the publisher, we achieve inherent loose coupling between those two components because the producer and consumer are unaware of each other and messages are durably stored until the receiving party can process the messages. To represent the events that will be published one or more topic needs to be created. It is possible to represent each published event with its topic or have a common topic that bundles all published events together.
In the topology illustrated above the publisher creates a topic per Event it publishes. Therefore the publisher would be responsible for creating the topic for
EventB. The publisher is not responsible of managing the subscriptions. Subscriptions are created by the subscribers. Based on simple conventions the Subscriber should be able to determine based on the event type to which topic it needs to subscribe to.
To simplify the management of topics multiple topics could be bundled together into a bundle topic. Publishers would create the bundle topic if not already existant. The mapping logic on the subscriber side becomes simple since the topic is always the same. Subscribers are still responsible for managing their subscriptions.
No matter what approach you’ll be using Subscriptions need to be created that subscribe to topics and filter the messages on a topic. Filtering on subscriptions is achieved by adding rules to a subscription. By choosing a topic per event, the subscriptions will have a simple rule that catches all the messages published to the topic (
1=1, CatchAll). If multiple events are bundled together with the rules underneath a subscription need to filter based on the event type like illustrated above (
Subscriptions are almost like virtual queues. They keep a copy of the messages that matched the rules attached to subscription until the owner of the subscription receives all the messages enqueued. In both illustrated topologies the subscriber needs to deterministically be able to map an event to a subscription and manage the receiving infrastructure per subscription not to miss messages enqueued.
NServiceBus was one of the first
In the next blog post we’ll look into potential drawbacks of the above topology approach and how those can be addressed by leveraging an Azure Service Bus feature called Forwarding.