Table of contents

1. The future of Azure Service Bus .NET SDK
2. ServiceBusClient
3. ServiceBusSender
4. ServiceBusReceiver
5. Safe Batching

What’s a message?

Throughout the time, the Azure Service Bus message has changed a lot.

In Track 0, it was a BrokeredMessage that included both the data and the disposition operations. One drawback that was found with that implementation was the difference with regards to the disposition operations when it came to the protocol: SBMP vs AMQP.

Table of contents

1. The future of Azure Service Bus .NET SDK
2. ServiceBusClient
3. ServiceBusSender
4. ServiceBusReceiver
5. Safe Batching

Entry point

Back in the days of Track 0 to be able to work with the SDK, everything had to go through a factory class called MessagingFactory. The messaging factory was responsible for the construction of all the Service Bus constructs to perform any operation. These constructs where QueueClient, SubscriptionClient, TopicClient, MessageSender, and MessageReceiver. The messaging factory had dedicated factory methods per each construct. That’s probably not the most important technical detail except that there was something additional that MessageFactory has provided. Connection pooling

The past and the current of the SDK

The Azure Service Bus SDK for .NET is one of the oldest Azure SDKs. Its first public appearance as a NuGet package WindowsAzure.ServiceBus goes back to 2011. Back then, it was for .NET Framework and closed source. The package had an excellent mileage and is still used on multiple projects even today. And then the .NET Core and Standard have landed. Times have changed, open-source has become much more mainstream and accepted. The Azure Service Bus .NET SDK has moved into the brand new world with a successor package, Microsoft.Azure.ServiceBus. Started in early 2017, it showed up, causing some havoc to the brownfield projects. These projects were forced to face a complete rewrite due to the nature of the disruptive changes introduced by the new package. Once the dust has settled, the old and the new SDK nomenclature has established, and slowly projects have embraced the new SDK. There was a balance in the Force.

Azure Event Grid is by far not a new kid on the block. Announced in January 2018, the service promised to get us closer to the event-driven architecture and replace the cumbersome polling for communication between services with a simple mechanism - pub/sub. Other the course of two years, we’ve seen some Azure services adding a few events, unleashing the power of Event Grid. Yet the list of services and their corresponding events are still shy to call it done-done. Current services providing some events are:

Working with a remote broker can be a challenge at times. The latency caused by the roundtrip to the broker to fetch a single message can exceed the processing time of that message. To help with this problem, Azure Service Bus (ASB) offers a prefetching option to retrieve messages before they are requested. This option is available with all three clients capable of retrieving messages: MessageReceiver, QueueClient, and SubscriptionClient. When a message is requested, and this option is turned on, the ASB client retrieves more messages. The additional messages are kept in a memory buffer until the user code requests the next message. Except for this time, the client will not fetch it from the broker but rather from the in-memory buffer. That beats the latency and improves the overall throughput of the application or the system performing message processing.

Azure Functions basics

Azure Functions design is a modular design. It consists of

• Mandatory trigger
• Function logic
• Optional one or more output bindings

Triggers and output bindings can be of different types. For example, a trigger could be an Azure Service Bus message, while an output binding could be a Storage Blob. The flexibility to mix and match is extremely powerful but has a price. And that price is the necessity to keep triggers and output bindings independent of each other, having no connection or relation whatsoever. In almost all combinations of triggers and output bindings, it’s expected to be the case with one exception when both the trigger and the output binding are of Service Bus type.

The principle of the auto-forwarding feature is simple and straightforward.
Thought use cases are not always obvious, and implementation sometimes can get a twist.
If you’d like to learn more, read all about the feature in my post here.

You might have a similar reaction to the Principal Program Manager Lead for Azure Messaging 😉

This week had an opportunity to present at the great Techorama conference. This year it was hosted in the Netherlands, executed by Dutch and Belgian teams. For a first time conference, I was amazed how well it was set up, the flawlessness, the speaker line, and the excitement they have managed to build around the event for both speakers and attendees. Not to mention the venue that was perfectly suited for the event, spacious, and filled with natural light while being there for two days.

This is a follow-up post discussing how to deal with large messages. This time, I’m looking at implementing Claim Check pattern in a simple manner, using Azure Storage Queues, which is powering Azure Service Bus ServiceBus.AttachmentPlugin implementation.

Whenever you deal with messages, message size is always a question you’ll have to answer and address. If you’re interested some of the factors going into message size and high-level options to tackle the challenge, continue here.