Message routing

The routing subsystem is responsible for finding destinations for messages. In most cases, the code which sends messages should not specify the destination of the message being sent:

var endpointInstance = await Endpoint.Start(endpointConfiguration);
var message = new MyMessage();
await endpointInstance.Send(message);

Based on the type of the message, the routing subsystem will provide the destination address.

NServiceBus routing consists of two layers, logical and physical. Logical routing defines which logical endpoint should receive a given outgoing message. Physical routing defines to which physical instance of the selected endpoint should the message be delivered. While logical routing is a developer's concern, physical routing is controlled by operations.

Broker transports handle the physical routing automatically. Other transport might require specific configuration. See also MSMQ Routing.

Command routing

As described in messages, events and commands, NServiceBus distinguishes between these kinds of messages. Command messages are always routed to a single logical endpoint.

Command routing can be configured in code. The routing API is attached to the transport configuration object because some routing APIs are transport-specific. The routes can be specified at assembly, namespace or specific type levels.

var routing = endpointConfiguration.UseTransport(new TransportDefinition());

routing.RouteToEndpoint(
    assembly: typeof(AcceptOrder).Assembly,
    destination: "Sales");

routing.RouteToEndpoint(
    assembly: typeof(AcceptOrder).Assembly,
    @namespace: "PriorityMessages",
    destination: "Preferred");

routing.RouteToEndpoint(
    messageType: typeof(SendOrder),
    destination: "Sending");

The routing engine prevents ambiguous routes so if route information comes from more than one source (e.g. code API and configuration file) the user has to make sure the type specifications do not overlap. If they do overlap, an exception will be thrown preventing the endpoint from starting up.

Per-namespace routes override assembly-level routes while per-type routes override both namespace and assembly routes.

Overriding the destination

In specific cases, like sending to the same endpoint or to a specific queue (e.g. for integration purposes), the routing configuration can be overridden when sending a given message. Refer to documentation on sending messages for further details.

Event routing

When events are published, they can be received by multiple logical endpoints. However, even in cases where those logical endpoints are scaled out, each event will be received by only one physical instance of a specific logical subscriber. It is important to note that before the event is published and delivered, the subscriber has to express its interest in that event by having a message handler for it.

Native

Multicast transports support the Publish-Subscribe pattern natively. In this case the subscriber uses the APIs of the transport to create a route for a given subscribed message type.

Message-driven

Other transports do not support Publish-Subscribe natively. These transports emulate the publish behavior by sending message to each subscriber directly. To do this, the publisher endpoint has to know its subscribers and subscribers have to notify the publisher about their interest in a given event type. The notification message (known as the subscribe message) has to be routed to the publisher.

Subscribe message routing can be configured using code API

var routing = endpointConfiguration.UseTransport(new TransportDefinition());

routing.RegisterPublisher(
    assembly: typeof(OrderAccepted).Assembly,
    publisherEndpoint: "Sales");

routing.RegisterPublisher(
    assembly: typeof(OrderAccepted).Assembly,
    @namespace: "PriorityMessages",
    publisherEndpoint: "Preferred");

routing.RegisterPublisher(
    eventType: typeof(OrderSent),
    publisherEndpoint: "Sending");

Similar to the command routing, more specific publisher registrations override less specific ones. The registrations must be unambiguous.

Reply routing

Reply message are always routed based on the ReplyTo header of the initial message regardless of the endpoint's routing configuration. Only the sender of the initial message can influence the routing of a reply. Refer to documentation on sending messages for further details.

Make instance uniquely addressable

When using a message broker, multiple instances of a scaled-out endpoint are consuming from the same address via the competing consumer model.

To address specific instances of a scaled-out endpoint, instances can be configured to be individually addressable by providing a unique discriminator to each instance:

The following queues will be created for endpoint Sales configured with discriminator B:

• Sales
• Sales-B

var endpointConfiguration = new EndpointConfiguration("Sales");
endpointConfiguration.MakeInstanceUniquelyAddressable("B");

Uniquely addressable instances are used for callbacks but can be used for other purposes like data partitioning with processing affinity or a form or processing prioritization.

var options = new SendOptions();
options.RouteToSpecificInstance("B");
endpointInstance.Send(new MyMessage(), options);

Recommendations:

• Avoid hard-coding the discriminator when sending messages.
• Avoid using MakeInstanceUniquelyAddressable for priority queues.
• Consider using routing extensibility for routing to specific instances.