La situazione in breve: il sistema riceve vari set di dati da più fonti indipendenti, li elabora in uno o più passi (alcuni tra loro indipendenti, altri no), li salva su database o cache, e/o li invia ad altri sistemi.

La soluzione in breve: dopo aver pensato di affrontare il problema con il paradigma degli attori e dopo essermi documentato su varie scelte disponibili, ho deciso di usare AKKA e per il momento non me ne sono pentito.

Per chi è curioso, seguono alcuni dettagli e qualche indirizzo internet. Tre anni fa durante la riscrittura in Java di una serie di procedure Oracle che era cresciuta eccessivamente, il paradigma degli attori (in particolare AKKA) mi era stato descritto esaltandone le qualità di efficienza e scalabilità su più server; ma all’epoca la soluzione “schietta” in Java aveva delle performance più che sufficienti e l’idea venne accantonata. Adesso i requisiti sono cambiati e soprattutto aumentati, varie volte è stato chiesto di gestire un nuovo input oppure di aggiungere un blocco di operazioni oppure di concatenare in maniera diversa le logiche esistenti: nel progettare la nuova versione del sistema, ho iniziato a disegnare rettangoli per le varie sorgenti di dati o operazioni, collegati da frecce per i passaggi dei dati, per poi esclamare ad un certo punto “ma questi si comportano come gli attori di cui si parlava 3 anni fa!”.

Parte una fase di studio delle caratteristiche di AKKA, inframmezzata ad una ricerca di alternative; la persona che aveva introdotto AKKA nel discorso è attualmente su altri progetti, per cui ho preferito approfondire in maniera autonoma.

Questi sono alcuni link a pagine che mi sono state utili:

Questi in ordine sparso sono stati alcuni punti della mia personale e soggettiva riflessione:

  • la topologia di Storm, fatta di sorgenti di dati e elaborazioni, si adatta molto bene alla modellazione del funzionamento della nuova applicazione, ma con un po’ di lavoro può essere realizzata anche a partire da AKKA (anzi, dirò subito che l’ho già fatto, anche se con alcune semplificazioni in questa prima versione);
  • al contrario alcune capacità di AKKA non sono facilmente realizzabili con Storm, o in altre parole Storm è una specializzazione di AKKA, e potenzialmente potrei voler sfruttare queste caratteristiche (ad esempio, istanziare o fermare attori figli in base alle necessità);
  • Spring-XD ha una struttura di elaborazione lineare, ma a me serve un grafo (un nodo può mandare l’output a più attori e/o ricevere input da più attori);
  • AKKA e Storm mi sono sembrati i sistemi più diffusi e con una più ampia base utenti, seguiti da Spring-XD; tutti e tre sono corredati di una buona documentazione;
  • sia AKKA che Storm hanno la possibilità di scalare su cluster;
  • preferisco un sistema che si integri all’interno dell’applicazione usando Spring, di cui sto approfondendo la conoscenza: Spring-XD lo fa per ovvie ragioni, AKKA ha qualche modo per farlo, Storm no (rimane un sistema esterno all’applicazione che fornisce funzionalità attraverso comunicazione remota);
  • affidabilità nella consegna dei messaggi: AKKA afferma al massimo una volta, Storm almeno una volta… anche se di primo acchito perdere qualche messaggio sembra un grosso problema, avere dei messaggi duplicati può essere peggiore (sia dal punto di vista dell’implementazione delle contromisure sia per la gestione del carico in momenti di picco; comunque per il momento non mi sono accorto di nessun messaggio perso da parte del sistema realizzato);
  • AKKA non è un programma scritto in Java, ma in Scala.

Come ho già detto, la mia preferenza è ricaduta su AKKA e ne sono soddisfatto, nonostante i vari dubbi e problemi iniziali. Al momento ho realizzato un modo per descrivere una “topologia” statica di attori (un grafo orientato in cui i nodi sono attori e gli archi passaggi di dati) definita attraverso la configurazione di bean di Spring.

Comunque ho ancora un sacco di funzionalità di AKKA da provare (gestire dinamicamente gli attori, scalare su cluster, per dire le più importanti dal mio punto di vista).

Annunci