Feature Request: IBusRegistry.Send(SomeCommand) to support Configurable Module Distribution

[jamshally]

Feature Request

It could be very useful if the IBusRegistry had a Send(SomeCommand) function, that would proxy a given command to the correct Rebus Instance (the one with the Routing configured for the Command).

Use Case - Configurable Module Distribution

This would easily allow a modular system, through configuration only, to be deployed in arbitrary combinations of co-hosted and remotely hosted (distributed) services. For example, the following hosting modes could easily be achieved:

1. Monolithic: all Commands routed to a Rebus Instance with an In Memory Transport
2. Micro-Service: all Commands routed to a Rebus Instance with a network based Transport
3. Polylithic (broken into multiple small Monoliths):
   • Commands with co-hosted Command Handlers routed to a Rebus Instance with an In Memory Transport
   • Commands with distributed Command Handlers routed to a Rebus Instance with a network based Transport

The application code would not need to care about where the various system modules are hosted. It can simply Send Commands (via the IBusRegistry) and they will be routed to the correct location (local or networked).

This approach would be massively helpful in supporting scenarios such as:

• Gradual System decomposition: for example, where a Monolithic system is being gradually decomposed over time
• Environments Specific Module Distribution: for example
  • Local, and sandbox development environments that have low resource demands can be easily configured as Monoliths
  • Production environments with high resource demands can be configured as distributed services

Notes

• SendLocal?: if a Command could somehow be routed to SendLocal or Send via configuration, then a single bus could be used, and the 'Configurable Module Distribution' goal still be achieved.
• Multi-Container Scenarios: it would be useful to benefit from the IBusRegistry even in scenarios where multiple Rebus Instances were configured in discrete Container-Instances. I suppose this would be possible by simply registering an instantiated concrete instance of an IBusRegistry across all Container Instances

Thanks for this work on this library - the Rebus.ServiceProvider project is a great addition to the Rebus ecosystem - and the documentation page covering the various Rebus instance and lifecycle options has been massively helpful.

[mookid8000]

Wouldn't this be fairly easy to implement manually by keeping all routing information in a registry somewhere and then

• use the registry during configuration to configure routing on each Rebus instance
• look up relevant bus instance in an IBusRegistry extension method

thus keeping this entirely separate from Rebus/Rebus.ServiceProvider?

[jamshally]

@mookid8000 - thanks for your reply. Good points. I see the benefit of keeping this capability segmented from the IBusRegistry (single responsibility principle and all that). I think I will try this approach you suggested and leverage an extension method. I'm happy to share/submit if I come up with something useful and reusable.

Side note - is is possible to query/inspect a Rebus Instance for its existing routes (which would avoid the need to develop and maintain a separate RouteRegistry).

Cheers

[mookid8000]

(..) is is possible to query/inspect a Rebus Instance for its existing routes (which would avoid the need to develop and maintain a separate RouteRegistry)

It isn't, which is why I suggest you implement this the other way around: Populate your own model of which bus instances should be available and which messages should be sent using those instances, and then use that model to configure the bus instances and actually select which bus instance should be used to send/publish each message.

I hope that made sense 🙂 Let me know if you need any more suggestions