A few months ago (when I was new to Azure Queues and the SDK tools out there) I Googled "how do I do this" and "how do I do that"... here is where I am today:
I'm using a QueueClient
(Microsoft.ServiceBus.Messaging - Microsoft.ServiceBus.dll) to receive messages from an Azure Queue.
In my same program I'm also using a MessageSender
(from the same namespace and dll) to send messages to the Azure Queue.
My program has to track a Dictionary<string, QueueClient>
and a Dictionary<string, MessageSender>
- which is more complicated than it should be.
Now that I'm more familiar with the Azure SDKs... I realize that the QueueClient
class can both send and receive... So why am I keeping track of 2 objects when the first one can do both?
Is there any reason to use the MessageSender
class instead of the QueueClient
class?
If I need to send and receive, shouldn't I just use the QueueClient
class?
Storage queues provide a uniform and consistent programming model across queues, tables, and BLOBs – both for developers and for operations teams. Service Bus queues provide support for local transactions in the context of a single queue.
Microsoft Azure supports two types of queue mechanisms: Azure Queues and Service Bus Queues. Azure Queues, which are part of the Azure storage infrastructure, feature a simple REST-based Get/Put/Peek interface, providing reliable, persistent messaging within and between services.
Maximum Number of Queues in Service BusA maximum of 10,000 queues can be created within a single Service Bus Namespace.
Service Bus enables up to 1000 concurrent connections to an entity. If a queue requires more than 1000 receivers, replace the queue with a topic and multiple subscriptions. Each subscription can support up to 1000 concurrent connections.
We have exposed the two different object to support symmetry and ease-of-use. As you are aware we have Topics/Subscriptions as well as Queues. If you are just using Queues then you can create a QueueClient and achieve all the operations needed thru that. But say you later wanted to move to a Topic/Subscription publish-subscribe model. Programming against a generic MessageSender and MessageReciever will allow you to change the underlying topology and not have to modify any code (just the address urls/names). Thus you can write code that can work both in Queue as well as Topic/Subscription scenarios.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With