Request for multiple Transport namespaces

[jkhendrix]

This issue is similar to https://github.com/Particular/NServiceBus.WindowsServiceBus/issues/10

In my scenario, I have the need to connect to multiple NSB/RabbitMQ services from a single central application. Security policies prevent at least one of the of the remote NSB endpoints from being able to communicate via the Gateway http fallback protocol. A proposed solution to the above issue was to namespace Transport connection strings, which could be applied to this scenario also:

<connectionStrings>
  <add name="NServiceBus/Transport" connectionString="host=default-hostname;virtualhost=vhost;username=...;password=..." />
  <add name="NServiceBus/Transport/NamespaceA" connectionString="namespaceA-hostname;virtualhost=vhostA;username=...;password=..." />
  <add name="NServiceBus/Transport/NamespaceB" connectionString="namespaceB-hostname;virtualhost=vhostB;username=...;password=..." />
  <add name="NServiceBus/Transport/NamespaceC" connectionString="namespaceC-hostnmae;virtualhost=vhostC;username=...;password=..." />
</connectionStrings>

Additionally, being able to make the runtime decision of which transport to use via the .Send() method would be extremely useful. This might be accomplished by embedding the namespace in the destination address of .Send(), or by additional optional parameters to specify the Transport namespace.

But why stop there? What about allowing this central application to be able to consume subscriptions to objects published from each of the Transport namespaces?

[andreasohlund]

This sounds a bit like the feature we have in the SqlServer transport where we can select the database to connect to based on a similar convention like you describe.

That said, is there a reason why you can handle this on the broker level by connecting them to each other using the native support in rabbitmq?

[jkhendrix]

If you are talking about Federated Exchanges and Queues of Rabbit, then I believe there are similar reasons to why we can't use the NServiceBus Gateway.

I think this might be an accurate drawing of how connections would have to be initiated in order to facilitate federated queues for 2-way communication. In this drawing, "InQ" and "OutQ" are the federated queues (since I think they are configured as "downstream" connecting to "upstream"). The App would write to "FQ1", but since security policies prevent the federated "InQ" from connecting to the RMQ1 server, the message would never get delivered.

Granted I have not tried to implement this yet, so my understanding of how these queues are initiated only come from reading the Rabbit documentation ... but I strongly suspect that either my DMZ inbound or outbound messages would be lost.

If I have some time later this week I'll try an experiment to see which it is.

[jkhendrix]

Well, technically federated exchanges might have worked (if Security could have been persuaded), but that just got squashed by Operations who will not support federated exchanges/queues for Rabbit in all the environments which need to be connected. Their justification seems to be that there is nothing in the Rabbit protocols which limits the number/location of connections in an application.

Ahhh the politics of programming. A developer trapped in the no-mans land between requirements and capabilities.

It seems that my 2 possibilities are (1) support of multiple transports for Rabbit in NServiceBus, or (2) a collection of applications, each dedicated to a single NServiceBus/Rabbit environment, who coordinate over some form of inter-process communication. If there is a 3rd, I'd love the input.

[andreasohlund]

Nothing comes to mind :(

@fhalim @scottmeyer @thirkcircus what's your take on this?

[scottmeyer]

@jkhendrix would you not have the same access security problems for transports addressed in the DMZ? Could you utilize flow control in RabbitMQ to limit the number of connections to a server and convince operations to allow federation across the DMZ?

I could see the use case for sending to multiple transport addresses in limited cases, but they also seem to be solvable by federation.

[jkhendrix]

I would not expect DMZ issues with standard Rabbit transports as the tcp connection is initiated from the client application rather than from within the DMZ itself. As long as all connection requests are "to" the Rabbit server in the DMZ, we should be golden.

I agree that federation would likely solve the problem at the cost of some manual configuration, but I'm afraid I've already lost that fight. Our customers security requirements are quite strict, and while there may be no obvious threat in punching a very application-specific hole thru a firewall, security audits would likely hang me out to dry because of it. Politics. Why didn't they teach that in engineering school?

I should note that multiple Rabbit transports isn't an immediate need on my part ... but I can see the writing on the wall. 3-6 months down the road it (or a lot of complex code to simulate it) will be required in my environment. While I'm not afraid of the complex code, if there is an "Easy" button available, I'll reach for it every time.

[ramonsmits]

Multi-transport seems like a feature that should be considered independent from NServiceBus.RabbitMQ