Different bus modes - rebus-org/Rebus GitHub Wiki

Since Rebus can be configured in many ways, there's probably a few modes of operation that you should take into consideration when you determine your bus requirements.

Two general bus modes

There's two general bus modes:

• Normal
• One-way client

where Normal is a bus that is capable of receiving messages, and a one-way client is only capable of sending messages.

How to configure bus mode

Since the available bus mode ties into the transport, it must be supported by the chosen transport in order to work. This is because a one-way client does not have an input queue, which means that the transport implementation must support that scenario somehow.

If a transport supports one-way client mode, it should support configuration extensions on the form UseTRANSPORTAsOneWayClient(...) in addition to the default UseTRANSPORT(...) style configuration extensions.

For example, with the MSMQ transport, you configure it normally like this:

Configure.With(activator)
    .Transport(t => t.UseMsmq("my_input_queue"))
    .(...)

which means that MSMQ one-way client mode can be configured like this:

Configure.With(activator)
    .Transport(t => t.UseMsmqAsOneWayClient())
    .(...)

Configuration options and one-way clients

Because of the nature of a one-way client, not all configuration options make sense or are applicable in that mode. This picture is complicated further by the fact that the transports might/might not support timeouts and pub/sub messaging :smiley: like persistence ignorance, transport ignorance is about making the code ignorant of whichever mechanism is used under the covers, but it does not always free the developers from having at least a little bit of knowledge about what they're doing.

Since one-way clients are not capable of receiving messages, it does not make sense to configure saga persistence for these types of buses.

Timeouts (i.e. the ability to bus.Defer messages to the future) should either be supported natively by the transport (e.g. as it is with SQL Server, Azure Service Bus, Azure Storage Queues, ...) or be configured to be sent to an external timeout manager like so:

Configure.With(activator)
    .Transport(t => t.UseMsmqAsOneWayClient())
    .Timeouts(o => o.UseExternalTimeoutManager("timeouts"))
    .(...)

Subscription storage can be configured for a one-way client if it should be capable of publishing messages. It will not be able to receive subscribe/unsubscribe requests though, so this only makes sense if the subscription storage is centralized (i.e. subscribers, or a dedicated endpoint, can register/unregister subscribers directly in the subscription storage).