Quali decisioni di progettazione preferirebbero gli attori di Scala invece di JMS?

Question

Quali sono le differenze utilizzando gli attori Scala anziché JMS?

Ad esempio dal punto di vista delle prestazioni e della scalabilità, che cosa aggiunge il modello Scala Actor rispetto a JMS? In quali casi è più sensato usare Actors piuttosto che JMS, cioè quali problemi gli Attori affrontano che il JMS non può coprire?

Answer 1

Gli attori JMS e Scala condividono una somiglianza teorica, ma non pensano che risolvano necessariamente gli stessi problemi architettonicamente. Gli attori sono pensati per essere un'alternativa leggera alla concorrenza a memoria condivisa in cui le razze e le situazioni di stallo sono generalmente difficili da creare accidentalmente. JMS è un'API sofisticata pensata per estendere la messaggistica diretta, pubblicare/sottoscrivere, transazioni, integrazione EJB, ecc.

L'equivalente JMS più vicino a un attore sarebbe un bean basato su messaggi supportato da un non persistente, non -transactional, non-pub/sottocoda. Lo chiamerò "bean JMS semplice".

Ora, per le vostre domande.

Le prestazioni sono una cosa difficile da discutere poiché JMS è una specifica piuttosto che un'implementazione. In ogni caso, quando si utilizza un bean JMS semplice, mi aspetterei che le prestazioni fossero approssimativamente simili con forse un po 'di vantaggio per l'attore nel tempo e nella memoria. Man mano che si aggiungono funzionalità a JMS come pub/sub, transazioni, ecc, le prestazioni si degraderanno naturalmente ulteriormente, ma poi si sta tentando di confrontare le mele con le arance.

Per quanto riguarda la scalabilità, i bean JMS semplici dovrebbero ridimensionarsi esattamente allo stesso modo degli attori. L'aggiunta di transazioni nel mix JMS danneggerà naturalmente la scalabilità di un importo in base all'ambito delle transazioni.

La domanda più ampia su cosa gli attori non possano fare. Bene, senza sub-transazione o transazioni built-in sembrerebbe che gli attori si sottraggano da JMS - e in generale è vero. Ma ecco la cosa: gli attori hanno bisogno di un codice così piccolo che li possa usare felicemente per una concorrenza a grana molto fine. Nell'ordinario codice Java potrei dire "Non ho voglia di fregare JMS e le sue dipendenze o il codice che richiede ecc. Quindi creerò solo una discussione, userò un blocco e condividerò una struttura dati". Con gli attori della Scala sono molto più propenso a dire "mi farò solo un attore e andrò avanti".

C'è anche una differenza filosofica nel design. Gli attori hanno un concetto semplice e integrato di gerarchie di supervisori. Gli attori sono solitamente usati in un progetto "lascia che si schianti". Se un attore muore per qualche motivo, un altro attore è responsabile di decidere cosa fare al riguardo, come riavviare quell'attore, uccidere un gruppo di attori e ricominciare tutti, o uccidere un gruppo di attori e se stesso in modo che qualche altro attore possa affrontare il problema. Questo tipo di cose può essere aggiunto a JMS, ma non è fondamentale per l'API e deve essere gestito esternamente in qualche modo.

A proposito, per una libreria di attori Scala che si sposta di più nei reami che copre JMS, vedere Akka. Akka porta anche un approccio dichiarativo a molte strategie di gerarchia degli attori comuni.