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

This mode isn't completely implemented yet - await issue #102. 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.

TODO: configuration sample

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 input queue address will be supplied as the rebus-return-address header in all sent messages, including the internally used subscription messages (which gets sent when you bus.Subscribe).

TODO: configuration sample

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...?