Why do we need service bus frameworks like NService Bus/MassTransit on top of message queuing systems like MSMQ/RabbitMQ etc?

Question

In the distributed message transaction world, am trying to understand the different parts that are involved in developing distributed systems. From what I understand you can

Answer 1

You certainly can code directly against the messaging infrastructure and you will find that there are pros and cons w.r.t. each transport. There are many decisions that you will need to make along the way, though, and this is where a service bus may assist.

Developing directly against the queuing system will inevitably lead to various abstractions that you will require to prevent duplication.

A service bus will provide opinions/implementations for:

• Message delivery
  • exactly-once (distributed transactions - distributed transactions are not supported by all queuing systems)
  • at-least-once (non-transactional)
  • at-most-once (will probably require some transactional processing but you can get away with no distributed transactions)
• Retrying failed messages
• Request / Response
• Message distribution
• Publish/Subscribe (probably quite easy with RabbitMQ directly, not so much with MSMQ directly)
• Message Idempotence
• Dependency Injection

Some service bus implementations provide a framework for implementing process managers (called sagas by most). My current opinion is that a process manager needs to be a first-class citizen as any other entity is but that may change :)

Anyhow, if you as still evaluating options you could also take a look at my FOSS project: http://shuttle.github.io/shuttle-esb/

So a service bus may buy you quite a bit out-of-the-box whereas coding against the queues directly may be a bit of work to get going.