37

I'd like to make an informed choice towards a simple publish/subscribe architecture.

So I'm wondering: what does the Service Bus add that MSMQ can't do?
What are the drawbacks of the Service Bus?

Thx for enlightening me!

David
  • 3,736
  • 8
  • 33
  • 52
  • 1
    +1, Interesting question. I don't know very much about Windows Service Bus, I'd love to see a detailed comparison with MSMQ. I've found this (see comments below the article): http://shanthuk.com/2012/11/05/windows-service-bus-vs-msmq/ For what it's worth, I've successfully used MSMQ in my architectures many times and definitely recommend it: lightweight, robust, transactional. See http://stackoverflow.com/a/9077925/870604 – ken2k Sep 30 '13 at 09:49
  • Just to add (as it's often overlooked), if you are using Sql Server at all then also consider Service Broker, which is a messaging system inside the database infrastructure. – Rikalous Sep 30 '13 at 10:28
  • I recommend you to use NServiceBus http://nservicebus.com/CodeFirstGettingStarted.aspx – Kamil Budziewski Oct 02 '13 at 17:58
  • +1. Good question. I suppose Windows Service Bus can be seen more as "Azure Service Bus on premises". It does not really "add to MSMQ", it's a completely different and new system, storing messages in SQL server. – Simon Mourier Oct 02 '13 at 20:33
  • This should be helpful despite it compares the WSB to RabbitMQ http://geekswithblogs.net/michaelstephenson/archive/2012/08/12/150399.aspx – Wiktor Zychla Oct 02 '13 at 20:46
  • Regard MSMQ as a transport protocol. MSMQ is a support layer for higher level applications, such as service bus. – John Breakwell Oct 02 '13 at 21:42
  • @ ken2k: thx for the bounty, I'd really like to get a complete answer. @ wudzik: why? that's in summary my question :) @ simon: true, but they provide similar functionality. where do they differ therein? @ John: an excellent explanation, but what does the higher level add? – David Oct 03 '13 at 09:45

2 Answers2

21

The main functional difference is Service Bus provides out of the box support for message exchange semantics such as topic based routing via publish-subscribe.

MSMQ on the other hand is a lightweight store-and-forward queuing system, which supports point-to-point one way messaging.

Service Bus:

  1. depends on SQL Server, and
  2. is a broker. This may be considered a drawback.

If you are looking at pub-sub frameworks then a popular one at the moment (free in single threaded mode) is NServiceBus, which sits on top of MSMQ, though has swap-able transport.

tom redfern
  • 30,562
  • 14
  • 91
  • 126
  • 1
    Thanks for your answer that is useful and documented with links. +1 for the answer and the bounty reputation bonus is for you :) – ken2k Oct 09 '13 at 17:14
  • 1
    @ken2k very gracious of you...to be honest was not expecting the bounty and I am surprised no better answers than mine were posted. This topic deserves better discussion I think. – tom redfern Oct 10 '13 at 06:49
  • Thanks for the link to bus-and-broker-pubsub-differences page - was informative. – eddiewould Jun 29 '17 at 03:29
9

Pros

  • Service Bus allows you to publish over tcp and http which is cool, and gives you greater decoupling.
  • Service Bus is a sql database so your Disaster Recovery is WAY simpler and a lot cheaper to implement.

Cons

  • Service Bus is centralised, and MSMQ is federated, so potentially more scalable. Although you can scale out with more nodes in WSB.
  • You need a live connection to the central bus before you can publish. So MSMQ being federated (on each machine) makes it more available to clients.

However people are using MSMQ as a local store with Service Bus, so publish locally, then push it over to the bus when a connection is available.

We are having a good experience with Service Bus instead of MSMQ at the moment.

jonho
  • 1,680
  • 2
  • 19
  • 29
  • can you describe the last scenario a little more? using MSMQ as a local store with SB? Does that mean you always push client message into MSMQ queues, and then how does SB leverage that? – Thiago Silva May 01 '14 at 22:02
  • 1
    Your Web Server has msmq installed as does your Sb Server. Your Client site implements an Sb retry policy when initially trying to publish to Sb directly. If these fail stick msg on local msmq and use the inbuilt Store and forward mechanism to deliver to msmq on the Sb Server (when it becomes available.) Have a windows service on the sb server that loads msmq messages into sb queues. Alternatively add more sb nodes to your farm for more availability. – jonho May 05 '14 at 14:48