Architettura dei sistemi software

Transcript

1 Architettura dei sistemi software Progetto per l A.A. 2018/2019 Premessa Il progetto del corso di Architettura dei sistemi software è relativo alla sperimentazione pratica di alcune tecnologie studiate durante il corso, e riguarda la realizzazione di una semplice applicazione distribuita, composta da due o più servizi, nonché il rilascio di questa applicazione in un opportuno ambiente di esecuzione distribuito. Il progetto va svolto in gruppi di 3 5 studenti (preferibilmente di 4 studenti). Il progetto può essere realizzato in diverse varianti, descritte nelle seguenti sezioni. Progetto 1 Lo scopo di questo progetto è la realizzazione di una semplice applicazione distribuita, composta da una coppia di servizi A e C, che comunicano tra loro tramite invocazioni remote con REST. Per ciascun servizio possono esserci più istanze in esecuzione, ciascuna con un proprio nome (ad esempio, Alice e Carlo). In particolare, il progetto deve essere composto da: Un servizio principale A, che può ricevere richieste da un client HTTP/REST esterno, per le o Per un istanza del servizio A, l operazione POST / (con il corpo della richiesta vuoto) deve invocare l operazione POST / del servizio C, contenente nel corpo una stringa formata dal nome dell istanza del servizio A che ha ricevuto la richiesta, seguita dal nome di un animale scelto casualmente (ad esempio, Alice: Orso ). o Per un istanza del servizio A, l operazione GET / deve invocare l operazione GET / del servizio C, e deve restituire il valore restituito da questa invocazione (vedi dopo). Un servizio secondario C, che può ricevere richieste da un client HTTP/REST, per le o Per un istanza del servizio C, l operazione POST / (contenente nel corpo una stringa che rappresenta il nome di un istanza del servizio A seguito dal nome di un animale) deve memorizzare la stringa ricevuta (in una lista gestita in memoria). o Per un istanza del servizio C, l operazione GET / deve restituire una stringa formata dal nome dell istanza del servizio C che ha ricevuto la richiesta, seguita dal contenuto della lista delle stringhe ricevute tramite l operazione POST (ad esempio, Carlo: [Alice: Orso, Alberto: Lupo] ). Un semplice client HTTP per generare le richieste POST e GET per il servizio A. client A C

2 In particolare: I servizi A e C possono essere realizzati come progetti Spring Boot/Spring Cloud. Il client HTTP può essere realizzato come uno script bash che utilizza curl. Ci possono essere più istanze del servizio A e del servizio C in esecuzione. Ciascuna di esse deve avere un nome diverso (che può essere specificato mediante una proprietà dell applicazione) e deve essere collegata ad una porta casuale di localhost. (Per semplicità, si suggerisce di iniziare con una sola istanza per ciascuno dei servizi A e C.) Il client deve poter accedere al servizio offerto da A sulla porta 8080 di localhost. Si utilizzino le seguenti tecnologie: Eureka (per il service discovery), Ribbon e Feign (per l invocazione del servizio C da parte del servizio A), Zuul (per esporre il servizio offerto da A sulla porta 8080 di localhost). In alternativa, il progetto potrà essere realizzato usando qualunque altra tecnologia per lo sviluppo di servizi REST purché si utilizzino tecnologie analoghe a quelle indicate qui sopra. In ogni caso, ciascuno dei servizi dovrà essere realizzato come una applicazione separata. Esempio Ci sono due istanze di A (Alice e Alberto) e due istanze di C (Carlo e Chiara). Uno scenario di esempio: Il client effettua una richiesta POST / al servizio A. o Questa richiesta viene ricevuta dall istanza Alice, che effettua una richiesta POST / al servizio B con contenuto Alice: Orso. Questa richiesta viene ricevuta dall istanza Carlo, che memorizza la stringa Alice: Orso nella propria lista (per ora è l unico elemento della lista). Il client effettua una richiesta POST / al servizio A. o Questa richiesta viene ricevuta dall istanza Alberto, che effettua una richiesta POST / al servizio C con contenuto Alberto: Lupo. Questa richiesta viene ricevuta dall istanza Carlo, che memorizza la stringa Alberto: Lupo nella propria lista (che ora vale [ Alice: Orso, Alberto: Lupo ]). Il client effettua una richiesta POST / al servizio A. o Questa richiesta viene ricevuta dall istanza Alice, che effettua una richiesta POST / al servizio C con contenuto Alice: Lupo. Questa richiesta viene ricevuta dall istanza Chiara, che memorizza la stringa Alice: Lupo nella propria lista (per ora è l unico elemento della lista). Il client effettua una richiesta GET / al servizio A. o Questa richiesta viene ricevuta dall istanza Alberto, che effettua una richiesta GET / al servizio C. Questa richiesta viene ricevuta dall istanza Carlo, che restituisce la stringa Carlo: [ Alice: Orso, Alberto: Lupo ]. Progetto 2 Lo scopo di questo progetto è la realizzazione di una semplice applicazione distribuita, composta da una terna di servizi A, B e C, che comunicano tra loro tramite invocazioni remote con REST e comunicazione asincrona con Kafka. Per ciascun servizio possono esserci più istanze in esecuzione, ciascuna con un proprio nome (ad esempio, Alice, Barbara e Carlo).

