Sounds to me like you want to do something like this:
Configure.With(yourFavoriteContainer)
.Transport(t => t.UseRabbitMq(...)
.ManageSubscriptions()) //< BAM!!1
.(...)
which lets Rebus take advantage of the fact that Rebus' RabbitMqMessageQueue
implements IMulticastTransport
, which in turn turns handling of all things multicast over to Rabbit.
It's just important that all of your Rabbit-enabled Rebus endpoints agree on letting Rabbit ManageSubscriptions
- otherwise, weird stuff might happen ;)
It means that
- when you
bus.Subscribe<SomeEvent>
, you bind a topic with the type name to the subscriber's input queue - e.g."SomeEvent.SomeNamespace" -> myInputQueue
- publishers publish events on a topic that is the type name - e.g.
"SomeEvent.SomeNamespace"
- message ownership is disregarded when subscribing
- Rabbit will do the heavy lifting when doing multicast (which is what Rabbit users are mostly doing)
If you require even more flexibility, you can even take responsibility of deciding the topic to publish to for each .NET type, like so:
Configure.With(yourFavoriteContainer)
.Transport(t => t.UseRabbitMq(...)
.ManageSubscriptions()
.AddEventNameResolver(type => DecideTopic(type))
.(...)
You can add multiple event name resolvers if you want - they will be run in sequence until one of them returns something that is not null
.
Does it make sense?