Message Queue vs. Web Services?

En este post de stackoverflow. Copio y pego literalmente, para no perder esta informacion.

When you use a web service you have a client and a server:
– If the server fails the client must take responsibility to handle the error.
– When the server is working again the client is responsible of resending it.
– If the server gives a response to the call and the client fails the operation is lost.
– You don’t have contention, that is: if million of clients call a web service on one server in a second, most probably your server will go down.
– You can expect an immediate response from the server, but you can handle asynchronous calls too.

When you use a message queue like RabbitMQ, ActiveMQ, IBM MQ Series, Tuxedo you expect different and more fault tolerant results:
– If the server fails, the queue persist the message (optionally, even if the machine shutdown).
– When the server is working again, it receives the pending message.
– If the server gives a response to the call and the client fails, if the client didn’t acknowledge the response the message is persisted.
– You have contention, you can decide how many requests are handled by the server (call it worker instead).
– You don’t expect an immediate synchronous response, but you can implement/simulate synchronous calls.
Message Queues has a lot more features but this is some rule of thumb to decide if you want to handle error conditions yourself or leave them to the message queue.

En programmers.stackexchange.com encontre este otro post buscando cuando implementar RabbitMQ.

When to use Advanced Message Queuing Protocol like RabbitMQ?
Imagine that you have a web service that can accept many requests per second. You also have a accounting system that does a lot of things, one of which is processing the requests coming from the web service.
If you put a queue between the web service and the accounting system, you will be able to:
have less coupling between the two applications, because now both applications have to know the configuration parameters of the queue management system and the name of the queue. Here the catch is that usually you are more likely to move to another server some application than move the queue management system
if you have a lot of requests coming in a short amount of time, the accounting system will be able to process them all anyway
persist some requests if their number becomes really huge
Of course, you could have more complex situations where the number of your applications is much bigger than two and you need to manage the communication between them.

Servidor de Mensajes

Basado en Message-oriented middleware (MOM) existe el Message queue. Que implementa los siguientes protocolos: Advanced Message Queuing Protocol (AMQP) y Simple (or Streaming) Text Oriented Message Protocol (STOMP).

Ventajas

(de este blog)
– Redundancia – Si tu aplicación falla mientras está procesando alguna petición no te debes preocupar de que esta se pierda para siempre ya que esta estrategia le permite a la cola persistir el mensaje hasta que el mismo sea procesado por completo.
– Naturaleza asíncrona – Dependiendo de la manera en que funcione tu sistema puedes necesitar que los mensajes se vayan acumulando para procesarlos en lotes, la cola irá manteniendo tus mensajes para cuando decidas (o programes) su procesamiento.
– Garantía de entrega y ordenamiento – Se garantiza que el orden en el que llegan los mensajes será el orden en el que sean procesados, de igual manera un emisor y/o consumidor puede estar seguro de que este ha sido recibido y se procesará una única vez mediante la implementación de intercambio de banderas de reconocimiento.
– Disponibilidad – Si parte de tu arquitectura falla, los mensajes no se perderán ya que estos seguirán en la cola hasta que se les indique lo contrario, al mismo tiempo la cola podrá seguir recibiendo mensajes para el procesamiento posterior a la recuperación del sistema.
– Elasticidad – En situaciones donde tu sistema pudiera llegar al tope de su capacidad de recepción de peticiones y volverse incapaz de responder por un anormal flujo de mensajes, el hecho de tener una cola o buffer de peticiones permitirá balancear, filtrar y normalizar el flujo, lo cual evitará que tu sistema sea inundado de peticiones que no pueda responder causando perdida de los mismos o incluso el colapso del sistema.
– Desacoplamiento – El hecho de tener una capa intermedia de comunicación entre procesos nos da la flexibilidad en la definición de arquitectura de cada uno de ellos de manera separada, mientras cada uno se mantenga alineado a los mismos requerimientos de interfaz que representa la cola de mensajes no abran mayores problemas de compatibilidad ni mucho que cambiar de lado y lado.
– Escalabilidad – Por la misma ventaja de desacoplamiento podemos escalar fácilmente nuestro sistema, solo debemos agregar más unidades de procesamiento y el sistema de colas se encargará de balancear la carga entre ellos.

Software
RabbitMQ. get started.

Standar de la industria AMQP.

STOMP