Estou tentando fazer a interface de um grande aplicativo Scala + Akka + PlayMini com uma API REST externa. A ideia é pesquisar periodicamente (basicamente a cada 1 a 10 minutos) um URL raiz e, em seguida, rastrear por meio de URLs de subnível para extrair dados que são então enviados para uma fila de mensagens.

Eu tenho duas maneiras de fazer isso:

1a via

Crie uma hierarquia de atores para corresponder à estrutura do caminho do recurso da API. No caso do Google Latitude, isso significaria, por exemplo

"Latitude / v1 / currentLocation" pesquisas de atoreshttps://www.googleapis.com/latitude/v1/currentLocation"Latitude / v1 / localização" do atorhttps://www.googleapis.com/latitude/v1/location"Latitude / v1 / location / 1" enquetes do atorhttps://www.googleapis.com/latitude/v1/location/1"Latitude / v1 / localização / 2" enquetes do atorhttps://www.googleapis.com/latitude/v1/location/2Latitude / v1 / local / 3 'enquetes do ator'https://www.googleapis.com/latitude/v1/location/3etc.

Nesse caso, cada ator é responsável por pesquisar seus recursos associados periodicamente, bem como criar / excluir atores-filhos para recursos de caminho de próximo nível (ou seja, o ator 'latitude / v1 / location' cria os atores 1, 2, 3, etc. todos os locais que aprende através da pesquisa dehttps://www.googleapis.com/latitude/v1/location).

Ò caminho

Criar um pool de agentes de pesquisa idênticos que recebem solicitações de pesquisa (contendo o caminho do recurso) com balanceamento de carga por um roteador, pesquisar o URL uma vez, fazer algum processamento e agendar solicitações de pesquisa (para recursos de próximo nível e para o URL pesquisado) . No Google Latitude, isso significaria, por exemplo:

1 roteador, n atores de poller. Solicitação de pesquisa inicial parahttps://www.googleapis.com/latitude/v1/location leva a várias solicitações de pesquisa novas (imediatas) parahttps://www.googleapis.com/latitude/v1/location/1, https://www.googleapis.com/latitude/v1/location/2, etc. e uma solicitação de pesquisa (atrasada) para o mesmo recurso, ou seja,https://www.googleapis.com/latitude/v1/location.

Implementei ambas as soluções e não posso observar imediatamente qualquer diferença relevante de desempenho, pelo menos não para as freqüências de API e de pesquisa nas quais estou interessado. Acho que a primeira abordagem é um pouco mais fácil de raciocinar e talvez mais fácil de usar com o sistema. .scheduler.schedule (...) que a segunda abordagem (onde eu preciso agendarOnce (...)). Além disso, assumindo que os recursos são aninhados através de vários níveis e um pouco de vida curta (por exemplo, vários recursos podem ser adicionados / removidos entre cada pesquisa), o gerenciamento do ciclo de vida do akka facilita a eliminação de uma ramificação inteira no primeiro caso. A segunda abordagem deve (teoricamente) ser mais rápida e o código é um pouco mais fácil de escrever.

Minhas perguntas são:

Qual abordagem parece ser a melhor (em termos de desempenho, extensibilidade, complexidade de código, etc.)?Você vê algo de errado com o design de qualquer abordagem (especialmente o primeiro)?Alguém já tentou implementar algo parecido? Como foi feito?

Obrigado!