Different bus modes

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.

One-way client mode

With MSMQ, you can run Rebus in the so-called one-way client mode. In this mode, the bus doesn't have its own input queue - therefore, it is capable only of sending messages.

This mode can be useful e.g. in systems where the web tier needs to send commands to application servers, but there's no need for the web tier to receive replies of any kind.

It follows from this that the bus cannot subscribe to anything either. It is allowed, however, to add a rebus-return-address header to a message and point to someone else, which will cause the recipient to reply to that someone.

An example configuration might look like this:

Configure.With(adapter)
    .Transport(t => t.UseMsmqInOneWayClientMode())
    (...)

Server

This is the simplest full-duplex mode of the bus. In this mode, the bus needs an input queue and therefore also an error queue.

The server's input queue address will be supplied as the rebus-return-address header in all sent messages, including the internally used subscription messages (which get sent when you bus.Subscribe).

For example:

Configure.With(adapter)
    .Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig())
    (...)

In this case, we tell the configuration API to pick up the input queue name from the application's app.config. Therefore, you must also supply at least the following tiny bit of XML in your app.config:

<configSections>
    <section name="rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" />
</configSections>

<rebus inputQueue="inputQueueName" errorQueue="errorQueueName" />

Publisher

The publisher mode covers the fact that the bus can handle the internally used subscription messages, and thus it can bus.Publish events as well.

A publisher should have some kind of persistent subscription storage (unless you're really really aware of what you're doing), otherwise subscribers might get dropped in the event of a publisher restart.

TODO: configuration sample

Process Manager

The process manager is a bus that can contain sagas. Sagas should most likely also be stored somewhere persistent, but it's entirely legal to choose the in-memory saga persister if your sagas are very short-lived and don't need to survive restarts.

TODO: configuration sample - and maybe think of a better name? I really wanted to call it "Raconteur", but maybe that's a little too pretentious...?