Allow control over the proxy name used for an endpoint

[davecluderaythinventory]

Problem

It is not possible to control the name of the proxy for an endpoint. This means that properly routing messages is not possible in some scenarios.

Our topology

We want to route messages between endpoints in two Azure Service Bus namespaces, as follows:

On the right-hand side, there are three distinct endpoints, in different namespaces, but all with the same name.

It's not possible to bridge more than one of these endpoints with the shared namespace on the left-hand side, because the proxy queue names would collide.

Ideally, we would like to have a way to configure an alias name for the proxy queue, for example: other-endpoint.ci, other-endpoint.qa etc.

This would allow us to bridge between all endpoints with no ambiguity.

Proposed feature

Introduce a way to specify an alias for each endpoint. The proxies in other transports would then all be created with the specified alias. For example:

// Register the three endpoints with an alias...
ciTransport.HasEndpoint("other-endpoint", alias: "other-endpoint.ci");
qaTransport.HasEndpoint("other-endpoint", alias: "other-endpoint.qa");
uatTransport.HasEndpoint("other-endpoint", alias: "other-endpoint.uat");

Additional Context

No response

[tmasternak]

Hi @davecluderaythinventory,

Could you share a bit more information on your use case? Specifically:

• Would all the endpoints on the left side of your diagram have the same prefix/suffix i.e. would it be enough if the prefix/suffix was configured per transport and not per endpoint?
• Are you handling pub-sub with the bridge?

Regarding:

It's not possible to bridge more than one of these endpoints with the shared namespace on the left-hand side, because the proxy queue names would collide.

What do you mean by "collide"?

[davecluderaythinventory]

Thanks @tmasternak - answers below:

Would all the endpoints on the left side of your diagram have the same prefix/suffix i.e. would it be enough if the prefix/suffix was configured per transport and not per endpoint?

Yeah everything on the left-hand side is in the same transport, so the names have got to be unique on the left-hand side. Being able to specify the names per-transport would be perfectly fine, and even give a bit more flexibility.

Are you handling pub-sub with the bridge?

Yes, some of it is commands, but we do need two-way pub/sub over this bridge as well.

What do you mean by "collide"?

I just mean that, because the endpoint names are all the same on the right (even though they re on different transports), they cannot be proxied on the left without giving the queues/subscriptions unique names. That is my understanding, of course!

[tmasternak]

Thank you for the answer @davecluderaythinventory.

One more clarifying question. On the left side are the three queues treated by the rest of the system (I assume there are more endpoints there) as different logical endpoints?

Is my understanding correct that the commands routing configuration would look something like:

routing.RouteToEndpoint(
    messageType: typeof(SendOrder),
    destination: "other-endpoint.ci");

[davecluderaythinventory]

Hi again @tmasternak, yes the three queues belong to three distinct endpoints, as do the three on the right.

You might see from the naming that we have two teams who have taken different approaches to separating their non-production environments (CI, QA, UAT). On the left, they have been separated by suffixing the endpoint names. On the right, they have been separated by putting them in their own dedicated namespaces.

And yes, the endpoint on the left would be configured to send commands to the alias from the right, as you put in your example.

[tmasternak]

Hi @davecluderaythinventory, once again, thank you for clarifying your scenario.

I can think of two approaches that might work in your scenario:

• Testing if ASB hierarchical namespaces on the left side of the Bridge will match all your requirements. This would require (possibly among other things) changing the naming scheme for environments on the left (from suffix to hierarchy prefix, e.g., env-ci\other-endpoint).
• For each endpoint, add two queues (one on the left, and one on the right side of the Bridge), both having the same name on both sides, e.g., other-enpdoint-ci-forward and configure message forwarding between these new queues and the existing ones.

When it comes to supporting the alias, we will add it to our backlog so that this will be considered for future enhancement releases.

[davecluderaythinventory]

Thanks @tmasternak.

I think the first option is probably not an option for us (it would be disruptive, and I don't expect the bridge as-is would cope with it, since the endpoints on the right would still appear to be the same logical endpoint). Part of what's needed, I think, is a way for the bridge to know that these identically named endpoints on each transport are actually distinct endpoints, not logically the same one.

The second option might be something we could make work in the meantime, though.

[tmasternak]

The second option might be something we could make work in the meantime, though.

I'm glad this sounds like a reasonable workaround. I would be great to hear if you face any problems with this approach.