Can't subscribe to messages from (or send commands to) queues in different Windows Service Bus namespaces

[CallumHibbert]

As there is only a single Windows Service Bus connection string it is not possible to subscribe to messages from two different Windows Service Bus namespaces:

<connectionStrings>
  <add name="NServiceBus/Transport" connectionString="Endpoint=sb://myHostName/NamespaceA;StsEndpoint=https://myHostName/NamespaceA:9355;RuntimePort=9354;ManagementPort=9355" />
</connectionStrings>

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Assembly="MyAssemblyA" Type="MyTypeA" Endpoint="queueInServiceBusNamespaceA" />
    <add Assembly="MyAssemblyB" Type="MyTypeB" Endpoint="queueInServiceBusNamespaceB" />
  </MessageEndpointMappings>
</UnicastBusConfig>

In the above example the two queues "queueInServiceBusNamespaceA" and "queueInServiceBusNamespaceB" are in different Windows Service Bus namespaces but there can only be one Windows Service Bus connection string. So in the above example, the "queueInServiceBusNamespaceB" queue could not be connected to.

There the same problem if you want to send commands to queues in different Windows Service Bus namespaces.

Is it possible to move the connection string to the message endpoint mappings or reference connection strings from the message endpoint mappings?

[mauroservienti]

Hi Callum,

interesting scenario, I suppose it is not supported at all by NSB, could you expand a bit on the requirement you are facing? [.m] .m

[CallumHibbert]

The scenario is that I have several domains/BCs, each domain/BC has several autonomous components that manifest themselves as NServiceBus endpoints.

For example, I have a "Payments" domain inside of which I have Authorisation, Billing and Fraud services, each of these being an NSB endpoint. I will also have an Orders domain which will have a number or services. I would like to separate the queues for services in each domain by putting them in different Windows Service Bus namespaces. All the queues for services in the Payments domain go into one Windows Service Bus namespace and all the queues for services in the Orders domain go into another Windows Service Bus namespace. This makes management somewhat easier and also important with respect to security as ACLs are controlled at the Windows Service Bus namespace level.

Unfortunately one of the Payment services is going to be interested in some sort of order accepted event from a service in the Orders domain. If these queues are in separate Windows Service Bus namespaces then the Payments service cannot subscribe to an event from the Orders service for the reasons described above.

There are obviously going to be lots of other examples of services exchanging events. With the Windows Service Bus transport functionality as is, I am going to have to put all of my queues for all of my services for all of my domains in a single Windows Service Bus namespace so that pub/sub can happen. This doesn't seem right.

[CallumHibbert]

It's a bit similar to this one: https://github.com/Particular/NServiceBus.Azure/issues/35

[CallumHibbert]

This issue is conceptually similar to this one: https://github.com/Particular/NServiceBus/issues/1116

You could maybe do something like:

<UnicastBusConfig>
  <MessageEndpointMappings>
    <add Assembly="MyAssembly" Type="MyTypeA" Endpoint="ep1" />
    <add Assembly="MyAssembly" Type="MyTypeB" Endpoint="ep2@NamespaceA" />
    <add Assembly="MyAssembly" Type="MyTypeC" Endpoint="ep3@NamespaceB" />
  </MessageEndpointMappings>
</UnicastBusConfig>

<connectionStrings>
  <add name="NServiceBus/Transport" connectionString="Endpoint=sb://...;StsEndpoint=...;RuntimePort=9354;ManagementPort=9355" />
  <add name="NServiceBus/Transport/NamespaceA" connectionString="Endpoint=sb://...;StsEndpoint=...;RuntimePort=9354;ManagementPort=9355" />
  <add name="NServiceBus/Transport/NamespaceB" connectionString="Endpoint=sb://...;StsEndpoint=...;RuntimePort=9354;ManagementPort=9355" />
</connectionStrings>

Use the "@..." suffix for each endpoint to point to the correct connection string e.g. "@NamespaceA" points to connection string "NServiceBus/Transport/NamespaceA".

You could have a "default" connection string (i.e. "NServiceBus/Transport") for retry, timeout queues. The default could also apply when an endpoint is missing the "@..." suffix ("ep1" in the above example).

Thoughts?

[CallumHibbert]

This looks like it could be related too: https://github.com/Particular/NServiceBus.Azure/issues/92

[jkhendrix]

I have a similar need, except I need to connect to multiple RabbitMQ transports. Using the gateway won't work since at least one of the target services is running in a production cage and thus prevented from initiating http connections back to the company intranet.

If the SqlTransport solution above were committed, would it also automagically apply to other transports? Like Rabbit?

[andreasohlund]

@jkhendrix can you open up a issue on the rabbit transport for the scenario above?