Friends and acquaintances might know that I’ve spent the last 6 months or so of my pastime, hacking on something I call Rebus. To cut a long story short, I can tell you that I am a happy NServiceBus user who became very sad when NServiceBus went from being free to requiring a commercial license – not because I think NServiceBus isn’t worth spending money on, but because I think it hurts the adoption of NServiceBus.
Speaking for myself, I have already refrained from using NServiceBus in a couple of smaller projects, where it would otherwise have been an awesome addition.
I seriously considered forking the 2.0 version of NServiceBus, which is licensed under Apache v. 2.0, but I was overwhelmed by the sheer size of the project. This led me to re-implement my favorite features of NServiceBus as Rebus, trying to focus and stay lean along the way.
And here it is: Rebus
Rebus – the core – depends on .NET 4 only. And since .NET 4 has MSMQ, ADO.NET, and binary serialization, you get to send and receive messages transactionally and persist your stuff in SQL Server without anything but Rebus core.
3rd party integration (like e.g. MongoDB, NewtonSoft JSON serializer, etc) is provided through small, dedicated add-on projects. This granularity makes it easier to manage your own dependencies.
Update: And since JSON serialization was deemed to be the preferred form of message serialization, it has been ILMerged into Rebus core since right after this announcement. Therefore, JSON serialization is included in the box and is the default.
There’s currently two ways to get started with Rebus:
RebusBusmanually, filling in the ginormous constructor with implementations for how you want the bus to run.
- Use the configuration API.
Let’s try the configuration API – with the following snippet of XML in your
<?xml version="1.0" encoding="utf-8" ?>
<section name="log4net" type="log4net.Config.Log4NetConfigurationSectionHandler, log4net"/>
<section name="rebus" type="Rebus.Configuration.RebusConfigurationSection, Rebus" />
<rebus inputQueue="myService.inputQueue" workers="5">
<add messages="AnotherService.Messages" endpoint="anotherService.inputQueue"/>
and the following piece of code in your app:
var myAdapter = new MyFavoriteContainerAdapter(myFavoriteContainer);
.Logging(c => c.Log4Net())
.DetermineEndpoints(c => c.FromRebusConfigurationSection())
.Transport(c => c.UseMsmqAndGetInputQueueNameFromAppConfig())
.Serialization(c => c.UseJsonSerializer())
// IBus is in the container now :)
you should be up and running with a Rebus bus.
That was a small teaser – there’s more blog posts on the way, I promise 😉
So, what’s the state of this?
Well, that’s actually the whole point of this blog post – I’m currently in a situation where I really feel like putting Rebus to some serious use, but I cannot justify foisting it on a client until I have a big project to prove its worth. And I cannot prove its worth in a big project until I have a client I can fob it on.
That’s where you come in! 🙂
- You’re building something – it’s not totally mission critical, as in human lives depend on it, but it’s still something.
- You want some nifty service bus technology to help you build a loosely coupled architecture that will allow your project to flex and bend and integrate with stuff in many years to come.
- You wanted to use NServiceBus because it’s cool, but you can’t afford the cost up front.
- You’re reading this blog post, or someone you know read it and is now telling you about it…
If that’s you, then you should meet Rebus!
- Absolutely free to use and abuse.
- Very very similar to NServiceBus, allowing you to migrate to NServiceBus some time in the future if Rebus is not enough for you.
- Pretty simple.
- Comes with unlimited[1. Within reason, of course – I have a day job, a wife, and two kids, so I’m not answering emails 24/7 – but I’ll go to great lengths to help you get a smooth adoption of Rebus – because that’s just how much I care :)] support from its author.
- Did I mention it was free?
A match made in heaven?
If you have the slightest bit of interest in what I’m suggesting, please contact me – either via email or on Twitter – and then we’ll talk about what Rebus can do for you. Oh, and please don’t hesitate to contact me – even if you’re NOT planning on using Rebus, I’d like to know why you picked NServiceBus, MassTransit, or Rhino Service Bus instead.
If you’re just eager to try it out, feel free to
Install-Package -Pre one or more of Rebus’ NuGet packages.