Fila de mensagens vs. serviços da Web? [fechadas]

Sob quais condições alguém preferiria aplicativos conversando por meio de uma fila de mensagens em vez de por serviços da Web (quero dizer XML ou JSON ou YAML ou qualquer outra coisa sobre HTTP aqui, não um tipo específico)?

Eu tenho que falar entre dois aplicativos em uma rede local. Um será um aplicativo da web e precisará solicitar comandos em outro aplicativo (executando em hardware diferente). Os pedidos são como criar usuários, mover arquivos e criar diretórios. Sob quais condições eu preferiria XML Web Services (ou TCP direto ou algo assim) a usar uma fila de mensagens?

O aplicativo da web é Ruby on Rails, mas acho que a questão é mais ampla que isso.

Ao usar um serviço da Web, você tem um cliente e um servidor:

1. Se o servidor falhar, o cliente deve assumir a responsabilidade de lidar com o erro.
2. Quando o servidor está funcionando novamente, o cliente é responsável por reenviá-lo.
3. Se o servidor responder à chamada e o cliente falhar, a operação será perdida.
4. Você não tem contendas, ou seja: se milhões de clientes ligam para um serviço da Web em um servidor em um segundo, provavelmente o servidor será desativado.
5. Você pode esperar uma resposta imediata do servidor, mas também pode lidar com chamadas assíncronas.

Ao usar uma fila de mensagens como RabbitMQ, Beanstalkd, ActiveMQ, IBM MQ Series, Tuxedo, você espera resultados diferentes e mais tolerantes a falhas:

1. Se o servidor falhar, a fila persistirá na mensagem (opcionalmente, mesmo que a máquina desligue).
2. Quando o servidor está funcionando novamente, ele recebe a mensagem pendente.
3. Se o servidor responder à chamada e o cliente falhar, se o cliente não reconhecer a resposta, a mensagem será mantida.
4. Você tem contenção, pode decidir quantas solicitações serão tratadas pelo servidor (chame-o de trabalhador).
5. Você não espera uma resposta síncrona imediata, mas pode implementar / simular chamadas síncronas.

As filas de mensagens têm muito mais recursos, mas essa é uma regra prática para decidir se você deseja lidar com as condições de erro ou deixá-las na fila de mensagens.

Houve uma quantidade considerável de pesquisas recentes ao considerar como as chamadas HTTP REST poderiam substituir o conceito de fila de mensagens.

Se você introduzir o conceito de um processo e uma tarefa como um recurso, a necessidade de camada de mensagens do meio começará a evaporar.

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

Uma tarefa pode ter várias etapas para inicialização e um processo pode retornar o status quando pesquisado ou POST para um URL de retorno de chamada quando concluído.

Isso é simples e torna-se bastante poderoso quando você percebe que agora pode assinar um feed rss / atom de todos os processos e tarefas em execução sem nenhuma camada intermediária. Qualquer sistema de enfileiramento exigirá algum tipo de front-end da Web, e esse conceito foi incorporado sem outra camada de código personalizado.

Seus recursos existem até você excluí-los, o que significa que você pode visualizar informações históricas muito tempo após a conclusão do processo e da tarefa.

Você integrou a descoberta de serviços, mesmo para uma tarefa que possui várias etapas, sem protocolos extras complicados.

GET /task/name
    - returns form with required fields

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

Sua descoberta de serviço é um formulário HTML - um formato legível universal e humano.

Todo o fluxo pode ser usado programaticamente ou por um ser humano, usando ferramentas universalmente aceitas. É um cliente orientado e, portanto, RESTful. Toda ferramenta criada para a web pode conduzir seus processos de negócios. Você ainda possui canais de mensagens alternativos, POSTando assincronamente para uma matriz separada de servidores de log.

Depois de considerar por um tempo, relaxe e comece a perceber que o REST pode apenas eliminar a necessidade de uma fila de mensagens e um ESB completamente.

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

As filas de mensagens são ideais para solicitações que podem levar muito tempo para serem processadas. As solicitações são colocadas na fila e podem ser processadas offline sem bloquear o cliente. Se o cliente precisar ser notificado sobre a conclusão, você poderá fornecer uma maneira de verificar periodicamente o status da solicitação.

As filas de mensagens também permitem escalar melhor ao longo do tempo. Isso melhora sua capacidade de lidar com rajadas de atividades pesadas, porque o processamento real pode ser distribuído ao longo do tempo.

Observe que as filas de mensagens e os serviços da web são conceitos ortogonais, ou seja, não são mutuamente exclusivos. Por exemplo, você pode ter um serviço da Web baseado em XML que atua como uma interface para uma fila de mensagens. Eu acho que a distinção que você procura é Filas de Mensagens versus Solicitação / Resposta; a última é quando a solicitação é processada de forma síncrona.

As filas de mensagens são assíncronas e podem tentar várias vezes se a entrega falhar. Use uma fila de mensagens se o solicitante não precisar esperar por uma resposta.

A frase "serviços da web" me faz pensar em chamadas síncronas para um componente distribuído por HTTP. Use serviços da web se o solicitante precisar de uma resposta de volta.

Eu acho que, em geral, você deseja um serviço da Web para uma tarefa de bloqueio (essas tarefas precisam ser concluídas antes de executarmos mais código) e uma fila de mensagens para uma tarefa sem bloqueio (pode demorar um pouco, mas não precisa esperar por isso).