Endpoint1 and Endpoint2 are doing request/response, what I see in the Azure portal after starting the solution and running it is what I would expect to see. Two queues created, one for ep1 and one for ep2
After reading through these three blog posts by @danielmarbach:
I understand the reason for using message forwarding for the subscriptions for Endpoint 3 and Endpoint 4 (both these ep’s handle the same published event, Event1)
What I’m confused about is why did NSB create a subscription for ep1 and ep2? Neither of those ep’s are handling or publishing an event.
Ep1 is sending the Message1 command, Ep2 is handling Message1 and then sending Message2 back to ep1 using .Reply. Message2 is an IMessage. Ep1 is handling Message2.
Are those subscriptions actually being used by ASB to handle the routing of Message1 and Message2 between ep1 and ep2?
The reason I’m asking, is I’m currently working on a project where I’m using ASB directly, and I’m trying to wrap my head around not only the AMQP protocol, but also the concept of Topics, Subscriptions and Rules.
Never having worked directly against an AMQP-style broker before, I’m realizing how spoiled I’ve been using NSB, as working with commands, events and handlers is such a nicer, higher-level abstraction than having to get down into the weeds of ASB’s topology and API.
An Azure Service Bus subscription entity is preparation by NServiceBus endpoint to receive messages should it subscriber to any. The act of subscribing to an event is translated into Azure Service Bus rules entity creation (which is named after the event type it subscribes to). Each endpoint generated the subscription entity in the anticipation of NServiceBus subscriptions that will follow. There might be none. In that case, the subscription entity is a no-op with a default rule that doesn’t receive any messages.
The subscription is always created but in this cause it would only contain the default rule ("$default) and no other rule because the endpoint doesn’t subscribe to any event. The subscription manager which later adds the rule is assuming the subscription is there and it can just add the rules.
It would not create the subscription if you disable the installers (in the samples the installers are always on)
That’s correct. There’s always a single message receiver per endpoint’s input queue that is handling as many concurrent incoming messages as the endpoint’s concurrency level is set to.
Only conceptually. The transport’s MessageReceiver is a replacement for SDKs MessageReceivePump. The built into the SDK message pump is intended for as-is usage. The moment any customizations are required, the recommendation is to look into MessageReceiver. Which is what ASB transport is doing.
