- Azure Service Bus Topologies
- Azure Service Bus Topologies with Forwarding
- Azure Service Bus Topologies of NServiceBus (current)
- Azure Service Bus Topology migration with NServiceBus (next)
Almost a decade ago Particular Software started supporting customers running on Azure Service Bus by leveraging a robust and reliable queue abstraction called NServiceBus. Particular Software has been one of the early adopters of the PaaS Service. Hundreds of customers later we can look back at many scars and assumptions we made in our code base. One of those “scars” is the way we got started with setting up our first topology.
Like described in previous posts in this series there are different ways of creating topologies to manage entities such as queues, topics and subscriptions and their relationship to each other. The first topology approach that we used wasn’t leveraging forwarding. It used simple conventions to implement a Publish-Subscribe mechanism. The topology was called Endpoint-oriented topology.
EndpointOrientedTopology each publishing endpoint creates a topic called
<publishing_endpoint_name>.events. The subscribing endpoints subscribe to the topic, by creating a subscription for a particular event type called
<subscriber_endpoint_name>.<event_type_name>. Note that each subscription has a single rule, used to filter a specific event type.
When a publisher raises an event, it is published to the publisher topic. Then the subscription entities filter events using the associated rules. Finally, the subscriber endpoint pulls events for processing.
The example below demonstrates a publisher called
Publisher and a subscriber called
Publisher can raise two events,
Subscriber subscribesto both events and two subscription entities are created, one per event type. Each subscription entity filters out events using a rule associated with the subscription.
EndpointOrientedTopology topology had several drawbacks we became aware of over time:
- In order to subscribe to an event, the subscriber must know the publishing endpoint’s name, causing coupling between publisher and subscriber.
- Multiple subscription entities per subscriber cause polymorphic events to be delivered multiple times to the subscribing endpoint.
- When a single subscriber is offline for an extended period of time and events are not consumed, it can cause event overflow. Since a single topic per publisher is used for all the subscribers, when event overflow is happening it will affect all subscribers and not just the one that is offline.
Once forwarding was implemented on the broker we knew this feature could enable us creating a better suitable topology that could overcome the drawbacks mentioned above. For new customers we created the ForwardingTopology that used the single topic approach described in earlier posts. In this topology Subscriptions are created under topic bundle with one subscription entity per subscribing endpoint. Each subscription contains multiple rules; there’s one rule per event type that the subscribing endpoint is interested in. This enables a complete decoupling between publishers and subscribers. All messages received by subscription are forwarded to the input queue of the subscriber. The scenarios described for the endpoint oriented topology would look like the following in the forwarding topology.
Unfortunately for quite some time this made the Azure Service Bus and NServiceBus story a bit more difficult than it should have been. Customers already using the EndpointorientedTopology could not move to the ForwardingTopology because those two topologies were not compatible. New customers were faced with making an educated choice about which topology they wanted to use. For many years we supported both topologies.
When Microsoft announced the new Azure Service Bus client that was compatible with .NET Standard we were forced to implement a new transport because many of the existing configuration options were no longer existent. For that new transport, we wanted to support one topology only which is the superior ForwardingTopology thus enabling all the benefits of that topology and also reducing the number of choices our clients had to make. In order to allow a smooth transition for existing customers we created an online migration path that I’m going to elaborate in the next post.
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 of NServiceBus. Available athttps://www.planetgeek.ch/2019/01/21/azure-service-bus-topologies-of-nservicebus/ [Accessed: 5th February 2019]