Routing subsystem is responsible for finding destinations for the messages. In most cases the sending code should not care about the destination of the message being sent:
var configUnicastBus = configure.UnicastBus(); var bus = configUnicastBus.CreateBus().Start(); var myMessage = new MyMessage(); bus.Send(myMessage);
Based on the type of the message the routing provides the destination address.
As described here, NServiceBus distinguishes several types of messages. Command messages are always routed to a single logical endpoint.
Command routing can be configured in a configuration section.
Each entry in the collection has to specify the assembly where the messages are defined. In addition to that, a type name or the namespace name can be also specified for additional filtering.
Messagesattribute can be used instead of
<configuration> <configSections> <section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core"/> </configSections> <UnicastBusConfig> <MessageEndpointMappings> <add Assembly="MyMessages" Endpoint="Sales" /> <add Assembly="MyMessages" Namespace="PriorityMessages" Endpoint="Preferred" /> <add Assembly="MyMessages" Type="MyMessages.SendOrder" Endpoint="Sending" /> </MessageEndpointMappings> </UnicastBusConfig> </configuration>
The per-namespace routes override assembly-level routes and the per-type routes override both namespace and assembly routes.
In specific cases, like sending to self or to a particular queue (e.g. for integration purposes), the routing configuration can be overridden when sending a given message. Refer to documentation on sending for further details.
Events can be received by multiple logical endpoints, however even in case of scale out each event will be received only by one physical instance of any logical subscriber. Before the message is published and delivered, the subscriber has to express its interest in a given type of event.
Multicast transports support 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.
EndpontOrientedTopologyrequires publishers names to be configured.
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 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.
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
MessageEndpointMappings routing configuration can take advantage of message inheritence: base types "inherit" routes from the derived types (opposite to member inheritence in .NET). If both
EventTwo inherit from
BaseEvent, when subscribing to
BaseEvent the subscription messages are sent to publishers of both
Replies are always routed based on the initial message
ReplyTo header regardless of replier's routing configuration. Only the sender of the initial message can influence the routing of a reply. Refer to documentation on sending for further details.