It’s been long underway, as I started developing it almost immediately after starting the Rebus project, so it’s almost as old as Rebus itself.
I originally started just out of curiosity, and because I wanted to learn about the AMQP model, but after having convinced a rapidly growing Aarhus trading firm to use Rebus for their enterprise messaging needs, and they had some bad experiences with MSMQ as their messaging infrastructure across VLANs, I was encouraged/forced to take it more seriously… and now… finally… I’m ready to announce that RabbitMQ is an official Rebus transport!
What does that mean?
It means that Rebus will exhibit the same guarantees with regards to atomiticy and transactionality of message exchange with RabbitMQ as it will with MSMQ! At first I didn’t think this was achievable, but it seems RabbitMQ has just enough transactional capability and Rebus requires sufficiently little of its queueing infrastructure, that everything just ends up working perfectly!
It also meant that we – the other day when I did a Rebus code camp with the local .NET user group, and some people had trouble making the MSMQ of their ridiculously locked-down work laptops talk to my MSMQ – could switch from MSMQ to Rabbit by going from
|
1 2 3 |
Configure.With(adapter) .Transport(t => t.UseMsmqAndGetInputQueueNameFromAppConfig()) .CreateBus().Start(); |
to
|
1 2 3 |
Configure.With(adapter) .Transport(t => t.UseRabbitMqAndGetInputQueueNameFromAppConfig("amqp://192.168.1.17")) .CreateBus().Start(); |
and everything would work, even for those who were struggling with their frigid laptops… pretty cool, huh?
There are still differences, however – in the next post I’ll go through some of the reasons why you might choose one over the other…
One thought on “New officially supported Rebus transport: RabbitMQ”