- 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
EventBwhenever 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 (
NServiceBus was one of the first adapters of Azure Service Bus. We used it when it was still in preview (yes we have gray hair ;)). The first version of the Azure Service Bus adapter used a similar approach but instead of creating a topic per event or a topic for all the events it created a topic per publisher. This topology was called the Endpoint Oriented Topology which I will describe in more depth in the “Azure Service Bus Topologies of NServiceBus” part of this series.
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.
About the Author:
Daniel Marbach is a Solution Architect at Particular Software Ltd and the CEO of tracelight GmbH. His experience spreads from client and server development to building distributed systems. Daniel has an engineer degree from the University of Applied Science in Horw. He has strong skills in Extreme Programming Practices such as Continuous Integration, Acceptance Test Driven Development and Test Driven Development. Daniel has extensive knowledge in the .NET ecosystem including NoSQ L databases, asynchronous programming, open-source software development and much more. He is a Microsoft MVP for Integration, a frequent speaker, coach and passionate blog writer. Daniel co-founded the .NET Usergroup Central Switzerland and continues his journey of software development with passion.
In his professional life, Daniel has worked for many companies, mainly focusing on software development for industrial, technological or medical applications. Examples include the implementation of firmware upgrade tool for field engineers of a company specialized in breastfeeding and health care, labor analysis software for gene expression and genetic variation with PCR-based light cyclers for a global player in the medical industry, a secure and hybrid elevator configuration utility for an elevator company, architecture and coaching from the introduction up to the marketability of an automated guidance system, coach for Agile Engineering Practices and co-architect of a highly distributed medical customer management system. In his current position, Daniel is improving and extending the Particular Platform and helping customers to develop thriving distributed systems with NServiceBus.
Marbach, D. (2019). Azure Service Bus Topologies. Available at: https://www.planetgeek.ch/2019/01/07/azure-service-bus-topologies/ [Accessed: 5th February 2019]