MSMQ vs SQL Server Service Broker

Question

tengo una aplicación que consta de tres partes:

• una tienda web front-end para los usuarios finales y socios de negocios
• un sistema de gestión de pedidos para manejar los
órdenes
• un sistema de base de datos técnica para manejar todos los detalles técnicos de los productos y servicios solicitados

Hoy en día, estos sistemas (que están en servidores independientes y están desarrollando por t separada eams) interoperan utilizando servicios web WCF.

Esta configuración funciona bien, siempre y cuando todos los servidores estén activos. Lo cual no son, no siempre, de todos modos.

Así que he comenzado a utilizar MSMQ o SQL Server Service Broker para manejar la comunicación entre esos sistemas, al menos cuando se trata de almacenar un pedido en el sistema de gestión de pedidos o el sistema de gestión de pedidos. enviando los datos técnicos al sistema de base de datos de tecnología.

Espero obtener más fiabilidad en todo el sistema: los usuarios pueden seguir haciendo pedidos y estos no se perderán, incluso si el backend de gestión de pedidos no está disponible temporalmente.

Pero la gran pregunta es: ¿MSMQ o Service Broker? Los tres sistemas están basados ​​en Windows y .NET, y ya usan SQL Server en tres servidores separados.

¿Alguien tiene algunos hechos sólidos, del mundo real que hablan en favor o en contra de una de esas dos tecnologías? ¿Cuáles son sus experiencias de la vida real con esos dos conjuntos de tecnologías? Pros y contras. Si pudieras comenzar desde cero, ¿cuál elegirías? ¿O elegirías algo más (¿qué?) Por completo?

Answer 1

He utilizado ambos, en diferentes situaciones, igualmente bien. Mi preferencia es realmente bastante básica: usar SQL Service Broker si el evento de envío de mensajes se desencadena desde un evento de base de datos; Use la cola de mensajes si el evento está en el código. Esa preferencia se basa simplemente en que es más fácil de configurar en la misma plataforma que activará el evento.