Azure Service Bus Queue

Question

I like to add azure service bus to one my projects. And the project does a few different tasks: sending email, processing orders, sending invoices etc.

What I am keen to know is, do I create seperate queues to process all these different tasks ? I understand that a queue has one sender and one reciever. That makes sense, but then I will end up with quite a few number of queues for a project. is that normal?

Answer 1

Based on your description:

The project does a few different tasks: sending email, processing orders, sending invoices etc.

These messages are not related to each other. I like to differentiate between commands and events. Commands are sent specifically to certain destination with an expectation of an outcome, knowing that operation could fail. With events it's different. Events are broadcasted and there are no expectations for success or failure. There's also no knowledge about consumers of events to allow complete decoupling. Events can only be handled using Topics / Subscriptions . Commands can be handled either with Queues or with Topics / Subscriptions (a topic with a single subscription would act as a queue).

If you go with events, you don't create separate consumer input queues. You create a topic and subscriptions on that topic. Let's say you'll have a PublisherApp and a ConsumerApp . PublisherApp could create a topic and send all messages to the events topic. ConsumerApp would create the required subscriptions , where each subscription would have a filter based on type of the message you'd like that subscription to receive. For your sample, it would be the following subscriptions:

1. SendMail
2. ProcessOrder
3. SendInvoice

In order to filter properly, your BrokeredMessage s will have to have a header (property) that would indicate the intent. You could either come up with a custom header or use a standard one, like Label .

I wrote a blog post a while ago on topologies with ASB, have a look, it might give you more ideas on how you can set up your entities.

If topology & entities management is not what you'd like to do, there are good frameworks that can abstract it for your and allow your code to work w/o diving into details too much. NServiceBus and MassTransit are two good examples you can have a look at.

Full disclosure: I'm working on Azure Service Bus transport for NServiceBus.

Answer 2

1. First of all look at Azure Storage queue i just switched to it in almost the same scenario. In Storage queue there is NO monthly payment fee you pay for what you use.
2. Queue is not limited to receivers or senders. What i mean by that, is that you could have many listeners for a queue (in case your app is scaled) but as soon as listener picked up event then its locked and not visible to others. (By default timeout is around 30 sec in Azure storage queue and 60 sec in Service bus, so be aware if you need more time for processing your message you need renew lock otherwise you will end up with processing same message multiple times)
3. You can use one queue per all your events and depends on message body you can run different message processors. For instance in my project I am sending message with key Type which identify who is going to process this message. You can also use one queue per type and then in your listeners listen to multiple queues

Look at this link for comparison table

Answer 3

There are 2 approaches based on your design.

1. Queue and Message: Message Body has an indicator tasks: sending email, processing orders, sending invoices etc. The code then process the message accordingly.
2. Topics and Subscriptions: Define topics for each tasks and brokered messages are processed accordingly. This should be better than the Queues.

Answer 4

topics and subscriptions suit your scenario the most. At the subscription end, you can filter the messages based on criteria,in your case, it can be your task ie sendemail,processorder .

If you want to add more tasks in future, you will be free from making any changes on the service bus itself, and will only have do required changes on sender and receiver code.

If you use service bus queues or storage queues, in future , you have to create more queues for adding another tasks and it can become complicated on the management level of your azure infrastrcture.