Università degli Studi di Padova
←
→
Trascrizione del contenuto della pagina
Se il tuo browser non visualizza correttamente la pagina, ti preghiamo di leggere il contenuto della pagina quaggiù
Università degli Studi di Padova
Dipartimento di Matematica "Tullio Levi-Civita"
Corso di Laurea in Informatica
Realizzazione di microservizi REST per
un’applicazione web
Tesi di laurea triennale
Relatore
Prof.Lamberto Ballan
Laureando
Samuele Bisello - #1122438
Anno Accademico 2017-2018
Samuele Bisello - #1122438: Realizzazione di microservizi REST per un’applicazione web, Tesi di laurea triennale, © Dicembre 2018.
Non ho alcun talento particolare. Sono solo appassionatamente curioso.
— Albert Einstein
Dedicato a chi non ha mai smesso di credere in me.Sommario
Il presente documento descrive il lavoro svolto durante il periodo di stage, della
durata di circa trecento ore, dal laureando Samuele Bisello - #1122438 presso l’azienda
Sync Lab S.r.l. L’obiettivo dello stage è lo sviluppo di un backend con architettura a
microservizi con il framework Spring per un’applicazione web riguardante la gestione
della mensa di un collegio.
vRingraziamenti
Innanzitutto, vorrei esprimere la mia gratitudine al Prof. Lamberto Ballan, relatore
della mia tesi, per l’aiuto ed il supporto fornitomi durante la stesura del lavoro.
Desidero ringraziare con affetto i miei genitori per essermi stati vicini in ogni momento
durante gli anni di studio.
Un ringraziamento speciale va alla mia cara nonna Maria Cristina per il costante
sostegno che ha sempre saputo donarmi, in particolar modo durante questo percorso
universitario.
Padova, Dicembre 2018 Samuele Bisello - #1122438
viiIndice
1 Introduzione 1
1.1 Struttura del documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Convenzioni tipografiche . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 L’azienda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Profilo aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.2 Servizi offerti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.3 Settori di impiego . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2 Descrizione dello stage 5
2.1 Introduzione al progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Obiettivi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3 Analisi dei requisiti 9
3.1 Attori del sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Tracciamento dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . 18
4 Tecnologie e strumenti 21
4.1 Architettura a Microservizi . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.1 Descrizione generale . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.1.2 Pattern Principali . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.1.3 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.2 JWT Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.1 Descrizione generale . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.2.3 Struttura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.3 Principi REST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.4 Framework, DB e linguaggio di programmazione . . . . . . . . . . . . . 29
4.4.1 Spring Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.2 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
4.4.3 Java e Maven . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5 Ambienti di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.1 Versionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.2 IDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.5.3 Strumenti per la documentazione . . . . . . . . . . . . . . . . . . 30
ixx INDICE
5 Progettazione 31
5.1 Progettazione Architetturale . . . . . . . . . . . . . . . . . . . . . . . . . 31
5.1.1 Funzionamento del Sistema . . . . . . . . . . . . . . . . . . . . . 32
5.1.2 Flusso di una richiesta . . . . . . . . . . . . . . . . . . . . . . . . 33
5.2 Progettazione di Dettaglio . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5.2.1 Struttura di base dei microservizi . . . . . . . . . . . . . . . . . . 35
5.2.2 Configurazione dei microservizi . . . . . . . . . . . . . . . . . . . 35
5.2.3 Verifica del token . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
5.2.4 Interfacciamento con il DB . . . . . . . . . . . . . . . . . . . . . . 36
5.2.5 Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.3 Documentazione API esposte . . . . . . . . . . . . . . . . . . . . . . . . 39
6 Verifica e validazione 45
6.1 Considerazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.2 Analisi statica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3 Analisi dinamica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.1 Microservizi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.3.2 Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
6.3.3 Integrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
7 Conclusioni 47
7.1 Consuntivo finale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3 Valutazione personale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3.1 Conoscenze acquisite . . . . . . . . . . . . . . . . . . . . . . . . 47
7.3.2 Corsi propedeutici . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Glossario 49
Bibliografia e Sitografia 55Elenco delle figure
1.1 Logo Synclab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1 Gantt - Pianificazione Stage prime 4 settimane . . . . . . . . . . . . . . 7
2.2 Gantt - Pianificazione Stage seconde 4 settimane . . . . . . . . . . . . . 8
4.1 Monolita vs. Microservizi . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2 API REST-based pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3 Application REST-based pattern . . . . . . . . . . . . . . . . . . . . . . . 23
4.4 Messaging pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
4.5 Analisi caratteristiche architettura a microservizi . . . . . . . . . . . . . 24
4.6 Esempio di Jwt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.7 La seguente tabella mostra l’uso dei metodi HTTP con due URL di esempio. 28
5.1 Architettura del sistema. . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 Formato URL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
5.3 Flusso di un richiesta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Elenco delle tabelle
3.1 Tabella del tracciamento dei requisiti funzionali . . . . . . . . . . . . . . 18
3.2 Tabella del tracciamento dei requisiti qualitativi . . . . . . . . . . . . . . 19
3.3 Tabella del tracciamento dei requisiti prestazionali . . . . . . . . . . . . 20
3.4 Tabella del tracciamento dei requisiti di vincolo . . . . . . . . . . . . . . 20
xiCapitolo 1
Introduzione
Questo capitolo presenta la descrizione dell’azienda nella quale ho svolto lo stage, in
particolare viene offerta una panoramica dei processi aziendali e delle metodologie
di sviluppo.
1.1 Struttura del documento
Il secondo capitolo descrive il progetto di stage, gli obiettivi che si propone e la sua
pianificazione;
Il terzo capitolo fornisce l’analisi dei requisiti relativa ai principali obiettivi dello stage;
Il quarto capitolo descrive le tecnologie utilizzate per lo sviluppo del progetto;
Il quinto capitolo approfondisce la progettazione e la codifica dei microservizi;
Il sesto capitolo descrive le metodologie di verifica e validazione adottate;
Nel settimo capitolo sono presenti alcune impressioni personali che concludono la
relazione finale di stage.
1.2 Convenzioni tipografiche
Riguardo la stesura del testo, relativamente al documento sono state adottate le
seguenti convenzioni tipografiche:
• gli acronimi, le abbreviazioni e i termini ambigui o di uso non comune menzionati
vengono definiti nel glossario, situato alla fine del presente documento;
• per la prima occorrenza dei termini riportati nel glossario viene utilizzata la
seguente nomenclatura: Esempio[g] , mentre le successive occorrenze dello
stesso termine vengono rappresentate nel modo seguente: Esempio;
• i termini in lingua straniera o facenti parti del gergo tecnico sono evidenziati con
il carattere corsivo;
12 CAPITOLO 1. INTRODUZIONE
• termini o gruppi di parole che esprimono concetti rilevanti e che non vengono
inseriti nel glossario vengono scritti in grassetto.
1.3 L’azienda
1.3.1 Profilo aziendale
Figura 1.1: Logo Synclab
Sync Lab S.r.l. è una società di consulenza informatica fondata nel 2002 con sedi a
Napoli, Roma, Milano e Padova.
Fin dai primi anni Sync Lab ha avuto una rapida crescita nel mercato ICT, raggiungendo
un organico aziendale di oltre 200 risorse, una solida base finanziaria ed una discreta
diffusione sul territorio.
La grande attenzione posta alla gestione delle risorse umane ha fatto di Sync Lab
un riferimento positivo per quanti volessero avviare o far evolvere professionalmente
la propria carriera.
Il basso turn-over testimonia la voglia dei collaboratori di condividere il progetto
comune, assumendo all’interno di esso ruoli e responsabilità che solo un processo
evolutivo così intenso può offrire.
I ricavi hanno avuto un incremento proporzionale alla crescita dell’azienda beneficiando
dell’approccio adattivo e diversificato al mercato.
1.3.2 Servizi offerti
Sync Lab Srl è un’azienda leader nella consulenza tecnologica, impegnata in un proces-
so di continua identificazione e messa in opera di soluzioni finalizzate alla creazione di
valore. Supporta le esigenze di innovazione di tutte le organizzazioni ed in ogni settore
di mercato nell’ambito dell’Information Technology, con servizi di:
• Business Consultancy
• Project Financing
• IT Consultancy
L’azienda ha come punti di forza la qualità dei servizi offerti (certificazioni ISO 9001,
ISO 14001, ISO 27001, OHSAS 18001) ed un’accurata gestione delle risorse umane.1.3. L’AZIENDA 3 L’approfondita conoscenza di processi e tecnologie, maturata in esperienze altamente significative e qualificanti le fornisce l’expertise e Know How necessari per gestire progetti di elevata complessità, dominando l’intero ciclo di vita: Studio di fattibilità, Progettazione, Implementazione, Governance e Post Delivery. L’offerta di consulenza specialistica trova le punte di eccellenza nella progettazio- ne di architetture Software avanzate, siano esse per applicativi di dominio, per sistemi di supporto al business, per sistemi di integrazione o per sistemi di monitoraggio applicativo/territoriale. Il suo laboratorio RD è sempre al passo con i nuovi paradigmi tecnologici e di comuni- cazione (Big Data Analysis, Cloud Computing, Internet delle Cose, Mobile e Sicurezza IT) per supportare i propri clienti nella creazione ed integrazione di applicazioni, pro- cessi e dispositivi. Le attività in ambito Educational ed RD hanno permesso di acquisire una profonda co- noscenza degli strumenti di finanza agevolata fruendone direttamente ed interagendo con enti di supporto ai progetti innovativi dei propri clienti. L’azienda, grazie alla rete di relazioni a livello nazionale ed internazionale, ha ottenuto importanti finanziamenti in progetti RD (FP7 e H2020) della Comunità Europea. 1.3.3 Settori di impiego Sync Lab si sta specializzando sempre di più in vari settori d’impiego partendo dal mondo banking fino all’assurance con una nicchia importante nell’ambito della sanità in cui vanta un prodotto d’eccellenza per la gestione delle cliniche private. L’azienda inoltre ha recentemente fondato Sync Security, realtà che si occupa espressamente del mondo della cyber security e della sicurezza informatica in genere.
Capitolo 2
Descrizione dello stage
Questo capitolo presenta una descrizione completa del progetto di stage. Vengono
specificati gli obiettivi da raggiungere, la pianificazione delle attività da svolgere ed
i requisiti che devono essere soddisfatti.
2.1 Introduzione al progetto
Lo scopo di questo progetto di stage è lo sviluppo di un backend con architettura a
microservizi di un’applicazione web che agevoli la gestione delle prenotazioni di pasti
giornalieri in un collegio di studenti. Tale progetto è stato commisionato dal collegio
Gregorianum con sede in via Marcel Proust 10 a Padova.
Questo collegio offre un servizio di ristorazione, attivo a pranzo e a cena, accessi-
bile a tutti gli studenti iscritti. Il committente è interessato ad utilizzare una piattaforma
online che permetta agli studenti di effettuare l’accesso con il proprio account (possi-
bilmente utilizzando gli account già esistenti nel sistema informatico del collegio) e di
scegliere il menu che desiderano per ogni giornata.
Il personale della mensa deve poter accedere tramite account di amministrazione e
visualizzare le prenotazioni effettuate, in modo da sapere in anticipo il tipo ed il numero
di pasti da preparare. ll personale dovrà inoltre poter definire il menù per ogni giornata.
Sebbene il risultato finale sia lo sviluppo di un’applicazione composta da un fron-
tend realizzato da altri due stagisti ed il backend oggetto di questo documento, si
vuole porre il focus non soltanto al backend in quanto parte del sistema ma anche
come unità a sè stante, utilizzabile da un qualsiasi client autorizzato. Questo per sotto-
lineare la bontà delle caratteristiche fondanti il progetto (le tecnologie utilizzate), che
verranno poi descritte con maggior dettaglio nelle pagine seguenti.
56 CAPITOLO 2. DESCRIZIONE DELLO STAGE
2.1.1 Obiettivi
Al termine del tirocinio lo stagista dovrà aver prodotto un sistema a microservi-
zi sviluppato con il framework[g] Spring[g] e con il linguaggio di programmazione Ja-
va[g] garantendo ad un client REST[g] funzionalità sufficienti per gestire efficacemente le
prenotazioni della mensa.
Nel piano di lavoro sono stati definiti gli obiettivi di progetto classificati per priori-
tà. I requisiti obbligatori rappresentano la soglia minima per garantire un esito positivo
al progetto di stage. I requisiti desiderabili permettono allo stagista di approfondire
tematiche di rilievo ma non sono indispensabili per la buona riuscita del progetto.
Infine i requisiti facoltativi sono da prendere in considerazione qualora siano stati
completamente soddisfatti i requisiti obbligatori e quelli desiderabili.
• Obbligatori
– O01: Formazione sul framework Spring, in particolare Spring Boot e Spring
Core;
– O02: Formazione di base sul database non relazionale MongoDB[g] ;
– O03: Creazioni dei microservizi, ciascuno con compito ben delineato;
– O04: Creazione dei database associati ai vari microservizi;
– O05: Interfacciamento con il frontend dell’applicazione.
• Desiderabili
– D01: Formazione sul framework Spring Security;
– D01: Test di funzionamento dell’applicazione in condizioni di normale utiliz-
zo.
• Facoltativi
– F01: Studio ed eventuale realizzazione di un API-Gateway[g] per centralizzare
le chiamate da parte del frontend (o da un qualsiasi client REST autorizzato)
ad un’unica entità.2.2. PIANIFICAZIONE 7
2.2 Pianificazione
Di seguito viene presentata la pianificazione temporale delle attività che si dovranno
svolgere durante il periodo di stage ed il relativo diagramma Gantt[g] .
Figura 2.1: Gantt - Pianificazione Stage prime 4 settimane
• Prima settimana [9-15 luglio] - Analisi preliminare e formazione stack tecnolol-
gico
– Definizione dei requisiti del prodotto da realizzare;
– Formazione Spring Core, Spring Boot e Spring MVC.
• Seconda settimana [16-22 luglio]: Avanzamento formazione delle tecnologie
– Continuazione studio (teorico e pratico) del framework Spring;
– Inizio formazione MongoDB;
– Refresh ed approfondimento dell’architettura a microservizi;
– Formazione su ulteriori tecnologie presenti all’interno del progetto.
• Terza settimana [23-29 luglio]: Conclusione formazione e progettazione archi-
tetturale
– Conclusione studio/approfondimento delle varie tecnologie;
– Progettazione architetturale del sistema;
– Progettazione del database.
• Quarta settimana [30 luglio - 5 agosto]: Sviluppo di base del sistema
– Inzio dello svilluppo di base dei vari microservizi;
– Creazione del database;8 CAPITOLO 2. DESCRIZIONE DELLO STAGE
Figura 2.2: Gantt - Pianificazione Stage seconde 4 settimane
– Preparazione della documentazione associata.
• Quinta settimana [6-12 agosto] - Avanzamente sviluppo e primi test
– Avanzamento sviluppo del codice dei microservizi;
– Raffinamento struttura del database;
– Scrittura dei primi test di unità;
– Primi test tra i vari microservizi.
• Sesta settimana [13-19 agosto]: Conclusione sviluppo del sistema
– Conculsione sviluppo dei microservizi;
– Conculsione scrittura dei test di unità;
– Testing del sistema;
– Preparazione della documentazione associata.
• Settima settimana [20-26 agosto]: Test e integrazione dell’infrastruttura
– Test di integrazione sull’intero sistema;
– Analisi delle criticità;
– Raffinamento del prodotto;
– Richiesta feedback dal proponente.
• Ottava settimana [27 luglio - 6 agosto]: Conclusione progetto
– Analisi dei feedback ottenuti;
– Correzione problemi riscontrati.Capitolo 3
Analisi dei requisiti
In questo capitolo vengono presentati i casi d’uso emersi durante l’attività di analisi
svolta con il tutor aziendale ed il proponente e le tabelle di tracciamento dei requisiti.
3.1 Attori del sistema
Lo sviluppo del backend richiede la definizione e l’esposizione di un’interfaccia uti-
lizzabile da un qualsiasi client REST, il quale nel contesto del seguente progetto si
concretizza nell’implementazione di un frontend su misura creato dagli stagisti Ales-
sandro Zangari e Manfredi Smaniotto.
Di seguito verrà utilizzato il termine client in modo generico, indicando non solo
il frontend che utilizza le seguenti API[g] .
Gli attori del sistema sono identificati a seconda del livello di accesso alle risorse fornito
dal sistema:
• Client non autenticato: indica un client che richiede un endpoint senza fornire
alcun tipo di token;
• Client base autenticato: indica un client che richiede un endpoint fornendo un
token che conosente l’accesso a servizi per utente di base;
• Client amministratore autenticato: indica un client che richiede un endpoint
fornendo un token che consente l’accesso a servizi per utente amministratore;
• Client autenticato: indica indifferentemente uno dei due precedenti.
NB: L’attore del sistema come già espressamente descritto non è un umano ma un
software che genera richieste HTTP. Dunque per facilitare la descrizione e la compren-
sione dei requesiti verrà indicato come attore del sistema l’utente mentre utilizza un
client per l’interrogazione degli endpoint messi a disposizione dalle API.
910 CAPITOLO 3. ANALISI DEI REQUISITI
3.2 Casi d’uso
UC1: Autenticazione
Attori Principali: Client non autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta di autenticazione
fornendo le credenziali username e password utilizzando Basic Authentication.
Scenario Principale:
1. L’utente inserisce l’url /authentication/api/login;
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce le credenziali di accesso (username e passsword) codificate con
Base64[g] ;
4. L’utente riceve un messaggio in formato JSON[g] .
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente il JWT.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.
UC2: Lista Utenti Registrati
Attori Principali: Client amministratore autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /authentication/api/users;
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente la lista
degli utenti registrati nel sistema.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.3.2. CASI D’USO 11
UC3: Creazione piatti
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url, metodo http e corpo per eseguire la richiesta fornendo
inoltre il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /dish/api/dishes e il corpo del messaggio;
2. L’utente usa il metodo HTTP POST;
3. L’utente fornisce JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente le
informazioni del piatto appena creato.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.
UC4: Visualizzazione di tutti i piatti
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /dish/api/dishes;
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente le
informazioni dell’oggetto appena creato.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.12 CAPITOLO 3. ANALISI DEI REQUISITI
UC5: Cancellazione di un piatto
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /dish/api/dishes/id specificando l’id del piatto che si
vuole eliminare;
2. L’utente usa il metodo HTTP DELETE;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente il
booleano true.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616, una descrizione del problema,
il timestamp e lo scope ossia l’origine del problema.
UC6: Visualizzazione menu per data
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /menu/api/menuplan?date=year-month-day specificando
la data nella query string;
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente il menu
del giorno inserito.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.3.2. CASI D’USO 13
UC7: Creazione menù
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url, metodo http e corpo per eseguire la richiesta fornendo
inoltre il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /menu/api/menuplan e il corpo del messaggio;
2. L’utente usa il metodo HTTP POST;
3. L’utente fornisce JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente le
informazioni del menù appena creato.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.
UC8: Eliminazione menù
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /menu/api/menuplan/id;
2. L’utente usa il metodo HTTP DELETE;
3. L’utente fornisce JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente il
booleano true.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616, una descrizione del problema,
il timestamp e lo scope ossia l’origine del problema.14 CAPITOLO 3. ANALISI DEI REQUISITI
UC9: Modifica menù
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url, metodo http e corpo per eseguire la richiesta fornendo
inoltre il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /menu/api/menuplan e il corpo del messaggio;
2. L’utente usa il metodo HTTP PUT;
3. L’utente fornisce JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente le
informazioni del menù appena modificato.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.
UC10: Visualizzazione lista piatto-utenti
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url
/reservation/api/reservations/meals?date=year-month-day&moment
=lunch|dinner specificando la data e il pasto nella query string
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente la lista
di piatti ed i corrsipondenti utenti che li hanno prenotati nel giorno e pasto inseriti.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.3.2. CASI D’USO 15
UC11: Visualizzazione lista utenti-piatto
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url
/reservation/api/reservations/users?date=year-month-day&moment
=lunch|dinner specificando la data e il pasto nella query string
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente la
lista degli utenti che hanno effettuato una prenotazione nel giorno e pasto indicati ed i
corrispettivi piatti prenotati.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.
UC12: Creazione prenotazione
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url, metodo http e corpo per eseguire la richiesta fornendo
inoltre il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /reservation/api/reservations e il corpo del messaggio;
2. L’utente usa il metodo HTTP POST;
3. L’utente fornisce JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente le
informazioni della prenotazione appena creato.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.16 CAPITOLO 3. ANALISI DEI REQUISITI
UC13: Eliminazione prenotazione
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url /reservation/api/reservations/id specificando l’id del-
la prenotazione che si vuole eliminare;
2. L’utente usa il metodo HTTP DELETE;
3. L’utente fornisce JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente il
booleano true.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616, una descrizione del problema,
il timestamp e lo scope ossia l’origine del problema.
UC14: Visualizzazione report
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta fornendo inoltre
il token restituito dalla richiesta di autenticazione.
Scenario Principale:
1. L’utente inserisce l’url
/reservation/api/report/download?month=mm&year=aaaa specificando la me-
se e anno nella query string
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato xlsx contenente un
report contenente il resoconto delle prenotazione del mese specificato.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.3.2. CASI D’USO 17
UC15: Verifica token
Attori Principali: Client autenticato.
Precondizioni: L’utente sta utilizzando un client REST.
Descrizione: Vengono inseriti url e metodo http per eseguire la richiesta di autenticazione
fornendo le credenziali username e password utilizzando Basic Authentication.
Scenario Principale:
1. L’utente inserisce l’url /authentication/api/public/check_token;
2. L’utente usa il metodo HTTP GET;
3. L’utente fornisce il JWT;
4. L’utente riceve un messaggio in formato JSON.
Postcondizioni: Il sistema risponde con un messaggio in formato JSON contenente le
informazioni dell’utente.
Estensioni: Il sistema risponde con un messaggio di errore in formato JSON dove viene
specificato un codice di stato secondo lo standard RFC 2616.18 CAPITOLO 3. ANALISI DEI REQUISITI
3.3 Tracciamento dei requisiti
A seguito di un’attenta analisi dei requisiti svolta assieme al proponente ed al tutor
aziendale è stata stilata la tabella che traccia i requisiti in rapporto ai casi d’uso.
Per garantire un preciso tracciamento dei requisiti si è deciso di classificarli in diversi
tipologie, utilizando un codice identificativo per distinguerli:
R[Importanza][Tipologia][Codice]
Ad ogni parametro corrisponde:
• Importanza: può assumere i seguenti valori:
O = indica un requisito obbligatorio;
D = indica un requisito desiderabile;
F = indica un requisito facoltativo.
• Tipologia: può assumere i seguenti valori:
F = requisito funzionale, indica una funzionalità che il sistema deve fornire;
Q = requisito di qualità, indica un elemento che può incrementare la qualità del
sistema;
V = requisito di vincolo, indica un limite a cui il sistema deve attenersi rigorosa-
mente;
P = requisito prestazionale, indica un valore misurabile delle performance del
sistema.
• Codice: numero che identifica il requisito. Deve essere univoco ed è indicato nel
formato X.Y.Z, aumentando in maniera gerarchica da destra a sinistra.
Nelle tabelle 3.1, 3.2, 3.3 e 3.4 sono riassunti i requisiti e il loro tracciamento con i
casi d’uso delineati in fase di analisi.
Tabella 3.1: Tabella del tracciamento dei requisiti funzionali
Requisito Descrizione Use Case
ROF-1 L’utente deve poter autenticarsi nel sistema UC1
ROF-2 L’utente autenticato deve poter visualizzare tutti UC2
gli utenti registrati nel sistema
ROF-3 L’utente deve poter creare un nuovo piatto UC3
ROF-4 L’utente deve poter visualizzare tutti i piatti UC4
disponibili3.3. TRACCIAMENTO DEI REQUISITI 19
ROF-5 L’utente deve poter cancellare un determinato UC5
piatto
ROF-6 L’utente deve poter visualizzare i piatti di un UC6
determinato menù per data
ROF-7 L’utente deve poter creare un nuovo menù UC7
ROF-8 L’utente deve poter eliminare un menù per id UC8
ROF-9 L’utente deve poter modificare un menù per data UC9
ROF-10 L’utente deve poter visualizzare la lista dei piatti UC10
in un determinato giorno e pasto con associati gli
utenti che lo hanno scelto
ROF-11 L’utente deve poter visualizzare la lista degli utenti UC11
con l’elenco dei piatti che hanno prenotato in un
determinato giorno e pasto
ROF-12 L’utente deve poter creare una prenotazione UC12
ROF-13 L’utente deve poter eliminare una prenotazione UC13
ROF-14 L’utente deve poter scaricare il report delle UC14
prenotazioni mensili, indicando il mese
ROF-15 L’utente deve poter verificare la validità del token UC15
Tabella 3.2: Tabella del tracciamento dei requisiti qualitativi
Requisito Descrizione Use Case
ROQ-1 Il sistema deve garantire la sicurezza nella -
trasmissione dei dati
ROQ-2 Il sistema deve utilizzare un meccanismo di auten- -
ticazione con JWT per accedere ai componenti di
servizio
ROQ-3 L’API deve usare Basic access Authentication per -
autenticare l’utente20 CAPITOLO 3. ANALISI DEI REQUISITI
Tabella 3.3: Tabella del tracciamento dei requisiti prestazionali
Requisito Descrizione Use Case
ROP-1 L’accesso ad un endpoint deve avvenire con -
latenza accettabile (Capitolo 4
Tecnologie e strumenti
In questo capitolo vengono presentate tecnologie, pattern e strumenti che stanno al-
la base del progetto di stage. Una visione d’insieme risulta fondamentale per cogliere
a pieno la logica e le scelte implementative del backend sviluppato.
4.1 Architettura a Microservizi
4.1.1 Descrizione generale
L’architettura a microservizi è uno stile architetturale che si è sviluppato a partire
da problemi associati ad altri pattern architetturali piuttosto che come soluzione in
risposta ad un specifico problema progettuale. Infatti si è evoluto da applicazioni
monolitiche sviluppate tramite un’architettura multi-tier[g] e da applicazioni distribuite
implementate con il pattern architetturale orientato ai servizi SOA[g] .
Figura 4.1: Monolita vs. Microservizi
Il percorso evolutivo che ha portato le applicazioni monolitiche verso lo stile architettu-
2122 CAPITOLO 4. TECNOLOGIE E STRUMENTI
rale a microservizi nasce dalla necessità di semplificare notevolmente la manutenibilità
del software. Solitamente le applicazioni monolitiche sono costituite da componenti
strettamente accopiati, che fanno parte di una singola unità di deploy. Ciò le rende
difficili da modificare, testare e distribuire.
Ciò che conduce verso un’architettura a microservizi è anche l’insieme di proble-
matiche riscontrate con applicazioni implementate con un’architettura orientata ai
servizi (SOA). Nonostante il pattern SOA sia molto potente ed offra caratteristiche
quali astrazione, connettività eterogenea ed orchestrazioni dei servizi, risulta essere
molto complesso, difficile da capire e da implementare.
Ci sono alcuni concetti chiave applicabili all’architettura a microservizi:
1. Componente di servizio: piuttosto che pensare a servizi inseriti in un’architettura
a microservizi è meglio pensare a componenti di servizio. Un’architettura a mi-
croservizi è costituita da un insieme di componenti di servizio ridotti e autonomi.
Ogni componente di servizio è indipendente e deve implementare una singo-
la funzionalità di business. In questo modo è possibile variarne la granularità
andando da moduli delle dimensioni di una singola classe fino a raggiungere por-
zioni consistenti dell’applicazione. Progettare al corretto livello di granularità di
componenti è una delle maggiori sfide nell’ambito dell’architettura a microservizi;
2. Unità di deploy separata: ogni componente è implementato come unità a sè
stante, consentendo una distribuzione più semplice attraverso una pipeline
efficace, maggiore scalabilità ed un alto grado di disaccoppiamento all’interno
dell’applicazione;
3. Architettura distribuita: in un’architettura a microservizi tutte le componenti
possono essere distribuite in modo indipendente: sono completamente disac-
coppiate tra loro e vi si accede attraverso protocolli ad accesso remoto quali
REST, SOAP[g] , etc. La natura distribuita di questo pattern architetturale fornisce
caratteristiche superiori di scalabilità e deployment rispetto agli altri modelli
architetturali;
4. Persistenza: Ogni componente di servizio è responsabile della persistenza dei
propri dati. Questo comportamento si distingue dal modello trazionale multi-tier,
dove la persistenza viene gestita su di un livello dedicato.
4.1.2 Pattern Principali
Anche se esistono numerose modalità per implementare un’architettura a microservizi,
sono tre i pattern più comuni e popolari.
1. API basato su REST: utile per esporre piccoli servizi autonomi attraverso delle
API. Consiste di microservizi a grana fine, che contengono uno o due moduli che
svolgono specifiche funzionalità di business indipendenti dagli altri microservizi.
In questa topologia, i vari componenti sono accessibili attraverso un interfaccia
REST.4.1. ARCHITETTURA A MICROSERVIZI 23
Figura 4.2: API REST-based pattern
2. Application basato su REST: a differenza del precedente, le richieste sono rice-
vute attraverso un’interfaccia grafica: solitamente si tratta di una SPA[g] , ossia
un’applicazione web indipendente che da remoto accede ai vari microservizi
attraverso una semplice interfaccia REST. Inoltre in questo modello i componenti
di servizio tendono ad essere piu grandi.
Figura 4.3: Application REST-based pattern
3. Messagistica centralizzata: questa topologia è simile alle precedenti ma invece
di accedere ai microservizi tramite REST, utilizza un broker di messaggi centraliz-
zato. Solitamente questo pattern è utilizzato per applicazioni molto complesse
che richiedono un controllo sofisticato a livello di trasporto tra interfaccia grafica
e componenti di servizio. I vantaggi fondamentali rispetto al modello basato
su REST sono l’uso di meccanisimi di code avanzati, messagistica asincrona,
monitoraggio e miglior scalabilità.24 CAPITOLO 4. TECNOLOGIE E STRUMENTI
Figura 4.4: Messaging pattern
4.1.3 Considerazioni
La seguente tabella riassume le caratteristiche principali inerenti al pattern architet-
turale a microservizi e fornisce una valutazione per ogni qualità rispetto ai più noti
pattern architetturali esistenti.
Figura 4.5: Analisi caratteristiche architettura a microservizi4.2. JWT AUTHENTICATION 25
4.2 JWT Authentication
4.2.1 Descrizione generale
Json Web Token - JWT[g] è uno standard open source noto come RFC 7519. Definisce
una modalità sicura per trasmettere informazioni tra parti disitinte con oggetti JSON.
L’informazione può essere verificata ed è affidabile in quanto firmata digitalmente.
I JWT possono essere firmati utilizzando un chiave segreta con l’uso dell’algoritmo
HMAC[g] oppure algoritmi a chiave pubblica come RSA[g] . Sebbene JWT possa essere
cifrato per garantire segretezza fra le parti, il focus viene posto sulla firma: i token
firmati garantiscono e possono verificare l’integrità delle informazioni contenute al suo
interno, mentre quelli cifrati nascondono tali contenuti al mondo esterno. Quando i
token sono firmati usando algoritmi a chiave pubblica, la firma certifica anche che solo
la parte che detiene la chiave privata è realmente colei che l’ha firmata.
4.2.2 Casi d’uso
Sono due i principali casi d’uso tipici di JWT:
• Autorizzazione: È lo scenario più comune. Solitamente una volta che l’utente è
autenticato nel sistema, ogni successiva richiesta includerà un JWT, consentendo
all’utente di accedere ai microservizi e quindi alle risorse accessibili con quel
tipo di token;
• Scambio di informazioni: JWT è anche una buona modalità per la trasmissione
di informazioni in modo sicuro tra parti disitinte. Poichè il token può essere
firmato con chiave pubblica, si è sicuri che chi lo ha inviato è realmente chi dice
di essere.
4.2.3 Struttura
Nella sua forma più compatta il token è composto da tre stringhe separate da punti:
• Header: l’intestazione generalmente consiste di due parti:
– tipologia: il tipo di token, che è JWT;
– algoritmo: è l’algoritmo utilizzato, come HMAC, SHA256[g] o RSA;
• Payload: contiene le informazioni, dette claims. Si tratta di dichiarazioni relative
ad un’entità (in genere, l’utente) e dati aggiuntivi. Esistono tre tipologie di claims:
– Registrati: sono informazioni predefinite; non sono obbligatorie ma racco-
mandate per fornire una serie di indicazioni utili e interoperabili;
– Pubblici: possono essere definiti a piacimento da coloro che utilizzano il
JWT. Per evitare collisioni dovrebbero essere definite nel registro dei token
JSON;
– Privati: usati per condividere informazioni tra le parti che si impegnano a
utilizzarle e non sono nè claims registrati nè pubblici.26 CAPITOLO 4. TECNOLOGIE E STRUMENTI
• Signature: Per creare la stringa relativa alla firma si deve prendere l’intestazione
codificata, il payload codificato con Base64, una chiave segreta, l’algoritmo
specificato nell’intestazione e firmarlo. La firma viene utilizzata per verificare
che il messaggio non sia stato modificato lungo il percorso e, nel caso di token
firmati con una chiave privata, può anche verificare che il mittente del JWT sia
chi dice di essere.
Il risultato finale è il seguente:
Figura 4.6: Esempio di Jwt4.3. PRINCIPI REST 27
4.3 Principi REST
Representational State Transfer (REST) è un tipo di architettura software per sistemi
distribuiti. Si tratta di un sistema di trasmissione dati su protocollo HTTP[g] .
REST prevede i seguenti principi di progettazione:
• lo stato dell’applicazione e le funzionalità devono essere divise in risorse web;
• ogni risorsa è unica ed indirizzabile usando una sintassi universale per uso nei
link ipertestuali;
• tutte le risorse sono condivise come interfaccia uniforme per il trasferimento di
stato tra client e risorse.
L’approccio REST viene definito dai seguenti vincoli applicati ad un’architettura, la-
sciando libera l’implementazione dei singoli componenti:
• Client-server: un insieme di interfacce uniformi separa i client dai server. Questo
garantisce una separazione netta dei ruoli ed ognuno può concentrarsi solo su
ciò che gli compete;
• Stateless: La comunicazione viene ulteriormente vincolata in modo che nessun
contesto/stato client sia memorizzato sul server. Ogni richiesta contiene tutte le
informazioni necessarie per richiedere il servizio e lo stato della sessione risiede
nel client;
• Cacheable: i client possono fare caching delle risposte, le quali devono definirsi
implicitamente o esplicitamente cacheable in modo da evitare l’utilizzo di uno
stato obsoleto o errato;
• A strati: server intermedi possono migliorare la scalabilità del sistema attraverso
load-balancing o cache distribuite. Offrono inoltre politiche di sicurezza;
• Interfaccia uniforme: un’interfaccia di comunicazione omogenea tra client e
server permette di semplificare e disaccoppiare l’architettura.
Il concetto centrale in REST è quello di risorsa, ossia una fonte di informazioni a cui si
può accedere tramite un identificatore globale detto URI[g] . Per utilizzare queste risorse,
client e server comunicano attraverso protocollo HTTP, scambiandosi rappresentazioni
(solitamente in formato JSON) di queste risorse. Quindi un’applicazione può interagire
con una risorsa conoscendo 2 cose:
• l’URI, ossia l’dentificatore della risorsa;
• l’azione richiesta, che corrisponde ad uno dei metodi del protocollo HTTP.28 CAPITOLO 4. TECNOLOGIE E STRUMENTI
Figura 4.7: La seguente tabella mostra l’uso dei metodi HTTP con due URL di esempio.4.4. FRAMEWORK, DB E LINGUAGGIO DI PROGRAMMAZIONE 29
4.4 Framework, DB e linguaggio di programmazione
4.4.1 Spring Framework
Spring è un framework open source nato per la creazione di applicazioni su piattafor-
ma Java. Si tratta di uno strumento capace di gestire la complessità dello sviluppo
di applicazioni enterprise: leggerezza e modularità lo rendono utilizzabile nella sua
interezza o solo in parte. L’adozione di Spring in un progetto è molto semplice, può
avvenire in maniera incrementale e non ne sconvolge l’architettura esistente.
Il concetto centrale alla base di Spring è il core conteiner: sopra di esso è costrui-
to l’intero framework. I moduli di Core sono responsabili delle funzionalità di Invertion
Of Control (IoC)[g] e Dependency Injection (DI)[g] ed hanno come compito principale
la creazione, gestione e manipolazione di oggetti di qualsiasi natura che, in Spring,
vengono detti beans[g] .
A questo framework sono associati altri progetti, quali Spring Boot, Spring MVC,
Spring Security, Spring Cloud, Spring Data etc. Questi progetti sono stati ideati per
fornire funzionalità aggiuntive al framework base. Nel progetto di stage sono stati
utilizzati:
• Spring Boot: semplifica notevolmente la creazione di applicazioni basate su
Spring di tipo standalone;
• Spring MVC: modulo che offre un’API che consente di esporre endpoint REST in
maniera rapida, oltre che una efficace implementazione del pattern MVC[g] ;
• Spring Security: offre un potente sistema di autenticazione ed un controllo
accessi altamente personalizzabile. È lo standard per proteggere le applicazioni
basate su Spring;
• Spring Cloud: mette a disposizone strumenti per creare rapidamente alcuni dei
modelli comuni nei sistemi distribuiti (i.e. microservizi);
• Spring Data MongoDB: fornisce l’integrazione con il database MongoDB. Una
delle funzionalità chiave di Spring Data MongoDB è il modello centrato su oggetti
Java, detti POJO[g] , che consente di interagire con le collezioni del database
consentendo la scrittura di uno strato di accesso ai dati in stile repository.
4.4.2 MongoDB
MongoDB è un DBMS[g] non relazionale, orientato ai documenti. Viene classificato
come un database di tipo NoSql[g] in quanto si discosta dalla struttura tradizionale
basata su tabelle in favore di documenti in stile JSON con schema dinamico, detto
BSON[g] , rendendo l’integrazione di dati in alcune tipologie di applicazioni più facile e
veloce. È un software libero ed open source.
Il database persenta le seguenti caratteristiche principali:
• Indicizzazione: qualsiasi campo in MongoDB può essere indicizzato;30 CAPITOLO 4. TECNOLOGIE E STRUMENTI
• Alta affidabilità: fornisce alta disponibilità e aumento del carico gestito attraverso
i replica set, ossia copie dei dati;
• Sharding e bilanciamento dati: scala orizzontalmente usando lo sharding[g] ed
include un meccanismo di bilanciamento dei dati, spostando gli intervalli di
dati da uno shard troppo carico ad uno meno carico, in modo da bilanciare la
distribuzione dei dati all’interno del cluster[g] ;
• File storage: può essere usato anche come un file system. Questa funzione è
nota come GridFS;
• Aggregazione: supporta due modalità di aggregazione dei dati: il MapReduce e
l’Aggregration Framework.
4.4.3 Java e Maven
I linguaggio di programmazione utilizzato per lo sviluppo del progetto di stage è Java
v1.8.0. Si tratta di una scelta abbastanza forzata dall’obbligo di utilizzo del framework
Spring. Insieme a Java è stato utilizzato Maven, strumento che aiuta la creazione e la
gestione di qualsiasi progetto basato su Java. Si tratta di un tool che offre le seguenti
funzionalità:
• standardizza la costruzione di progetti;
• offre una chiara descrizione del progetto;
• mette a disposizione una modalalità di condivisione dei file JAR[g] .
4.5 Ambienti di sviluppo
Lo sviluppo è stato interamente svolto sul sistema operativo Ubuntu 18.04 LTS[g] .
4.5.1 Versionamento
Per il versionamento del codice e delle modifiche alla documentazione è stato utilizzato
Git[g] ed un repository privato creato sulla piattaforma GitHub[g] .
4.5.2 IDE
Per la scrittura del codice l’azienda ospitante ha consigliato l’uso dell’IDE[g] Spring Tool
Suite. Tuttavia avendo una conoscenza pregressa dell’IDE Intellij Idea ho preferito
utilizzare questo nella versione 2018.2.
4.5.3 Strumenti per la documentazione
Per la redazione della documentazione è stato utilizzato l’editor LATEX[g] Texmaker
5.0.3 e l’editor per il linguaggio Markdown[g] Typhora 0.9.9.Capitolo 5
Progettazione
In questo capitolo vengono presentate le scelte architetturali e la progettazione del
sistema partendo da una visione d’insieme fino ad arrivare ad un discreto livello di
dettaglio per ogni componente creato.
5.1 Progettazione Architetturale
La progettazione del sistema sviluppato durante lo stage non ha lasciato molto spazio
alla creatività in quanto si è voluto aderire al pattern Application basato su REST ed
alle best-practices fornite da Spring Cloud, il quale ha reso lo sviluppo più agevole.
Inoltre, la scelta di utilizzare questo stile architetturale è stata espressa esplicitamente
dal tutor aziendale.
A partire dalla fase di analisi e di definizione dei requisiti si è deciso di sviluppare
il sistema con 6 componenti di servizio (i.e. microservizi), ognuno responsabile di
specifiche funzionalità di business e dotato di un proprio database.
I microservizi che compongono il sistema sono i seguenti:
• Menu: responsabile della gestione delle risorse relative ai menù della mensa;
• Reservation: responsabile della gestione delle risorse relative alle prenotazioni
della mensa;
• Dish: responsabile della gestione delle risorse relative alle pietanze della mensa;
• Eureka: responsabile del servizio di discovery fornito out-of-the-box da Spring
Cloud;
• Authentication: responsabile del servizio di autenticazione e di gestione degli
utenti;
• API-Gateway: responsabile dell’inoltro e load balancing delle richieste dei client.
3132 CAPITOLO 5. PROGETTAZIONE
NB: Nel seguente progetto non è stata prevista l’esposizione di un endpoint che forni-
sca la funzionalità di creazione utenti, in quanto si presuppone siano già presenti in un
database interno al collegio. Tuttavia, per consentire lo sviluppo locale del sistema, si
è utilizzato un database provvisorio responsabile della persistenza degli utenti. Tale
database viene gestito dal microservizio Authentication.
Figura 5.1: Architettura del sistema.
5.1.1 Funzionamento del Sistema
Per ogni richiesta in arrivo, l’API-Gateway interroga il servizio di discovery gestito dal
microservizio Eureka il quale estrae dall’url della richiesta inoltrata dall’API-Gateway il
nome del microservizio di destinazione. Agisce quindi da server DNS, inoltrando la ri-
chiesta al servizio corretto. Ovviamente ogni microservizio è configurato con un nome
univoco al quale viene associato l’indirizzo IP e la porta dell’host su cui è installato.5.1. PROGETTAZIONE ARCHITETTURALE 33
Il formato degli url è strutturato nel seguente modo:
Figura 5.2: Formato URL.
La risposta inviata dal microservizio di destinazione viene fatta passare attraverso
l’API-Gateway, il quale la inoltra a sua volta al client.
Tutti i microservizi sono protetti da un layer di sicurezza, la cui implementazione
viene agevolata dall’uso di Spring Security, ad eccezione dell’API-Gateway.
Si è scelto di dotare di sicurezza tutti i microservizi tranne il gateway e non viceversa
per garantire un alto livello di affidabilità al sistema anche qualora i componenti do-
vessero venire installati su macchine distinte e non all’interno di un network privato.
Tutte gli endpoint esposti sono accedibili solo se si dispone di un JWT valido, ad ecce-
zione dell’endpoint di login che per ovvi motivi è accedibile da utente non autenticato.
Come specificato precedentemente l’autenticazione viene fatta verificando la pre-
senza degli utenti su un databse locale gestito dal microservizio Authentication e non
sul database del collegio.
5.1.2 Flusso di una richiesta
Per prima cosa un utente si autentica al sistema accorpando all’endpoint di autentica-
zione username e password secondo lo standard Basic access Authentication[g] .
Ogni richiesta viene gestita dall’API-Gateway il quale non effettua alcuna verifica a
livello di firma del token.
La destinazione viene risolta dal microservizio Eureka e la richiesta è poi inoltrata al
microservizio Authentication.
Se l’utente è registrato nel sistema il servizio di autenticazione ritorna un JWT, firmato
con HS256[g] ed un chiave generata ogni qualvolta viene creato un nuovo token e poi
associata all’utente. Ogni JWT espira dopo 40000s (circa 11 ore).
Una volta che si ha a disposizione il token è possibile interagire con qualsiasi ser-
vizio accedibile con quel tipo token. Nello specifico, ogni microservizio quando riceve
una richiesta esegue a sua volta una richiesta al microservizio Authentication per veri-
ficare se il token è valido o meno. In caso positivo viene restituita la risorsa desiderata,
altrimenti viene restituito un messaggio di errore.34 CAPITOLO 5. PROGETTAZIONE
Figura 5.3: Flusso di un richiesta
Non avendo utilizzato un certificato TLS[g] (quindi protocollo HTTPS[g] ), l’uso di Basic
access Authentication per l’autenticazione può risultare poco sicuro. Inoltre seguendo
le best practices relative all’architettura a microservizi è consigliato, pur violando i
principi DRY[g] , la replicazione di codice tra i vari componenti per evitare la comunica-
zione diretta tra essi, a favore delle performance dell’intero sistema. Tuttavia per gli
scopi del progetto tali accorgimenti non sono stati presi in considerazione.Puoi anche leggere
