Message routing

Component: NServiceBus
NuGet Package NServiceBus (4.x)
Standard support for version 4.x of NServiceBus has expired. For more information see our Support Policy.

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 configUnicastBus = Configure.With().UnicastBus();
var bus = configUnicastBus.CreateBus().Start();

var myMessage = new MyMessage();
bus.Send(myMessage);

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

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 via MessageEndpointMappings.

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.

The Azure Service Bus EndpointOrientedTopology requires publisher names to be configured.

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 in a configuration section by registering publishers for a given type, namespace or assembly containing events.

In the UnicastBusConfig/MessageEndpointMappings configuration section, publishers are registered in the same way as the command destinations are defined. If a given assembly or namespace contains both events and commands, the mapping will recognize that fact and configure the routing correctly (both commands and subscribe messages will be routed to the destination specified in the Endpoint attribute).

MessageEndpointMappings routing configuration can also take advantage of message inheritance: base types "inherit" routes from the derived types (opposite to member inheritance in .NET). If both EventOne and EventTwo inherit from BaseEvent, when subscribing to BaseEvent the subscription messages are sent to publishers of both EventOne and EventTwo.

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.

Samples

  • Publish/Subscribe
    Publish/Subscribe, fault-tolerant messaging, and durable subscriptions.

Related Articles


Last modified