MSMQ and SQL Server Service Broker

Question

I have an application that consists of three parts:

• front-end web store for end users and business partners
• order management system to process these orders
• technical database for processing all technical details of ordered products and services

Today, these systems (which are located on separate servers and are developed by separate teams) interact using WCF web services.

This setting works fine - while all the servers are busy. Which they are not - not always, anyway.

So, I began to study the use of MSMQ or SQL Server Service Broker to process communication between these systems - at least when it comes to the web store that stores the order in the order management system, or sending the order management system technical data to the technical database system .

I hope to achieve greater reliability throughout the system - users can still place orders, and they will not be lost, even if the backend order management is temporarily unavailable.

But the big question is: MSMQ or Service Broker ?? All three systems are based on Windows and .NET and already use SQL Server - on three separate servers.

Does anyone have solid, real facts that say (or are against) one of these two technologies? What is your real experience with these two sets of technologies? Pros and cons. If you could start from scratch, which one would you choose? Or would you choose something else (what?) Completely?

Answer 1

I used both options equally well in different situations. My preferences are really quite simple: use SQL Service Broker if a message sending event is triggered from a database event; Use a message queue if the event is in code. This preference is based only on the fact that it is easier to configure on the same platform that will trigger the event.