Message Queue vs. Web Services?

Question

¿En qué condiciones uno preferiría que las aplicaciones hablen a través de una cola de mensajes en lugar de a través de servicios web (me refiero a XML, JSON, YAML o lo que sea por HTTP aquí, no a un tipo 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 hardware diferente). Las solicitudes son cosas como crear usuarios, mover archivos y crear directorios. ¿Bajo 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.

Answer 1

Cuando se utiliza un servicio web que tienen un cliente y un servidor:

1. Si el servidor falla el cliente debe asumir la responsabilidad de manejar el error.
2. Cuando el servidor está funcionando nuevamente, el cliente es responsable de volver a enviarlo.
3. Si el servidor da una respuesta a la llamada y el cliente falla, la operación se pierde.
4. No tiene conflicto, 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 disminuya.
5. Puede esperar una respuesta inmediata del servidor, pero también puede manejar llamadas asincrónicas.

Cuando se utiliza una cola de mensajes como RabbitMQ, beanstalkd, ActiveMQ, IBM MQ Series, smoking esperas más fallas resultados tolerantes diferentes y:

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

Message Queues tiene 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.

Answer 2

Las colas de mensajes son asíncronas y pueden volver a intentarse 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. Use servicios web si el solicitante necesita una respuesta.

Answer 3

Creo que, en general, querría un servicio web para una tarea de bloqueo (estas tareas deben completarse antes de ejecutar más código) y una cola de mensajes para una tarea sin bloqueo (podría llevar bastante tiempo) , pero no necesitamos esperar por eso).

Answer 4

Las colas de mensajes son ideales para solicitudes que pueden llevar mucho tiempo en procesarse. Las solicitudes se ponen en cola y se pueden procesar fuera de línea sin bloquear el cliente. Si el cliente debe ser notificado de la finalización, puede proporcionar una forma para que el cliente compruebe 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 ráfagas de actividad intensa, porque el procesamiento real se puede distribuir 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. P.ej. 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 busca es Message Queues versus Request/Response, este último es cuando la solicitud se procesa de forma sincronizada.

Answer 5

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

Si introduce el concepto de un proceso y una tarea como recurso, la necesidad de una capa de mensajería intermedia 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 volver al estado de encuestados o POST a una URL de devolución de llamada cuando haya terminado.

Esto es absolutamente simple, y se vuelve bastante poderoso cuando te das cuenta de que ahora puedes suscribirte a una alimentación rss/atom de todos los procesos y tareas en ejecución sin ninguna capa intermedia. Cualquier sistema de colas va a requerir algún tipo de interfaz de red de todos modos, 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 que se complete el proceso y la tarea.

Ha incorporado el descubrimiento de servicios, incluso para una tarea que tiene varios pasos, sin ningún protocolo complicado adicional.

GET /task/name 
    - returns form with required fields 

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

Su descubrimiento de servicios es un formulario HTML, un formato universal legible por humanos.

Todo el flujo puede ser utilizado por programa 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 al realizar la PUBLICACIÓN de forma asincrónica en 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 simplemente eliminar la necesidad de una cola de mensajes y un ESB en conjunto.

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