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).
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.
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.
Just bragging. Check out the "Scenarios" section for some words on how real world problems can be solved with some of these building blocks.
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).
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.
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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4