Sugestão para sistema de mensagens

[Daniel Cukier]

Olá pessoal. 

Estamos desenvolvendo uma API para um sistema de mensagens. Ao chamar a API, um cliente espera que:

1) Se eu responder OK, eu garanto que a mensagem será entregue

2) Se eu responder ERRO, ele deve me chamar de novo

3) Nenhuma mensagem será entregue em duplicidade. 

Alguém tem alguma sugestão de como implementar isso de forma simples e elegante em Scala?

—
Daniel Cukier

[Daniel Sobral]

Pessoalmente, eu acho que vocês não devem implementar isso. Sistemas de mensageria existem aos montes, e problemas como idempotência e garantia de entrega não são simples. Para que reinventar a roda?

Eu gosto muito do Kafka, mas o Kafka passa para o cliente certas responsabilidades -- pessoalmente, eu acho que as responsabilidades são melhor divididas do que em algo como ActiveMQ, e a simplicidade compensa.

2013/4/8 Daniel Cukier <dani...@gmail.com>

--
 
---
Você está recebendo esta mensagem porque se inscreveu no grupo "scala-br" dos Grupos do Google.
Para cancelar a inscrição neste grupo e parar de receber seus e-mails, envie um e-mail para scala-br+u...@googlegroups.com.
Para obter mais opções, acesse https://groups.google.com/groups/opt_out.
 
 

--
Daniel C. Sobral

I travel to the future all the time.

[Alberto SOUZA]

Não sei se é tão simples quanto você espera. Mas acho que o Akka poderia lhe ajudar. O sistema de mensageria dele é baseado em hierarquia. Tem um pai controlando os atores filhos, e caso alguma coisa dê errado o filho pode notificar o pai. Dessa maneira você pode tomar a atitude que você quiser...  

Estou em dúvida se fui muito útil... o que geralmente quer dizer que não fui.

Alberto

2013/4/8 Daniel Cukier <dani...@gmail.com>

--

[Flavio W. Brasil]

Não sei se o Akka serviria para o caso do Daniel. Ele não possui garantia de entrega das mensagens.

http://doc.akka.io/docs/akka/snapshot/general/message-delivery-guarantees.html

Hoje não utilizo o Akka por causa desta limitação.

-- 

Flávio W. Brasil

http://activate-framework.org

{persistence as it should be}

[Alberto SOUZA]

Verdade. Fiquei mais preso no ponto de contornar o "OK" e "ERRO".

2013/4/8 Flavio W. Brasil <fwbr...@gmail.com>

[Paulo "JCranky" Siqueira]

O comentário do Sobral é importante implementar isso na unha não é legal.

Usar o Akka pode funcionar. Como o Flávio falou, ele não tem garantia de entrega, mas não é complicado implementar um ack em cima. Fora isso, essa restrição só é relevante se estivermos falando de remoting.

O que leva à pergunta: estamos falando de troca de mensagens entre que tipo de componentes / clientes etc?

[]s,

Paulo "JCranky" Siqueira
http://jcranky.com
http://lojinha.paulosiqueira.com.br

[Daniel Cukier]

Talvez eu possa explicar melhor:

Será uma API rest. Um cliente faz um post pedindo pra eu enviar a mensagem. Se eu responder 200 OK pra ele, ele considera que a mensagem foi enviada e não me chama de novo. Se eu responder 500 Error ele me chama de novo mais tarde.  

Internamente, eu faço algumas operações para persistir essa mensagem num banco de dados e outras para enviar um email via SMTP com o conteúdo da mensagem. 

Expliquei?

—
Daniel Cukier

[Paulo "JCranky" Siqueira]

Me parece um bom caso para o Spray.io. Internamente ele usa o Akka, mas vai te ajudar a expor a API rest.

[]s,

Paulo "JCranky" Siqueira
http://jcranky.com
http://lojinha.paulosiqueira.com.br

[Isaias Barroso]

Olá, usando akka nesse cenário acho que vale a pena dar uma olhada no Event Sourced https://github.com/eligosource/eventsourced

Uma outra opção é usar o RabbitMQ que é leve e bem rápido.

[]'s

[adriano santos]

O Akka não possuí garantia de entrega mas se você utilizar o Akka com ActiveMQ este lhe forneceria a garantia de entrega, e mensagens persistentes.