Próbuję połączyć dużą aplikację Scala + Akka + PlayMini z zewnętrznym interfejsem API REST. Pomysł polega na okresowym sprawdzaniu (zasadniczo co 1–10 minut) głównego adresu URL, a następnie przeszukiwaniu adresów URL niższego poziomu w celu wyodrębnienia danych, które następnie są wysyłane do kolejki komunikatów.

Wymyśliłem dwa sposoby, aby to zrobić:

Pierwsza droga

Utwórz hierarchię aktorów, aby dopasować strukturę ścieżki zasobów API. W przypadku Google Latitude oznaczałoby to np.

Aktor „latitude / v1 / currentLocation” ankietyhttps://www.googleapis.com/latitude/v1/currentLocationSondaże aktora „szerokość / v1 / lokalizacja”https://www.googleapis.com/latitude/v1/locationAktor „latitude / v1 / location / 1” ankietyhttps://www.googleapis.com/latitude/v1/location/1Aktor „latitude / v1 / location / 2” ankietyhttps://www.googleapis.com/latitude/v1/location/2Aktor „latitude / v1 / location / 3” ankietyhttps://www.googleapis.com/latitude/v1/location/3itp.

W tym przypadku każdy aktor jest odpowiedzialny za okresowe odpytywanie związanych z nim zasobów, a także tworzenie / usuwanie aktorów potomnych dla zasobów ścieżki następnego poziomu (tj. Aktor „szerokość / v1 / lokalizacja” tworzy aktorów 1, 2, 3 itd. wszystkie lokalizacje, o których dowiaduje się poprzez odpytywaniehttps://www.googleapis.com/latitude/v1/location).

Druga droga

Utwórz pulę identycznych aktorów odpytujących, które odbierają żądania odpytywania (zawierające ścieżkę zasobów) zrównoważone obciążeniem przez router, odpytują adres URL raz, wykonują przetwarzanie i planują żądania odpytywania (zarówno dla zasobów następnego poziomu, jak i odpytywanego adresu URL) . W usłudze Współrzędne Google oznaczałoby to na przykład:

1 router, n aktorzy poller. Początkowe żądanie odpytywania dlahttps://www.googleapis.com/latitude/v1/location prowadzi do kilku nowych (natychmiastowych) żądań głosowaniahttps://www.googleapis.com/latitude/v1/location/1, https://www.googleapis.com/latitude/v1/location/2itd. i jedno (opóźnione) żądanie odpytywania tego samego zasobu, tj.https://www.googleapis.com/latitude/v1/location.

Zaimplementowałem oba rozwiązania i nie mogę od razu zauważyć żadnej istotnej różnicy w wydajności, przynajmniej nie dla API i częstotliwości, które mnie interesują. Uważam, że pierwsze podejście jest nieco łatwiejsze do wyjaśnienia i być może łatwiejsze w użyciu z systemem .scheduler.schedule (...) niż drugie podejście (gdzie muszę zaplanowaćOst (...)). Ponadto, zakładając, że zasoby są zagnieżdżone na kilku poziomach i nieco krótkotrwałe (np. Kilka zasobów może zostać dodanych / usuniętych między każdym odpytywaniem), zarządzanie cyklem życia akka ułatwia zabicie całej gałęzi w pierwszym przypadku. Drugie podejście powinno (teoretycznie) być szybsze, a kod jest nieco łatwiejszy do napisania.

Moje pytania to:

Jakie podejście wydaje się najlepsze (pod względem wydajności, rozszerzalności, złożoności kodu itp.)?Czy widzisz coś złego w konstrukcji jednego z podejść (szczególnie pierwszego)?Czy ktoś próbował wdrożyć coś podobnego? Jak to się stało?

Dzięki!