Introduction - rebus-org/Rebus GitHub Wiki

What is Rebus?

Rebus is a service bus implementation, similar in nature to NServiceBus, MassTransit, and Rhino ESB. In fact, it was built from the outset to align with NServiceBus in almost every aspect, in order to allow you (and me) to start out with Rebus and feel safe, because it would always be possible to migrate to NServiceBus if Rebus for some reason fell short (which I don't think it will).

Service bus? Really?

Yes, but it may or may not adhere to your definition of a service bus. You see, the "enterprise service bus" term is severely overloaded, so people mean many different things when they say it.

When I say "enterprise service bus", I'm talking about a thing that in a transparent and distributed way enables communication between bounded contexts. That is, Rebus is present in your bounded contexts, but your code need not know of the bus nor care whether any other bounded contexts are interacting.

Rebus achieves this with clever usage of messaging and old and proven patterns for exchanging them.

Rebus will do this in .NET, and primarily by using MSMQ, RabbitMQ, SQL Server, or Azure Service Bus as a platform to transport messages. Work is ongoing however, to get Rebus working in the same reliable manner with additional transport implementations, which will allow you to use e.g. Amazon Simple Queue Service for message queueing, and HTTP/HTTPS to move messages between physical locations or in and out of DMZ.

Technically, what is it?

Rebus is a library that has the RebusBus class as its main component. You create an instance of it, and then you start it. When your application shuts down, you remember to dispose it. Therefore, you must take care of hosting the bus yourself, e.g. in your web application process, in your Windows service process, in your console application, etc.

There's a configuration API available, that helps you instantiate RebusBus in a human-readable and slightly more declarative way than doing the instantiation manually.

Feature list

Just bragging. Check out the "Scenarios" section for some words on how real world problems can be solved with some of these building blocks.

  • common message exchange patterns like point to point, request/reply, publish/subscribe made easy
  • advanced coordination of messages, i.e. process managers (or "sagas" in NServiceBus terminology)
  • timeout manager that allows message delivery to be deferred to the future
  • messages can be transferred using MSMQ, RabbitMQ, Azure Service Bus, SQL Server, and even by using a shared directory in the file system
  • subscriptions, sagas and timeouts can be stored in either Microsoft SQL Server, MongoDB, RavenDB, or PostgreSQL
  • polymorphic message dispatch that allows messages to compose by implementing multiple interfaces and enables handler reuse
  • handler pipeline re-ordering
  • MSMQ queue inspector
  • and more

Non-feature list

These are features that have been consciously left out, and will most likely never be part of Rebus (because you're better off building these things yourself).

  • configuration management - i.e. varying configurations across environments - is not part of Rebus, because Rebus doesn't want to mess with how you're doing this
  • visual service editor - i.e. a GUI where you can paint your architecture with doodles - will not be part of Rebus, because Rebus is very code-centric - if you want a visual overview, I suggest you write a simple app yourself that scans your app.config/web.config files for endpoint mappings and generates a graphical service dependency graph
  • and more ;)

Preconditions

It is assumed that the reader is fairly well-accustomed to .NET development, and knows how to e.g. pull down NuGet packages, put in appropriate using statements, etc.

So what does it look like?

Don't pay attentions to all the fluffy descriptions of what constitutes an "enterprise service bus" - in this case, it's just a messaging library that makes it easy to send messages from one process to another, usually by sending the message without explicitly telling where to deliver it - that part is configured elsewhere.

Ignoring configuration code, your Rebus code (in a publisher endpoint) might look like this:

await bus.Publish(new ImportantThingHappened
{
    Id = 139,
    Importance = Importance.High
});

if you want to make information about important things happening available to the world, and like this (in a subscriber endpoint):

public class ImportantThingHappenedHandler : IHandleMessages<ImportantThingHappened>
{
    public async Task Handle(ImportantThingHappened message)
    {
        var id = message.Id;
        var importance = message.Importance;

        // do stuff in here
    }
}

in order to be able to handle ImportantThingHappened events, and than at startup in order to begin subscribing to this particular message type:

await bus.Subscribe<ImportantThingHappened>();

This is of course a silly example, so please check out the Scenarios section of the wiki front page for some real-world usage scenarios.