ConwayLife Sprint3

1. Realizzare una versione in Java del gioco Life di Conway, come gioco zero-player. Il gioco consiste nell’introdurre una Griglia di Celle il cui stato (cella ‘viva’ o cella ‘morta’) evolve come stabilito dallle regole di ConwayLife.
2. L’utente umano deve poter:
   • specificare la configurazione iniziale della griglia del gioco
   • vedere l’evoluzione del gioco in forma opportuna (si veda Problema della vista del gioco)
   • fermare e far ripartire l’evoluzione del gioco
   • pulire (a gioco fermo) la configurazione della griglia del gioco
3. In particolare, il committente desidera che la vista del gioco (e la configurazione iniziale) sia realizzata mediante una pagina HTML, precisando che:
   • la pagina deve costituire un componente che si relaziona con l’applicazione secondo l'architettura riportata in IoJavalin esterno alla applicazione
   • il gestore del gioco sarà l’utente che ha aperto per primo (owner) una pagina HTML collegata al gioco. In altre parole, solo la pagina dell’owner avrà pulsanti di comando START/STOP/CLEAN/EXIT attivi
   • la pagina HTML deve essere aggiornata in modo automatico man mano il gioco procede
   • un utente non owner che si collega mentre il gioco è in corso, dovrebbe vedere lo stato attuale della griglia in modo corretto
   • il deployment del gioco deve avvenire mediante Docker

E’ opportuno riportare qui lo scenario architetturale menzionato nei requisiti:

E’ necessario avvalersi di un server che deve svolgere due ruoli diversi. Il componente che utilizza il server viene indicato col nome iojavalin.
Nel caso di Javalin esterno, IoJavalin è parte di un componente (un servizio) esterno alla applicazione che deve relazionarsi con il LifeController applicativo mediante messaggi.
L' interazione applicazione-servizio può avvenire in due modi:

1. utlizzando una connessione via Websocket sulla porta 8080
2. utilizzando un diverso protocollo, ad esempio MQTT

Il committente ha già indicato il primo comportamento, almeno per il prototipo iniziale del sistema. In seguito si potrà discutere sulla seconda possibilità.
Come da requisito, la pagina mostra in ogni caso i pulsanti, ma un click su questi provoca effetti solo nel caso in cui la pagina sia owner del gioco.
Per quanto riguarda i piani di test, al momento, sulla base dei requisiti, possiamo limitarci a dire quanto segue:

• attivo l’applcazione su un computer
• sullo stesso computer, attivo due browser su localhost:8080 e verifico che solo uno dei due riesce a controllare il gioco

L'obiettivo è quello di realizzare un sistema distribuito, in cui:

1. Una parte del sistema (l'erogazione di una pagina HTML, in breve GUI) è del tutto nuova (Job1) rispetto allo Sprint 2.
2. Una parte del sistema (l'applicazione) è già disponibile e deve essere solo adattata a interagire con la GUI (Job2).

Le due diverse parti costituiranno un Sistema solo se capaci di interagire in modo opportuno scambiando informazioni via rete in forma di messaggi. L'analisi si concentra sulla natura di questi messaggi per delineare le interazioni tra i componenti, che chiamiamo:

• lifectrl: l'applicazione Java.
• guiserver: il componente che include iojavalin.

Il sistema opera con un vincolo implicito: il livello applicativo utilizza la stessa connessione stabilita per collegarsi al server ai fini dell'output anche per ricevere l'input.

Il Job1 consiste nel realizzare un componente che funge da servizio erogatore di una pagina connessa via WebSocket. Suddividiamo l'analisi in:

• Analisi delle comunicazioni pagina-server
La pagina comunica con il guiserver usando stringhe la cui struttura sintattica permette al server di ricavare oggetti che rispettano l'interfaccia IApplMessage: msg( MSGID, dispatch, SENDER, guiserver, CONTENT, SEQNUM ).
I messaggi inviati dalla pagina sono di tipo fire-and-forget (dispatch).
Il server assegna un nome alla pagina al momento della connessione (es. caller1). La prima pagina connessa viene identificata come owner.
I messaggi hanno la forma msg( do, dispatch, caller1, guiserver, CONTENT, SEQNUM ). Il payload CONTENT può essere: start, stop, clear o cell(x,y).

• Analisi delle comunicazioni server-pagina
Il server invia alla pagina comandi semplici che la pagina è capace di interpretare (codice Javascript):
• ID:name: per assegnare il nome alla pagina.
• cell(X,Y): per commutare una cella.
• [[false,true,...]]: per specificare lo stato di una griglia globale (JSON).

Il Job2 consiste nella realizzazione di una implementazione di IOutDev ( OutInGuiInteraction.java ) che stabilisca una connessione WebSocket con la GUI.
All'avvio, il componente invia un dispatch con id="setcontroller" per informare il server della sua esistenza.
OutInGuiInteraction implementa IObserver. I messaggi (ri)trasmessi dal guiserver vengono percepiti tramite il metodo update e inoltrati al LifeControllerAdhoc.java.
Per aggiornare la GUI, il controller invia dispatch al guiserver: CommUtils.buildDispatch("lifectrl", "eval", CMDDISPLAY, "guiserver").

Il piano di test prevede la verifica della corretta interazione tra i componenti tramite:

• test manuale dell'owner: apertura di più sessioni browser su localhost:8080 per verificare che solo la prima connessione possa inviare comandi START/STOP, mentre le successive rimangano in stato di osservazione.
• verifica messaggistica: utilizzo di CallerServerInteraction.java per simulare l'invio di messaggi dispatch e validare la ricezione lato server.

1. Il file wscanvascontrol.js interpreta i messaggi scambiati via WebSocket:
   • Utilizzo della Canvas HTML5 per la rappresentazione della griglia (20x20), permettendo aggiornamenti grafici fluidi tramite la funzione draw(grid).
   • I comandi (START/STOP/CLEAR/cell) vengono inviati al server nel formato msg(do, dispatch, SENDER, lifectrl, CMD, 0), dove SENDER è l'identificativo univoco assegnato dal server.
2. Il collegamento tra la logica Java e il mondo Web è gestito da OutInGuiInteraction.java:
   • All'avvio, il componente esegue informTheServerAboutController(), inviando un dispatch setcontroller al guiserver per registrare la propria presenza.
   • Essendo un IObserver, percepisce i comandi provenienti dal browser (tramite il server) e li inoltra al LifeControllerAdhoc.
3. Per l'aggiornamento della griglia in GUI si è deciso di utilizzare esclusivamente messaggi di tipo dispatch (asincroni).
   Data la natura del gioco (evoluzione continua), l'uso di request risulterebbe troppo oneroso. Il server invia lo stato della griglia in formato JSON in modalità fire-and-forget a tutti i client connessi.
4. Il requisito dell'utente owner è gestito all'interno di IoJavalin.java:
   • Il server mantiene una lista allConns di tutti i contesti WebSocket attivi.
   • Il primo utente che si connette viene memorizzato in firstCaller (Owner). Solo i messaggi provenienti da questo mittente vengono inoltrati al controller per l'esecuzione.
   • Tuttavia, grazie alla funzione sendToAll(message), ogni aggiornamento della griglia prodotto dal gioco viene inviato a tutte le connessioni attive, permettendo ai non-owner di osservare lo stato corrente correttamente.

La procedura seguita è basata su Docker e prevede:

1. Generazione dell'archivio distribuibile tramite il comando gradlew distTar.
2. Creazione dell'immagine Docker personalizzata: docker build -t gui26html:1.0 ..
3. Esecuzione del container con mappatura della porta 8080: docker run -p 8080:8080 gui26html:1.0.

Utilizzo Docker Compose per coordinare i diversi nodi del sistema (Logica e GUI) tramite il file conway26Guihtml.yaml, avviabile con il comando: docker-compose -f conway26Guihtml.yaml up