Modelli di progettazione per la progettazione simultanea agente/attore

Question

Recentemente mi sono trovato in linguaggi alternativi che supportano un attore/agente/l'architettura di condivisione non condivisa, ad es. scala, clojure ecc (il clojure supporta anche lo stato condiviso).

Finora la maggior parte della documentazione che ho letto si concentra sul livello di introduzione. Quello che sto cercando è una documentazione più avanzata lungo la banda dei quattro, ma invece non ho condiviso nulla.

Perché? Aiuta a ingannare il cambiamento nel modo di pensare del design. Semplici esempi sono semplici, ma in un'applicazione Java reale (single threaded) è possibile avere grafici di oggetti con migliaia di membri con relazioni complesse. Ma con lo sviluppo della concorrenza basato sugli agenti, introduce una nuova serie di idee da comprendere quando si progettano sistemi di grandi dimensioni. vale a dire. Granularità dell'agente: la quantità di stato che deve gestire un agente, implicazioni sulle prestazioni ecc. Oppure i loro buoni schemi per il mapping dei grafici di oggetti di stato condivisi al sistema basato su agenti. suggerimenti per la mappatura dei modelli di dominio da progettare. Discussioni non sulla tecnologia ma su come utilizzare MEGLIO la tecnologia nel design (esempi di "complessi" nel mondo reale sarebbero grandiosi).

Answer 1

Ho fatto una domanda simile here che ha avuto alcune risposte ragionevoli che potrebbero essere d'aiuto. Sto guardando i tuoi con attenzione. Non ho ancora trovato qualcosa che mi abbia davvero aiutato, ma sto guardando molto attivamente.

Penso che il cambiamento di mentalità costituisca l'ostacolo più grande al passaggio alle architetture e ai linguaggi concorrenti e fino a quando questo non si risolverà, gli sviluppatori si appresteranno a semplici paradigmi di stile MS. Perché diventi realmente mainstream, ha bisogno di trovare la sua strada nelle scuole e di essere insegnato insieme a C# e VB.

La mia risposta allo 2080 programmers question è "concomitante".

Answer 2

Anche se non riesco a trovare alcun buon esempio del mondo reale che fornisca modelli di design in ordine, ci sono alcuni punti da cui iniziare.

Il primo è quello di avvolgere correttamente la testa attorno ai concetti. Un libro che aiuta a fare questo è Making reliable distributed systems in the presence of software errors scritto da un Erlang Guru Joe Armstrong in cui spiega Programmazione orientata alla concorrenza in un modo molto accessibile. È infatti un dottorato di ricerca. tesi, ma non lasciare che ti spaventi. È di gran lunga più facile da leggere, e piacevole in accordo, rispetto ai libri di testo più comuni.

Guardare i sistemi attuali significa in genere che è necessario imparare troppo sull'effettivo linguaggio , anche per questo ha senso solo per valutare le cose. Per Erlang il documentation fornisce metodologia di progettazione e comportamenti (Erlang speek per le librerie di modelli di progettazione). Questo illustrerà i motivi di progettazione più comunemente utilizzati in questa impostazione. E questi hanno dimostrato di essere efficaci nella costruzione di sistemi su larga scala, vale a dire milioni di linee di codice (paragonabile a un fattore da 4 a 10 di altri linguaggi come Java) e millenni di processi concorrenti in esecuzione su una macchina in cluster distribuiti di macchine. Un recente esempio di un vero sistema live è Facebook Chat.

Per gli altri quadri non posso davvero aiutarti, ho paura.

Answer 3

Un "attore" è esso stesso il modello unificante per la programmazione simultanea (una coda di messaggi asincroni più un contesto di esecuzione per elaborarlo), ma esistono molti schemi di progettazione che aiutano a specificare aspetti o elementi di sistemi basati su agenti. Molti dei più comuni possono essere trovati nell'articolo di Wikipedia su Concurrency Patterns.Alcuni punti salienti:

• Reactor Pattern
• Mediator Pattern
• Scheduler Pattern
• Observer Pattern

Se non avete incontrato già, Akka possono essere di interesse per voi - si tratta di una framework di attori puramente "event-driven" in esecuzione sulla JVM.