RabbitMQ transport

Routing

As Rebus was initially built with MSMQ in mind, which (at least in its traditional incarnation) is a very simple point-to-point channel, the multicast capabilities (i.e. the simple type-based pub/sub mechanism) is implemented as a layer on top of said channels.

You can read more about the subject in the Rebus routing page.

Rabbit routing

Relying only on Rebus to implement all routing works fine with RabbitMQ. But you have another option: let RabbitMQ take care of everything multicast.

You can do that by configuring the Rabbit transport like so:

Configure.With(...)
    .Transport(t => t.UseRabbitMqAndGetInputQueueNameFromAppConfig()
                     .ManageSubscriptions())
    (...)

which will change Rebus' behavior in the following places:

• When you subscribe to a message type, Rebus will bind the topic with the full .NET type name to the service's input queue instead of sending a SubscriptionMessage to the publisher.
• When you publish a message, the message will be sent with a topic that is the full .NET type name of the message instead of using IStoreSubscriptions to look up who subscribed.

Effectively, this means that RabbitMQ is your subscription storage, which also makes it easier to set up these things - i.e. you don't need to think about having subscription storage for each publisher.

It probably also means that some things don't make sense - e.g. explicitly subscribing to something somewhere (by using the explicitly routed subcription operation, advancedBus.Routing.Subscribe<TEvent>(someEndpint)) doesn't make sense, because all subscriptions are global.