Solución:
Con el debido respeto a la respuesta de @ Juan, ambas son formas de intercambiar datos entre dos procesos desconectados, es decir, canales de comunicación entre procesos (IPC). Las colas de mensajes son asincrónicas, mientras que los servicios web son síncronos. Usan diferentes protocolos y servicios de back-end para hacer esto, por lo que son completamente diferentes en implementación, pero similares en propósito.
Usted querrá utilizar las colas de mensajes cuando exista la posibilidad de que el otro proceso de comunicación no esté disponible, pero aún así desea que el mensaje se envíe en el momento que elija el cliente. La entrega se producirá cuando el proceso en el otro extremo se active y reciba una notificación de la llegada del mensaje.
Como su nombre lo indica, es solo un administrador de colas.
Puede enviar objetos (serializados) a la cola donde permanecerán hasta que los reciba. Normalmente se utiliza para enviar mensajes u objetos entre aplicaciones de forma desacoplada.
No tiene nada que ver con los servicios web, son dos cosas diferentes
Información sobre MSMQ:
https://msdn.microsoft.com/en-us/library/ms711472(v=vs.85).aspx
Información sobre servicios web:
http://msdn.microsoft.com/en-us/library/ms972326.aspx
Gestión de colas transaccionales 101
Una cola transaccional es un sistema de middleware que enruta de forma asincrónica mensajes de un tipo u otro entre hosts que pueden estar conectados o no en un momento dado. Esto significa que también debe ser capaz de persistir el mensaje en alguna parte. Ejemplos de tales sistemas son MSMQ e IBM MQ
Una cola transaccional también puede participar en una transacción distribuida y una reversión puede desencadenar la eliminación de mensajes. Esto significa que se garantiza que un mensaje se entregará con semántica como máximo una vez o entrega garantizada si no se revierte. El mensaje no se entregará si:
-
El host A publica el mensaje pero el host B no está conectado
-
Algo (posiblemente, pero no necesariamente iniciado desde el Host A) revierte la transacción
-
B se conecta después de revertir la transacción
En este caso, B nunca sabrá que el mensaje existió a menos que se le informe a través de algún otro medio. Si la transacción fue revertida, probablemente esto no importe. Si B se conecta y recopila el mensaje antes de que se revierta la transacción, la reversión también revertirá los efectos del mensaje en B.
Tenga en cuenta que A puede publicar el mensaje en la cola con la garantía de una entrega como máximo. Si la transacción se confirma, el Host A puede asumir que el mensaje ha sido entregado por el medio de transporte confiable. Si la transacción se revierte, el Host A puede asumir que se han revertido los efectos del mensaje.
Servicios web
Un servicio web es una llamada a procedimiento remoto u otro servicio (por ejemplo, API RESTFul) publicado por un servidor HTTP (normalmente). Es un protocolo de solicitud / respuesta sincrónico y no tiene garantía de entrega incorporada en el protocolo. Depende del cliente validar que el servicio se haya ejecutado correctamente. Por lo general, esto se realizará mediante una respuesta a la solicitud o el tiempo de espera de la llamada.
En el último caso, los servicios web no garantizan la semántica como máximo. El servidor puede completar el servicio y no entregar una respuesta (posiblemente debido a que algo fuera del servidor va mal). La aplicación debe poder hacer frente a esta situación.
IIRC, los servicios RESTFul deben ser idempotentes (se logra el mismo estado después de cualquier número de invocaciones del mismo servicio), que es una estrategia para hacer frente a esta falta de notificación garantizada de éxito / fracaso en las arquitecturas de servicios web. La idea es que conceptualmente se escribe estado en lugar de invocar un servicio, por lo que se puede escribir tantas veces como se desee. Esto significa que la aplicación puede tolerar la falta de comentarios sobre el éxito, ya que puede volver a intentar la publicación hasta que reciba un mensaje de “éxito” del servidor.