Routing

"Routing", eh? Routing with the NServiceBus/MassTransit/Rhino ESB/Rebus class of service bus implementations is pretty simple: Either you do it manually, e.g. like so

bus.Send("some.destination.queue.name", someMessage);

and

bus.Subscribe<TSomeEvent>("some.destination.queue.name");

which is NOT the preferred way of routing things. This is mainly due to two facts:

1 Hardcoding message destinations makes your system unflexible. 1 Your application should not care about these things anyway - routing should be implemented by the bus.

How do you use the bus to route things?

Simple: Just use the overloads on IBus that don't take a destination endpoint as a parameter, e.g. like so:

bus.Send(someMessage);

and

bus.Subscribe<TSomeEvent>();

So how does the bus route things?

Rebus relies on the very simple IDetermineDestination interface in order to route messages - the interface provides a simple mapping from a message type to an endpoint name.

Rebus will look up a destination using this mechanism when you bus.Send messages, and when you bus.Subscribe to messages.

A word about publishing messages

Don't confuse this kind of routing with publishing - when you bus.Publish, the message will be sent to whoever has subscribed, provided that your configured subscription storage (the implementation of IStoreSubscriptions that you're using) has persisted the subscriptions as it should.

A word about replying to messages

Another thing is when you reply to a message, i.e. inside a message handler you bus.Reply - in this case, the reply will be sent to the return address as specified inside the message you're currently handling.

The duality

When you think of it, the messaging patterns Request/Reply and Publish/Subscribe are actually very much alike - only, it should have been called Subscribe/Publish, because that's the order of the sequence.

You can read and ponder some more here and here.