Convenzioni di denominazione per i messaggi e gli attori di Akka

Question

Attualmente sono in procinto di creare un'applicazione Java Akka piuttosto grande e sto incontrando un paio di problemi che mi fanno impazzire.

mio layout attuale pacchetto si presenta un po 'come questo:

La mia classe Mobile servire come supervisore degli attori all'interno del pacchetto actors.

Dal momento che non voglio creare un nuovo insieme di attori per ogni HttpClient e Account, passo quelli intorno a oggetti dei messaggi, che vengono memorizzati nel pacchetto messaggi, insieme con l'endpoint ActorRef che riceve il risultato finale. Ciò tuttavia crea un pacchetto molto ingombrante messages con un messaggio diverso per ciascun attore. Per esempio. MobileForActor1, Actor1ForMobile, MobileForActor2 ecc Ora la mia domanda è: esiste una Convenzione da utilizzare per questo genere di cose che si occupa di questo problema ed è la mia struttura (Mobile ->Actor1 ->Mobile ->Actor2 -.>, Ecc) il modo in cui Akka vuole che sia o devo fare una sorta di cascata dei messaggi (Mobile ->Actor1 ->Actor2 -> ecc.)?

In questo momento sto inviando un ConnectMessage alla mia Mobile attore che poi lo invia a Actor1, Actor1 elabora e invia un nuovo messaggio al Mobile, Mobile invia questa risposta poi a Actor2 e il ciclo continua con un nuovo messaggio essere creato in base al vecchio messaggio. Per esempio. new Message2(message1.foo, message1.bar, message1.baz, newComputatedResult, newComputatedResult2, etc);

Questa buona pratica o dovrei includere la vecchia istanza (che può contenere informazioni che non sono più utili) e includere le nuove cose? Per esempio. new Message2(message1, newComputatedResult, newComputatedResult2, etc);

Oppure devo fare qualcosa di completamente diverso?

Ho pensato di utilizzare TypedActors ma quelli richiedono l'utilizzo di un pattern a cascata e non so come passare l'ActorRef dell'ascoltatore che desidera ricevere il risultato finale.

Spero di essermi reso abbastanza comprensibile perché l'inglese non è la mia lingua di partenza e che la domanda è chiara per tutti.

Sono uno sviluppatore Akka di inizio e amo l'idea, ma dal momento che la documentazione non copre questo molto bene, ho pensato che questo sarebbe il posto migliore per chiedere. Grazie per aver letto!

Answer 1

Mi avventuro alcuni commenti in risposta a questo perché ho affrontato gli stessi problemi nella mia curva di apprendimento di Akka. Penso che tu stia chiedendo alcune regole empiriche così le mie sono contenute qui.

Innanzitutto, creare attori è incredibilmente economico; sono molto leggeri Quindi, perché non crearne uno per ogni HttpClient e Account e dare loro nomi adatti derivati ​​dalla loro identità? Questo evita anche di doverli passare tanto, probabilmente, decifrando il codice.

In secondo luogo, mantenere i nomi dei messaggi brevi, concentrati e iniziare con un verbo. Ogni messaggio dovrebbe dire all'attore di fare qualcosa in modo che tu voglia che il nome rifletta quello usando un verbo.

In terzo luogo, serie di messaggi vanno con l'attore.Di solito li dichiaro nell'oggetto compagno della classe attore in modo che utilizzarli sia come ActorClass.MessageName a meno che non sia compreso tra ActorClass e quindi sia solo MessageName.

In quarto luogo, aggiungere un contatore al nome di un attore. Spesso combino un contatore (usa AtomicInteger) con il nome del tipo (Car-1, Car-2, ecc.).

Se la gerarchia è importante per te, ti consiglio di aggiungere solo l'attore principale al nome. Qualcosa come Phone-1-in-Car-7 che significa Phone-1 è contenuto in Car-7. È quindi possibile assemblare la gerarchia sia a livello di codice che manualmente seguendo i collegamenti principali.

Penso che "Messaggio" in ConnectMessage sia ridondante. Basta fare in modo che il nome del messaggio sia "Connect" o anche "ConnectToThing" (qualunque cosa sia, se questo è rilevante).

Non aggiungerei i nomi dei messaggi troppo a quelli che stai suggerendo con Message2. Usa la quantità minima di informazioni per essere utile a chiunque legga quei nomi. Penso che la mancanza di risposta a questo possa essere il risultato di questa parte della tua domanda. L'ho trovato confuso poiché manca un sacco di dettagli.

Spero che questo aiuti.