Goals and Disclaimers

This post is not a deep-dive comparison of the two frameworks. To do so would be extremely time consuming and I’m not sure would add a lot of value as the use cases for these frameworks are so broad. Instead, I hope to offer some general guidance on how to approach your own comparison research (with links to more details where appropriate).

The other goal for this post is to hopefully solicit feedback from others to improve the quality of advice offered here. You may want to check back frequently for updates and interesting conversation. Keep things civil, however, please. (The “FIGHT”!” in the post title is just my own attempt at journalistic sensationalism.)

First, the disclaimers… I’ve used MassTransit for quite some time and obviously if you look at the other posts on this blog, you can see there’s a definite MassTransit bias. But there’s a twist! I actually do some (paid) work for Particular Software (makers of NServiceBus) writing documentation for their products. Particular is not paying me to write this blog post, however. If this post feels biased to you in any way, I apologize. We’re all human. On the other hand, the level of exposure I have to both frameworks does put me in a good position to publish some thoughts on the differences. Proceed with caution!

MassTransit versus NServiceBus

Common Qualities

Both frameworks have these qualities in common (in broad strokes):

• The projects were started and are actively maintained by wicked smart SOA experts. [MT | NSB]
• The code base is high quality, unit tested, and open to community contributions. [MT | NSB]
• There is a very responsive community. [MT | NSB]
• They support the most common messaging patterns (request/response, publish/subscribe, sagas, etc.). [MT | NSB]
• Both support your choice of IoC Container. [MT | NSB]
• Exceptions during message processing are handled and messages re-queued to be retried. [MT | NSB]

The bottom line is these are both very solid frameworks.

So What’s Different?

It’s been mentioned in other places many times before, but here are the basic differences if you haven’t seen them (again in broad strokes):

• While both are open source, only MassTransit is free to use in production. Production use of NServiceBus requires a commercial license. [MT | NSB]
• MassTransit support is strictly community-based through it’s Google Group (where the founders are extremely active) whereas NServiceBus offers a commercial support option. [MT | NSB]
• NServiceBus has an entire platform of other (commercial) tools supporting it.
• NServiceBus’ documentation and the platform itself tends to hold your hand a little more and try to steer you down the path of good practices. (You can still shoot yourself in the foot, they just try to make it harder.)

Obviously, there are many other, more detailed, differences but these are the major factors most people are considering when getting started.

The Automotive Analogy

Let’s use an automotive analogy and say MassTransit is a base model Honda Accord. Very solid, reliable vehicle. Always highly recommended by the auto experts and consumer groups. It will get you from point A to point B in a predictable manner. There are even upgraded components you can get that are designed to work well with it to give you a better experience.

If MassTransit is a Honda Accord, then NServiceBus is a Lexus IS350. All the same attributes as the Honda, but with a lot more capabilities right in the package. It’s a lot more comfortable, has more horsepower, and can do some pretty impressive things. Could you make the Honda do all the things that a Lexus could do? Possibly, but you’re going to be working in the garage a long time to upgrade it (or paying a custom car shop a lot of money to do so). It would be a very custom, one-of-a-kind vehicle, whereas the Lexus was designed holistically to have all its features work together in a reliable and safe package.

A Concrete Example

Let me give you a concrete example of some of the additional features you would get “in the box” from NServiceBus versus MassTransit. Take the example of working with a queuing system like RabbitMQ or Azure Service Bus that does not support distributed transactions. If you have a business process that needs to be highly reliable and consistent, then you have to deal with this lack of distributed transaction support. Consider this simple example:

1. You take the message off the queue.
2. You do some database work.
3. Before you can commit your database work, your server crashes.

In this example, you will lose data because the message will no longer be in the queue, but your database work was not persisted. This is why both MassTransit and NServiceBus don’t actually remove the message from the queue until your handler has completed successfully. So the scenario could go like this:

1. You peek at the next message on the queue.
2. You do your database work and it commits.
3. You go to remove the message from the queue, but… oops… the server crashes.

Now the message is still in the queue and will be processed again. This could lead to duplicate data. “No problem,” you say, “just keep track of the messages that are processed in the database.”

1. You peek at the next message on the queue.
2. You do your database work.
3. In the same db transaction, you record the message id so you know it’s been processed.
4. Commit the database transaction.
5. You go to remove the message from the queue, but… oops… the server crashes.

Now we’re okay because the logic in your handler can check to see if the message id has already been processed. We’re utilizing the transaction capability of your database to help us out here.

Problem solved, right? Actually, not quite… what if you want to publish another message after finishing the database work? That won’t be involved in the same transaction and now you risk either publishing incorrect information to the service bus or not publishing it at all depending on what order you do your database commit and message publishing. Here’s a great talk by Udi Dahan about this very problem and what the full end-to-end solution for it looks like:

The point that I am trying to make here is that with MassTransit, you have to code for these scenarios. This isn’t always necessary given the business requirements. If the occasional lost message or inconsistency in the database is not a big deal, then you wouldn’t need to add that logic and MT or NSB would do the job for you just fine.

However, if you do need this, then NServiceBus offers it out of the box. It also offers deferred message retry and publishing out of the box. There’s just a number of scenarios that it handles for you where with MassTransit you have to either roll your own or wire up another component (some of which are built by the MassTransit guys).

Bottom Line

If your needs don’t require compromise-free reliability and consistency and you are on a tight budget, then definitely look at MassTransit. If you do require compromise-free reliability and consistency, then you need to weigh the pros and cons of building the additional code necessary on top of MassTransit versus paying for NServiceBus but getting all of the functionality you need in one package.

Now it’s your turn. Let me know where I dropped the ball, where I didn’t elaborate enough, or where you think I’ve got it just all wrong…