3 In particolare, il progetto deve essere composto da: Un servizio principale A, che può ricevere richieste da un client HTTP/REST esterno, per le o Per un istanza del servizio A, l operazione POST / (con il corpo della richiesta vuoto) deve inviare un messaggio al canale Z, contenente nel corpo una stringa formata dal nome dell istanza del servizio A che ha ricevuto la richiesta, seguita dal nome di un animale scelto casualmente (ad esempio, Alice: Orso ). o Per un istanza del servizio A, l operazione GET / deve invocare l operazione GET / del servizio C, e deve restituire il valore restituito da questa invocazione (vedi dopo). Un servizio secondario B, che è un ascoltatore di messaggi dal canale Z. o Per un istanza del servizio B, la ricezione di un messaggio sul canale Z (contenente nel corpo una stringa che rappresenta il nome di un istanza del servizio A seguito dal nome di un animale), deve invocare l operazione POST / del servizio C, contenente nel corpo una stringa formata dal nome dell istanza del servizio B che ha ricevuto la richiesta, seguita dalla stringa ricevuta (ad esempio, Barbara: Alice: Orso ). Un servizio secondario C, che può ricevere richieste da un client HTTP/REST, per le o Per un istanza del servizio C, l operazione POST / (contenente nel corpo una stringa che rappresenta il nome di un istanza del servizio B seguito dal nome di un istanza A seguito dal nome di un animale) deve memorizzare la stringa ricevuta (in una lista gestita in memoria). o Per un istanza del servizio C, l operazione GET / deve restituire una stringa formata dal nome dell istanza del servizio C che ha ricevuto la richiesta, seguita dal contenuto della lista delle stringhe ricevute tramite l operazione POST (ad esempio, Carlo: [Barbara: Alice: Orso, Bruno: Alberto: Lupo] ). Un semplice client HTTP per generare le richieste POST e GET per il servizio A. ZZ client A B C In particolare: I servizi A, B e C possono essere realizzati come progetti Spring Boot/Spring Cloud. Il client HTTP può essere realizzato come uno script bash che utilizza curl. Ci possono essere più istanze del servizio A, del servizio B e del servizio C in esecuzione. Ciascuna di esse deve avere un nome diverso (che può essere specificato mediante una

4 proprietà dell applicazione) e deve essere collegata ad una porta casuale di localhost. (Per semplicità, si suggerisce di iniziare con una sola istanza per ciascuno dei servizi A, B e C.) Il client deve poter accedere al servizio offerto da A sulla porta 8080 di localhost. Il canale Z può essere gestito tramite Kafka, e deve avere una semantica di tipo point topoint (si configuri il canale con 4 partizioni). Si utilizzino le seguenti tecnologie: Eureka (per il service discovery), Ribbon e Feign (per l invocazione del servizio C da parte dei servizi A e B), Zuul (per esporre il servizio offerto da A sulla porta 8080 di localhost). In alternativa, il progetto potrà essere realizzato usando qualunque altra tecnologia per lo sviluppo di servizi REST purché si utilizzino tecnologie analoghe a quelle indicate qui sopra. In ogni caso, ciascuno dei servizi dovrà essere realizzato come una applicazione separata. Esempio Ci sono due istanze di A (Alice e Alberto), due istanze di B (Barbara e Bruno) e due istanze di C (Carlo e Chiara). Uno scenario di esempio: Il client effettua una richiesta POST / al servizio A. o Questa richiesta viene ricevuta dall istanza Alice, che invia un messaggio al canale Z con contenuto Alice: Orso. Questo messaggio viene ricevuto dall istanza Barbara, che effettua una richiesta POST / al servizio C con contenuto Barbara: Alice: Orso. Questa richiesta viene ricevuta dall istanza Carlo, che memorizza la stringa Barbara: Alice: Orso nella propria lista (per ora è l unico elemento della lista). Il client effettua una richiesta POST / al servizio A. o Questa richiesta viene ricevuta dall istanza Alberto, che invia un messaggio al canale Z con contenuto Alberto: Lupo. Questo messaggio viene ricevuto dall istanza Bruno, che effettua una richiesta POST / al servizio C con contenuto Bruno: Alberto: Lupo. Questa richiesta viene ricevuta dall istanza Carlo, che memorizza la stringa Bruno: Alberto: Lupo nella propria lista (che ora vale [ Barbara Alice: Orso, Bruno: Alberto: Lupo ]). Il client effettua una richiesta POST / al servizio A. o Questa richiesta viene ricevuta dall istanza Alice, che invia un messaggio al canale Z con contenuto Alice: Lupo. Questo messaggio viene ricevuto dall istanza Bruno, che effettua una richiesta POST / al servizio C con contenuto Bruno: Alice: Lupo. Questa richiesta viene ricevuta dall istanza Chiara, che memorizza la stringa Bruno: Alice: Lupo nella propria lista (per ora è l unico elemento della lista). Il client effettua una richiesta GET / al servizio A. o Questa richiesta viene ricevuta dall istanza Alberto, che effettua una richiesta GET / al servizio C. Questa richiesta viene ricevuta dall istanza Carlo, che restituisce la stringa Carlo: [ Barbara Alice: Orso, Bruno: Alberto: Lupo ].

