Saltar al contenido

¿Qué es Microsoft Message Queuing (MSMQ)? ¿Como funciona?

Agradeceríamos tu apoyo para difundir nuestros enunciados sobre las ciencias de la computación.

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 asíncronas, mientras que los servicios web son síncronos. Utilizan diferentes protocolos y servicios de back-end para hacer esto, por lo que su implementación es completamente diferente, pero su propósito es similar.

Desearía utilizar las colas de mensajes cuando exista la posibilidad de que el otro proceso de comunicación no esté disponible, pero aun así desee que el mensaje se envíe en el momento que elija el cliente. La entrega ocurrirá cuando el proceso en el otro extremo se despierte 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 asincrónicamente mensajes de un tipo u otro entre hosts que pueden o no estar conectados 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 de una vez como máximo 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 que la transacción se revierte

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 se revirtió, esto probablemente 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 entrega como máximo una vez. 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 suponer que se revirtió cualquier efecto del mensaje.

Servicios web

Un servicio web es una llamada a un procedimiento remoto u otro servicio (p. ej., API RESTFul) publicado por un (típicamente) servidor HTTP. Es un protocolo de solicitud/respuesta síncrona y no tiene ninguna garantía de entrega integrada en el protocolo. Corresponde al cliente validar que el servicio se ha ejecutado correctamente. Por lo general, esto será a través de una respuesta a la solicitud o el tiempo de espera de la llamada.

En este último caso, los servicios web no garantizan la semántica como máximo una vez. El servidor puede completar el servicio y fallar en entregar una respuesta (posiblemente debido a que algo fuera del servidor está fallando). La aplicación debe ser capaz de 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 lidiar con esta falta de notificación garantizada de éxito/fracaso en las arquitecturas de servicios web. La idea es que, conceptualmente, uno escriba el estado en lugar de invocar un servicio, por lo que puede escribir cualquier número de veces. 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.

Te mostramos reseñas y puntuaciones

Tienes la posibilidad dar visibilidad a esta noticia si lograste el éxito.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)


Tags : /

Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *