nServiceBus vs Mass Transit vs Rhino Service Bus vs other?

Question

Just doing some quick spikes into possibly using a messaging system to process files that are in a nicely decoupled work flow system.

What are the pro's and cons that people have found of using each of the above frameworks? What are the advantages of using these versus a hand-rolled MSMQ system with the WCF bindings and/or non-MSMQ solutions??

Muffin

Answer 1

I'd recommend staying away from hand-rolled solutions as there is a bunch of somewhat difficult stuff that needs to be gotten just right - like how transactions are handled, how exceptions cause rollbacks, how to stop rolling back endlessly (poison messages), how to integrate with long-running workflows so that the state management boundaries line up, and more.

You will probably want some kind of durable/transactional messaging infrastructure, so not using MSMQ you'd be left with Service Broker on the Microsoft platform, or some other alternative like ActiveMQ. MSMQ has the benefit of already being installed on all Windows machines, as opposed to Service Broker which isn't.

In terms of choosing between NServiceBus, Mass Transit, and Rhino Service Bus - this Stackoverflow answer comparing NServiceBus to MassTransit would be a good place to start..

In our 3.1 release, we're introducing NSB Studio - a set of Visual Studio integrated modeling tools that enable you to model your system at a higher level of abstraction and have much of the configuration and initialization of NServiceBus be done for you automatically. I'd say that this really tips the scales in favor of NServiceBus.

Disclaimer: I am the author of NServiceBus.

Trommel

Can you elaborate on "what kind of taste you prefer" means? What are some of the more noticeable differences between your nServiceBus and the other solutions (apart from being the oldest and most stable)? – Muffin

Rhino Service Bus is very Castle centric. If you're not familiar/comfortable with Castle as a core part of your application architecture, you may have some difficulty with it. NServiceBus and Mass Transit or more container agnostic. NServiceBus comes with an "application server" that handles hosting your code as well as changing active infrastructure implementations (like in-memory, MSMQ, & DB) as you transition your system from dev to test to prod. It also comes with unit testing facilities for your message handling logic & long-running processes. I don't believe that MassTransit has these. – Trommel

It's probably worth noting that Udi is the AUTHOR of NServiceBus, and so his opinion may be a little biased here. :) Having said that, I completely agree, and would advocate the use of NServiceBus for the same reasons he has done. – Anear

@skb: agreed! Udi, you should really give some kind of disclaimer when answering nservicebus questions, particularly ones like this! – Unstuck

I'm still getting used to the fact that people are now discovering NServiceBus who do not know that I created it – Trommel

@Alex: People have to eat, and the fact they charge for the license doesn't make the answer any less valid. Still, it's quite expensive so I'll likely select an open source alternative (if you publish the source code without a license to freely use that source code, it may as well be closed-source). – Deepsea

@UdiDahan: How is nServiceBus "open source"? Publishing the source code without a license to use it does nothing for the spirit of open source, which is sharing. I fully support your right to earn a living selling software (I do the same), but I think it would be much more accurate if you did not tout the solution (post 2.0) as open source. – Deepsea

@EricJ. If I'm not mistaken NServiceBus has a public licence provided you also share your source code )Reciprocal Public License 1.5 (RPL1.5) for open source use. as it say on the website). – Graphy

Though arguably true at the time of writing, Microsoft offerings have progressed sufficiently. WCF now supports WS-* and Windows Server AppFabric offer workflow support. May not be up to the level of sophistication as other vendor products - commercial or otherwise but still could be used as a foundation for a "roll-your-own" system. – Algonquian

Answer 2

NServiceBus is a good product but beware of licensing problems. It has a tendency to change it licensing policy as the authors wishes. Take a look for example at old license information.

It could happen that in the middle of you project development you will find out that you have to pay lot's of money for NServiceBus.

Also free version have performance limitations.

MassTransit is absolutely free open source, it has no limitations, and is under Apache 2.0 license.

I have not used Rhino Service Bus.

Bartolome

Actually we will be providing a new license with version 3.1 that will allow you to run it on multiple machines for free (although at lower levels of throughput). – Trommel

MassTransit is your man. It's free; no licensing restrictions. If you can do without a flow designer and can hand roll your own then you can't beat it. It can also sit on top of RabbitMQ and MSMQ has community Azure plugins. MassTranit + RabbitMQ has proven itself to be an excellent stable environment and very quickly lets you get your consumers/producers up and running. – Paroxysm

Also consider EasyNetQ (simple wrapper around rabbitMQ) Suprised UDI doesn't weigh in more on discussions with suggestions 4 good alternatives 2 nServiceBus? What I mean. help folk on the messaging journey at the early stages. There r many good simple (free) ways 2 get started; doesnt really matter what you use as long as it's easy and ideally free; (free to play, and free to implement for real, and free to change as well later) Once you're growing you'll develop ur own list of concerns; at that point a more mature products be an easy decision, with easy cost justfications, e.g. nservicebus. – Passe

As of MassTransit 4.0 MSMQ is no longer supported (masstransit-project.com/MassTransit) – Accumulation

Answer 3

An update to the state of Rhino vs NServicebus:

http://www.infoq.com/news/2012/04/nservicebus3-0

InfoQ to Ayende: You have previously written a service bus for .NET yourself, namely the Rhino Service Bus. Should users of Rhino Service Bus now reconsider and move to NServiceBus?

Ayende: I built Rhino Service Bus around 2008. I built it mostly because I wasn't happy with the state of the other service buses at the time. I have had different concerns and direction when building my service bus, but that was 4 years ago. In that time, I think that NServiceBus made great strides in becoming an easier to use product and having a much better out of the box development story. If I was starting out with service buses today, I strongly doubt that I would be building my own.

Plaster

Answer 4

a potential con of anything MSMQ based is the restriction on maximum message size. IIRC it is approximately 4MB, which you might easily run into if you're dealing with large files and storing the file content within the message.

Interplanetary

Interestingly enough, most cloud-based queues don't even support payloads of 100KB, so this is something that will need to be taken into account by many apps in the future. – Trommel

In Enterprise Integration Patterns (Woolf,Hohpe), the Claim Check pattern specifically addresses this concern. A reference to the large payload is kept in the message only, keeping the message small. Large message sizes can wreak havoc on the throughput of a messaging system. – Kopeck

This isn't an issue with NServiceBus since they have a concept of a Data Bus, which transparently works around size limitations. – Descartes