5 Progetto 1D Come nel progetto 1, ma i diversi servizi vanno mandati in esecuzione in contenitori Docker. Progetto 2D Come nel progetto 2, ma i diversi servizi vanno mandati in esecuzione in contenitori Docker. Altri progetti Ciascun gruppo può formulare, se vuole, una propria proposta progetto (che deve comunque avere finalità simili a quelle dei progetti illustrati in questo documento). In ogni caso, queste proposte di progetti alternativi devono essere autorizzate dal docente. Modalità di svolgimento e di consegna del progetto Ciascun gruppo dovrà interagire con il docente in questo modo: Ciascun gruppo dovrà comunicare al docente, per posta elettronica, la composizione del proprio gruppo, le tecnologie che si pensano di utilizzare (se diverse da quelle proposte), oppure la propria proposta di progetto (se diversa da quelli illustrati in questo documento). Poi, ciascun gruppo dovrà realizzare e verificare (sul proprio computer) la propria applicazione distribuita. Infine, ciascun gruppo dovrà caricare la propria applicazione distribuita su GitHub (o altro servizio di condivisione del codice). In particolare, dovrà caricare tutto il codice sorgente dell applicazione, oltre ad ogni script necessario per la compilazione e costruzione dell applicazione (Maven o Gradle), i file Dockerfile e gli eventuali file per Docker Compose, nonché gli script per mandare in esecuzione l applicazione. Al completamento del progetto, l URI su GitHub del codice dell applicazione dovrà essere comunicato al docente per posta elettronica.