¿Cola de mensajes vs. servicios web? [cerrado]

¿En qué condiciones se preferirían las aplicaciones que hablan a través de una cola de mensajes en lugar de a través de servicios web (solo me refiero a XML o JSON o YAML o lo que sea sobre HTTP aquí, no a ningún tipo en particular)?

Tengo que hablar entre dos aplicaciones en una red local. Una será una aplicación web y tendrá que solicitar comandos en otra aplicación (que se ejecuta en un hardware diferente). Las solicitudes son cosas como crear usuarios, mover archivos y crear directorios. ¿En qué condiciones preferiría los servicios web XML (o TCP directo o algo así) a usar una cola de mensajes?

La aplicación web es Ruby on Rails, pero creo que la pregunta es más amplia que eso.

Cuando usa un servicio web tiene un cliente y un servidor:

1. Si el servidor falla, el cliente debe asumir la responsabilidad de manejar el error.
2. Cuando el servidor vuelve a funcionar, el cliente es responsable de reenviarlo.
3. Si el servidor responde a la llamada y el cliente falla, la operación se pierde.
4. No tiene contención, es decir: si millones de clientes llaman a un servicio web en un servidor en un segundo, lo más probable es que su servidor se caiga.
5. Puede esperar una respuesta inmediata del servidor, pero también puede manejar llamadas asincrónicas.

Cuando utiliza una cola de mensajes como RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, espera resultados diferentes y más tolerantes a fallos:

1. Si el servidor falla, la cola persiste el mensaje (opcionalmente, incluso si la máquina se apaga).
2. Cuando el servidor vuelve a funcionar, recibe el mensaje pendiente.
3. Si el servidor responde a la llamada y el cliente falla, si el cliente no confirmó la respuesta, el mensaje persiste.
4. Usted tiene contención, puede decidir cuántas solicitudes maneja el servidor (en su lugar, llámelo trabajador).
5. No espera una respuesta síncrona inmediata, pero puede implementar / simular llamadas síncronas.

Las colas de mensajes tienen muchas más funciones, pero esta es una regla general para decidir si desea manejar las condiciones de error usted mismo o dejarlas en la cola de mensajes.

Ha habido una gran cantidad de investigaciones recientes al considerar cómo las llamadas HTTP REST podrían reemplazar el concepto de la cola de mensajes.

Si introduce el concepto de un proceso y una tarea como recurso, la necesidad de una capa de mensajería media comienza a evaporarse.

Ex:

POST /task/name
    - Returns a 202 accepted status immediately
    - Returns a resource url for the created task: /task/name/X
    - Returns a resource url for the started process: /process/Y

GET /process/Y
    - Returns status of ongoing process

Una tarea puede tener múltiples pasos para la inicialización, y un proceso puede devolver el estado cuando se sondea o POST a una URL de devolución de llamada cuando se completa.

Esto es muy simple y se vuelve bastante poderoso cuando te das cuenta de que ahora puedes suscribirte a un feed rss / atom de todos los procesos y tareas en ejecución sin ninguna capa intermedia. De todos modos, cualquier sistema de colas requerirá algún tipo de front-end web, y este concepto lo tiene incorporado sin otra capa de código personalizado.

Sus recursos existen hasta que los elimine, lo que significa que puede ver información histórica mucho después de completar el proceso y la tarea.

Ha incorporado el descubrimiento de servicios, incluso para una tarea que tiene varios pasos, sin protocolos adicionales complicados.

GET /task/name
    - returns form with required fields

POST (URL provided form's "action" attribute)

El descubrimiento de su servicio es un formulario HTML, un formato universal y legible por humanos.

Todo el flujo puede ser utilizado mediante programación o por un humano, utilizando herramientas universalmente aceptadas. Es un cliente impulsado y, por lo tanto, RESTful. Cada herramienta creada para la web puede impulsar sus procesos comerciales. Aún tiene canales de mensajes alternativos POSTING asincrónicamente a una matriz separada de servidores de registro.

Después de considerarlo por un tiempo, se sienta y comienza a darse cuenta de que REST puede eliminar la necesidad de una cola de mensajería y un ESB por completo.

http://www.infoq.com/presentations/BPM-with-REST

Las colas de mensajes son ideales para solicitudes que pueden tardar mucho tiempo en procesarse. Las solicitudes se ponen en cola y se pueden procesar sin conexión sin bloquear al cliente. Si el cliente necesita ser notificado de su finalización, puede proporcionarle una manera de verificar periódicamente el estado de la solicitud.

Las colas de mensajes también le permiten escalar mejor en el tiempo. Mejora su capacidad para manejar estallidos de actividad intensa, porque el procesamiento real puede distribuirse a lo largo del tiempo.

Tenga en cuenta que las colas de mensajes y los servicios web son conceptos ortogonales, es decir, no son mutuamente excluyentes. Por ejemplo, puede tener un servicio web basado en XML que actúa como una interfaz para una cola de mensajes. Creo que la distinción que está buscando es Colas de mensajes versus Solicitud / Respuesta, esta última es cuando la solicitud se procesa sincrónicamente.

Las colas de mensajes son asíncronas y pueden volver a intentarlo varias veces si falla la entrega. Use una cola de mensajes si el solicitante no necesita esperar una respuesta.

La frase "servicios web" me hace pensar en llamadas sincrónicas a un componente distribuido a través de HTTP. Utilice los servicios web si el solicitante necesita una respuesta.

Creo que, en general, querrías un servicio web para una tarea de bloqueo (esta tarea debe completarse antes de ejecutar más código) y una cola de mensajes para una tarea que no sea de bloqueo (podría llevar bastante tiempo, pero no No necesito esperarlo).