messages moved from azure subscription to azure queue before being dispatched to code ?

[sabbadino]

Hi, I had a look at how rebus/"rebus asb transport" actually do their magic using the ASB explorer.

It seems to me that messages are sent to the subscription and then moved to a queue before being dispatched to the application code subscriber. Is this documented somehow ? isn't it possible to dispatch to code the message directly from the subsription ?

thank you enrico

[mookid8000]

(...) isn't it possible to dispatch to code the message directly from the subsription ?

That's currently not possible with Rebus.

The reason for this design is that Rebus then only needs to poll one thing: Its input queue.

Why would you like to receive messages directly from a subscription?

[sabbadino]

No particular reason. In a native asb implementation one would pull messages directly from a subscription, but I understand that this does not fit into the rebus architecture.

[mookid8000]

In a native asb implementation one would pull messages directly from a subscription

Unless one wanted to subscribe to multiple things - I would say that the only sensible and broadly applicable topology is the way Rebus does it.

It also closely resembles e.g. how RabbitMQ works, they just use the word "binding" for a subscription.

Actually, I find it rather mysterious that it's even possible to receive messages directly from a subscription - it's as if it's a queue, too.

[sabbadino]

From https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-queues-topics-subscriptions

To receive messages, you create one or more subscriptions to the topic. Similar to queues, messages are received from a subscription

To make a parallel to rabbit , asb topic = rabbit exchange.

Asb subscription bound to topic = rabbit queue bound to exchange

Rabbit binding (fanout, topic, etc)= asb subscription filters.

---

Rebus get the messages from the queue since the subscription has the forwardto property set to the queue name.

https://docs.microsoft.com/en-us/azure/service-bus-messaging/service-bus-auto-forwarding

[mookid8000]

To receive messages, you create one or more subscriptions to the topic. Similar to queues, messages are received from a subscription

That's what they say 😄 but I would not recommend doing that, except in cases where you were really sure that you never wanted to receive messages from anything else.

On the documentation page for the auto-forwarding feature they show this picture:

with the intro wording "You can also use autoforwarding to decouple message senders from receivers."

That's what we're after.

That's a great topology for supporting individual services, where the name of the input queue serves as a form of identifier for the service.