Applicazione web Giornale di bordo per hotel Studente/i Trisolini Christian Relatore Ceppi Patrick Correlatore - Committente CLHS Corso di laurea Ingegneria informatica (Informatica TP) Modulo M00002 - Progetto di diploma Anno 2018 Data 7 settembre 2018
51
Embed
Applicazione web Giornale di bordo per hoteltesi.supsi.ch/2410/1/DOC_TRISOLINI.pdf · La gestione dei repository è stata affidata ai servizi gratuiti di GitLab.com. In questo caso
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Il linguaggio utilizzato è Java, con il supporto del Framework Spring MVC per creare un’ap-
plicazione web ed avere un ottima portabilità dell’applicazione su vari sistemi operativi e
dispositivi. Il software è stato sviluppato su IntelliJ IDEA 2017.1.3, la JDK utilizzata è la 1.8.
6.3 Ambiente di Sviluppo
L’implementazione del progetto è avvenuta sul portatile personale, con installato xampp (per
apache e mysql) e coldfusion per far funzionare il sistema monolitico di Hoxell.
L’IDE utilizzato è intellij IDEA di jetBrain per lo sviluppo dei microservizi , mentre per studiare
e lavorare sul sistema coldfusion ho utilizzato Eclipse. Come piattaforma d’integrazione ho
scelto di utilizzare gitlab e git come software di controllo della versione.
6.4 Analisi Sistema Attuale
Il sistema è suddiviso in 2 parti: una comune a tutti gli hotel (rappresenta il core dell’ap-
plicazione ed è uguale per tutti gli hotel) e una dedicata a ciascun hotel (contiente tutte le
preferenze e configurazione dell’hotel). Inizialmente ho analizzato il codice per capire com’è
strutturato, qual’è il flusso delle operazioni e quali sono i problemi principali.
La prima cosa che si nota è che il codice è molto complesso e mal strutturato, questo perchè
non c’è una separazione chiara tra il codice lato client e lato server, inoltre c’è un frequente
utilizzo di css inline che distraggono e rendono quasi impossibile capire quale stile abbia un
determinato componente, ho perso molto tempo proprio per questo motivo.
Spostando l’attenzione sul flusso delle operazioni è sorto un’ulteriore problema. Per spiega-
re quest’ultimo è necessario sapere che Coldfusion suddivide la pagina web in più parti che
vengono incluse nella pagina principale tramite il tag <cfinclude>. Il loro approccio è poco
funzionale: -per specificare la pagina corretta da caricare mettono nell’url un parametro li-
sta="nome parte" -il server utilizza un codice di switch di oltre 1000 righe per identificare la
parte corretta da caricare Questo approccio è una chiaro segnale di come l’applicazione sia
Applicazione web Giornale di bordo per hotel
17
cresciuta molto senza aver fatto l’adeguata manutenzione del codice(refactoring e software
enginering)
Avendo osservato la situazione dell’applicazione è chiaro il motivo per cui vogliono cambiare
tecnologia suddividendo l’applicazione in piccoli moduli a sé stanti.
6.5 Analisi Nuovo Sistema
L’attuale sistema è un monolite molto complesso che richiede tempo e risorse per essere ri-
modellato, inoltre è attualmente utilizzato da molti hotel. Ora si vuole passare ad un sistema
a microservizi.Per fare in modo che gli utenti non si rendano conto di questo cambiamen-
to, si è deciso di effettuare questa trasformazione estraendo dal monolite un servizio alla
volta , arrivando a rimanere soltanto con il core, ottenendo cosi un trapasso meno invasivo
possibile.
Rimasti con un’applicazione vuota si può eliminare completamente la parte coldfusion ed
utilizzare soltanto i microservizi già produttivi.
Figura 6.1: Trasformazione da monolite a micro servizi.java
6.5.1 Architettura della Rete
Come mostrato il figura 6.2 l’idea iniziale era una rete in cui il server Coldfusione rimane
locale (fisicamente nell’hotel) mentre un nuovo server esterno gestisce le richieste ai servizi
Spring di tutti gli hotel.
Applicazione web Giornale di bordo per hotel
18 Analisi
Figura 6.2: Network architecture
6.5.2 Architettura del Sistema
Tutto il progetto si basa sul pattern MVC e la suddivisione della struttura rispecchia il concet-
to di base. A partire dal livello main, è possibile notare la prima ed importante divisione tra
le classi Java e le risorse, Spring offre una divisione molto pulita tra controllers, JavaBean,
models, e views.
Applicazione web Giornale di bordo per hotel
19
Figura 6.3: Progetto IntelliJ
Applicazione web Giornale di bordo per hotel
20 Analisi
Applicazione web Giornale di bordo per hotel
21
Capitolo 7
MicroServices
I mirco servizi sono dei piccoli servizi autonomi che lavorano insieme.
Figura 7.1: Schema microservices
7.1 Introduzione
Le CodeBases crescono mentre scriviamo codice e aggiungiamo nuove features. Nel tem-
po, può diventare difficile capire dove la modifica deve essere effettuata a causa della di-
mensione della codebase. In un sistema monolitico, si cerca di rendere il codice più coesivo,
spesso creando astrazioni o moduli. La coesione è un’aspetto importante quando si parla
di micro servizi. I microservizi adottano lo stesso approccio ai servizi indipendenti.
Applicazione web Giornale di bordo per hotel
22 MicroServices
Concentriamo il nostro servizio limitando le funzionalità in base al suo scopo, rendendo
ovvio dove il codice vive per un dato pezzo di funzionalità. E mantenendo questo servizio
focalizzato su un confine esplicito, evitiamo la tentazione di farlo diventare troppo grande,
con tutte le difficoltà associate che questo può introdurre.
7.1.1 Autonomia
Il microservizio è un’entità separata. Potrebbe essere deployata come un servizio isolato
su una piattaforma as a service. Cerchiamo di evitare di mettere più servizi sulla stessa
macchina, anche se questa isolazione può aggiungere dell’overhead, la semplicità risultan-
te rende il nostro sistema distribuito molto più facile da ragionare e le nuove tecnologie sono
in grado di mitigare molte delle sfide associato a questa forma di distribuzione.Tutte le co-
municazioni tra i servizi stessi avvengono tramite chiamate di rete.
Il nostro servizio espone un application programming interface (API) e i servizi di collabora-
zione comunicano con noi tramite tali API. Dobbiamo anche pensare a quale tecnologia è
appropriata per garantire che questo non accoppi i consumatori.
7.2 Benefici Chiave
I vantaggi dei microservizi sono molti e vari e principalmente legati ad un sistema distri-
buito. I microservizi, tuttavia, tendono a raggiungere questi benefici in misura maggiore
principalmente a causa della misura in cui adottano i concetti relativi ai sistemi distribuiti e
all’architettura orientata ai servizi.
7.2.1 Eterogeneità delle Tecnologie
Con un sistema composto da più servizi collaborativi, possiamo decidere di utilizzare diver-
se tecnologie all’interno di ciascuno di essi. Questo ci permette di scegliere lo strumento
giusto per ogni lavoro, piuttosto che dover selezionare un approccio più standardizzato, a
taglia unica, che spesso finisce per essere il minimo comune denominatore.
Se una parte del nostro sistema ha bisogno di migliorare le sue prestazioni, potremmo deci-
dere di utilizzare un diverso stack tecnologico che sia maggiormente in grado di raggiungere
i livelli di prestazioni richiesti. Potremmo anche decidere che il modo in cui archiviamo i nostri
dati deve cambiare per diverse parti del nostro sistema.
Ad esempio, per un social network, potremmo memorizzare i nostri utenti interazioni in
un database graph-oriented per riflettere la natura altamente interconnessa di un grafico
sociale, ma forse i post che gli utenti fanno potrebbero essere archiviati in un database
Applicazione web Giornale di bordo per hotel
23
document-oriented, dando luogo a un’architettura eterogenea come quella mostrata nella
Figura 7.2.
Figura 7.2: I Microservices possono permetterti di sfuttare diverse tecnologie più facilmente
Con i microservizi, siamo anche in grado di adottare la tecnologia più rapidamente e capire
in che modo i nuovi progressi possono aiutarci. Con un’applicazione monolitica, se voglio
provare un nuovo linguaggio di programmazione, database o framework, qualsiasi modifica
avrà un impatto su gran parte del mio sistema. Con un sistema composto da più servizi, ho
molti nuovi posti in cui provare un nuovo pezzo di tecnologia. Posso scegliere un servizio
che è forse a basso rischio e utilizzare la tecnologia lì, sapendo che posso limitare qualsiasi
potenziale impatto negativo. Molte organizzazioni ritengono che questa capacità di assorbi-
re più rapidamente le nuove tecnologie sia un vero vantaggio per loro.
Abbracciando più tecnologie non viene senza un overhead, naturalmente. Alcune organiz-
zazioni scelgono di porre alcuni vincoli sulle scelte linguistiche. Netflix e Twitter, ad esempio,
utilizza principalmente Java Virtual Machine (JVM) come piattaforma, in quanto ha un’ottima
conoscenza dell’affidabilità e delle prestazioni di quel sistema. Sviluppano inoltre librerie e
strumenti per la JVM che rendono operativo su vasta scala molto più facile, ma rende più
difficile per i servizi o client non basati su Java. Ma Né Twitter né Netflix utilizzano solo uno
stack tecnologico per tutti i lavori.
Un altro contrappunto alle preoccupazioni sulla miscelazione in diverse tecnologie è la di-
mensione. Se riesco davvero a riscrivere il mio microservizio in due settimane, potresti
tranquillamente mitigare i rischi legati all’adozione della nuova tecnologia.
7.2.2 Robustezza
In un servizio monolitico, se il servizio fallisce, tutto smette di funzionare. Con un sistema
monolitico, possiamo eseguire l’applicativo su più macchine per ridurre le nostre possibilità
di fallimento, ma con i microservizi possiamo costruire sistemi che gestiscono il fallimento
Applicazione web Giornale di bordo per hotel
24 MicroServices
totale dei servizi..
Dobbiamo stare attenti, tuttavia. Per garantire che i nostri sistemi di microservizi possano
appropriarsi adeguatamente di questa maggiore resilienza, è necessario comprendere le
nuove fonti di insuccesso che i sistemi distribuiti devono affrontare. Le reti possono e falli-
ranno, così come le macchine. Abbiamo bisogno di sapere come gestirlo e quale impatto
(se esiste) dovrebbe avere sull’utente finale del nostro software.
7.2.3 Scaling
Con un servizio ampio e monolitico, dobbiamo ridimensionare tutto insieme. Una piccola
parte del nostro sistema generale è limitata nelle prestazioni, ma se quel comportamento è
bloccato in una gigantesca applicazione monolitica, dobbiamo gestire il ridimensionamento
di tutto come un pezzo. Con servizi più piccoli, possiamo semplicemente scalare quei servizi
che necessitano di ridimensionamento, permettendoci di eseguire altre parti del sistema su
hardware più piccolo e meno potente, come nella Figura 7.3.
Figura 7.3: È possibile scegliere di ridimensionare solo per quei microservizi che ne hannobisogno
7.2.4 Ease of Deployment
Una modifica di una riga a un’applicazione monolitica di milioni di righe richiede che l’intera
applicazione venga distribuita per rilasciare la modifica. Potrebbe essere una distribuzione
di grande impatto e ad alto rischio. In pratica, le distribuzioni a impatto elevato e a rischio
elevato finiscono per accadere raramente a causa di timori comprensibili. Sfortunatamente,
Applicazione web Giornale di bordo per hotel
25
questo significa che i nostri cambiamenti si accumulano e si accumulano tra una release e
l’altra, fino a quando la nuova versione della nostra applicazione che verrà mandata in pro-
duzione ha una grossa mole di cambiamenti. E più grande è il delta tra le versioni, maggiore
è il rischio di sbagliare qualcosa!
Con i microservizi, possiamo apportare una modifica a un singolo servizio e distribuirlo indi-
pendentemente dal resto del sistema. Questo ci consente di implementare il nostro codice
più velocemente. Se si verifica un problema, può essere isolato rapidamente per un sin-
golo servizio, rendendo facile il rollback veloce. Significa anche che possiamo portare le
nostre nuove funzionalità ai clienti più velocemente. Questo è uno dei motivi principali per
cui organizzazioni come Amazon e Netflix utilizzano queste architetture, per garantire che
rimuovano il maggior numero di impedimenti possibili per far uscire il software.
7.2.5 Organizational Alignment
Molti di noi hanno riscontrato problemi associati a team di grandi dimensioni e codebase di
grandi dimensioni. Questi problemi possono essere eliminati quando il team viene distribui-
to. Sappiamo anche che i team più piccoli che lavorano su codebase più piccoli tendono ad
essere più produttivi. I microservizi ci consentono di allineare meglio la nostra architettura
alla nostra organizzazione, aiutandoci a ridurre al minimo il numero di persone che lavora-
no su qualsiasi codebase per raggiungere il sweet spot delle dimensioni e della produttività
della squadra. Possiamo anche spostare la proprietà dei servizi tra i team per cercare di
mantenere le persone che lavorano su un unico servizio.
7.2.6 Composability
Una delle promesse chiave dei sistemi distribuiti e delle architetture orientate ai servizi è
che apriamo nuove opportunità per il riutilizzo delle funzionalità. Con i microservizi, consen-
tiamo di consumare le nostre funzionalità in modi diversi per scopi diversi.
Questo può essere particolarmente importante quando pensiamo a come i nostri consu-
matori utilizzano il nostro software. È finito il momento in cui potevamo pensare in modo
restrittivo al nostro sito Web desktop o all’applicazione mobile. Ora dobbiamo pensare alla
miriade di modi in cui potremmo voler intrecciare funzionalità per il Web, l’applicazione nati-
va, il Web mobile, l’app per tablet o il dispositivo indossabile.
Man mano che le organizzazioni si allontanano dal pensare in termini di canali ristretti a
concetti più olistici di coinvolgimento dei clienti, abbiamo bisogno di architetture che possano
tenere il passo.
Applicazione web Giornale di bordo per hotel
26 MicroServices
7.2.7 Optimizing for Replaceability
Se lavori in un’organizzazione di dimensioni medie o grandi, è probabile che tu sia a co-
noscenza di qualche grande e sfortunato sistema legacy seduto nell’angolo. Quello che
nessuno vuole toccare. Quello che è vitale per come funziona la tua azienda, ma che sem-
bra essere scritto in qualche strana variante di Fortran e funziona solo su hardware che ha
raggiunto la fine della vita di 25 anni fa. Perché non è stato sostituito? Sai perché: è un
lavoro troppo grande e rischioso.
Con i nostri singoli servizi di dimensioni ridotte, il costo per sostituirli con un’implementa-
zione migliore, o addirittura eliminarli del tutto, è molto più facile da gestire. Quante volte
hai cancellato più di cento linee di codice in un solo giorno e non ti preoccupi troppo? Poi-
ché i microservizi spesso hanno dimensioni simili, le barriere che cancellano o eliminano
completamente i servizi sono molto basse.
I team che utilizzano approcci di microservizio sono a loro agio con servizi di riscrittura
completamente necessari quando richiesto e semplicemente uccidendo un servizio quando
non è più necessario. Quando una codebase è lunga solo poche centinaia di righe, è difficile
per le persone essere attaccate a livello emotivo e il costo per sostituirlo è piuttosto ridotto.
7.3 What About Service-Oriented Architecture?
L’architettura orientata ai servizi (SOA) è un approccio di progettazione in cui più servizi
collaborano per fornire alcune funzionalità finali. Un servizio qui in genere significa un pro-
cesso del sistema operativo completamente separato. La comunicazione tra questi servizi
avviene tramite chiamate attraverso una rete piuttosto che chiamate di metodo all’interno di
un limite del processo.
SOA è emerso come un approccio per combattere le sfide delle grandi applicazioni monoliti-
che. È un approccio che mira a promuovere la riusabilità del software; due o più applicazioni
per l’utente finale, ad esempio, potrebbero utilizzare entrambi gli stessi servizi. Mira a rende-
re più facile la manutenzione o la riscrittura del software, in quanto teoricamente possiamo
sostituire un servizio con un altro senza che nessuno lo sappia, a patto che la semantica
del servizio non cambi troppo.
L’approccio microservice è emerso dall’uso nel mondo reale, portando la nostra migliore
comprensione dei sistemi e dell’architettura a fare bene la SOA. Quindi, dovresti invece
considerare i microservizi come un approccio specifico per SOA nello stesso modo in cui
XP o Scrum sono approcci specifici per lo sviluppo di software Agile.
Applicazione web Giornale di bordo per hotel
27
Capitolo 8
Multi Tenancy
Hoxell è un’applicazione che viene utilizzata da più hotel e questo introduce delle complica-
zioni. Ogni hotel: -deve avere il proprio database -deve avere le proprie tabelle -vorrebbe
avere la propria personalizzazione
Una buona soluzione a questo tipo di problematica è implementare un’applicazione "Multi-
tenant". Un’applicazione multitenant è una risorsa condivisa che consente a utenti separati,
o "tenant", di visualizzare l’applicazione come se fosse la loro. Uno scenario tipico che si
presta a un’applicazione multitenant è uno in cui tutti gli utenti potrebbero voler personaliz-
zare l’esperienza utente, ma contemporaneamente hanno gli stessi requisiti di business di
base.
Esistono diversi modelli per ottenere la multi-tenancy in un’applicazione:
• Database per Tenant : Ogni tenant ha il proprio database ed è isolato dagli altri tenant.
• Shared database, Separate Schema: Tutti i tenant condividono un database, ma
hanno i propri schemi di database e le proprie tabelle.
• Shared Database, Shared Schema: Tutti gli tenant condividono un database e tabelle.
Ogni tabella ha una colonna con l’identificatore del tenant, che mostra il proprietario
della riga.
Applicazione web Giornale di bordo per hotel
28 Multi Tenancy
Figura 8.1: Multi-tenancy Models
Ogni modello è un compromesso tra isolamento e condivisione delle risorse, e in questo
caso ho scelto di optare per la seconda soluzione, ovvero un database contenente uno
schema per ogni tenant.
Applicazione web Giornale di bordo per hotel
29
Capitolo 9
implementazione
9.1 Introduzione
Ho sviluppato il progetto in modo da facilitare lo sviluppo di nuovi servizi e in modo itera-
tivo l’eliminazione di coldfusion. Per ciò, ho utilizzato un pattern molto comune durante lo
sviluppo di applicativi web, ossia il Model View Controller.
Per implementare il pattern MVC ho utilizzato "Spring MVC", un framework Java che permet-
te di creare model e controller nello stesso linguaggio (Java); per la parte di visualizzazione
ho realizzato delle pagine HTML dinamiche sfruttando l’integrazione con Thymeleaf.
Il progetto è formato da due progetti: un progetto che si occupa dell’autenticazione degli
utenti (Nome User), e un secondo si occupa esclusivamente della gestione del modulo dia-
ry(Nome diary). Ogni progetto contiene solamente le classi che sono necessarie al servizio,
per esempio diary nel package security conterrà il filtro che controlla se l’utente è autorizzato
mentre user conterrà il filtro di autenticazione.
Figura 9.1: Package Security: Diary a sinistra e User a destra
Applicazione web Giornale di bordo per hotel
30 implementazione
9.1.1 GridStack
Figura 9.2: Interfaccia grafica Diary.java
gridstack.js è una libreria Javascript mobile-friendly per il layout e la creazione di dashboard
drag-and-drop, multi-colonna. gridstack.js ti permette di creare layout droggable e reattivi
compatibili con bootstrap.
Ho utilizzato questa libreria per creare i widget del diary, in modo da renderli completamente
personalizzabili e persistenti.
Quando un widget viene spostato o ridimensionato, la nuova configurazione viene salvata
su database automaticamente e il salvataggio viene segnalato con un "lampeggio" verde
intorno al widget modificato, di modo da rendere il più chiaro possibile che al prossimo cari-
camento i widget saranno visualizzati nell’ultima configurazione salvata.
In alto partendo da sinistra ci sono: un più verde per aggiungere un nuovo widget, un campo
drag-and-drop per eliminare i widget, e un campo di ricerca.
Applicazione web Giornale di bordo per hotel
31
Quando viene premuto il pulsante per aggiungere il widget verrà inserito sempre alla posi-
zione (0,0) della griglia, ovvero in alto a sinistra, e di dimensione 2x2.
Per eliminare un widget basta trascinarlo sulla zona punteggiata rossa con all’interno un
cestino. Il campo di ricerca cercherà se la stringa inserita è presente nel titolo o nel testo di
tutte le news, queste verranno visualizzate al posto dei widget, per farli riapparire bisogna
premere sulla x rossa.
Figura 9.3: Interfaccia grafica Diary.java
Applicazione web Giornale di bordo per hotel
32 implementazione
9.2 Descrizione classi
9.2.1 Class Diagrams
Figura 9.4: Diary Class Diagram
Applicazione web Giornale di bordo per hotel
33
Figura 9.5: User Class Diagram
9.2.2 Model
In questo package sono presenti le classi che rappresentano gli oggetti dell’applicazione.
Queste classi generano le tabelle nel database MySQL tramite le annotazioni di JPA.
9.2.3 Controller
• UserController
– Gestisce il sign-up di un utente tramite l’oggetto SignUpPayload che contiene i
dati inviati tramite il form di login e da server colfusion.
Applicazione web Giornale di bordo per hotel
34 implementazione
Tabella 9.1: ModelNome Descrizione
HoxUser Classe che rappresenta gli utenti all’interno dell’applicativoNews Classe che rappresenta le news inserite all’interno dei widgetRole Classe che rappresenta i ruoli degli utentiTenant Classe che rappresenta i tenant ovvero gli hotel e contiene i
dati per la connessione al suo dbWidget Classe che rappresenta il contenitore delle news e a cui è
associato un widgetDetailsWidgetDetails Classe che rappresenta le caratteristiche del widget all’interno
della griglia (posizione, dimensione)SignUpPayload Classe utilizzata dal modulo user per ricevere i dati di
autenticazione al sign-up
• DiaryController
– gestisce la creazione ed eliminazione dei widget.
– gestisce la griglia dei widget.
– fornisce le pagina html contenente il diary o le pagine di creazione widget e
news.
∗ GET /manage/diary_spring: Ritorna un frammento di pagina contenente i
widget .
∗ POST /save_widget: Salva il widget passato come parametro.
∗ GET /load_widgets: Ritorna tutti i WidgetDetail in una lista.
∗ POST /update_widget: Serve ad aggiornare un widget già esistente quanto
viene modificato (dimensione e posizione).
∗ GET /add_news: ritorna il frammento di pagina contenente il form per la
creazione di una news.
∗ POST /add_news: Serve ad aggiungere o aggiornare una news associata
ad un widget .
∗ GET /edit_news: ritorna il frammento di pagina contenente il form per la
modifica di una news.
∗ GET /load_news: ritorna una lista di news relativa a un widget.
∗ GET /search_news: ritorna una lista di news data dal risultato della ricerca
sul titolo e il testo della news.
∗ POST /delete_widget: serve ad eliminare il widget.
9.2.4 Repository
Comprendono tutti i repository necessari a comunicare con il database per il salvataggio o la
ricerca dei file, tramite l’ORM hibernate precedentemente presentato. Repository sono delle
Applicazione web Giornale di bordo per hotel
35
interfacce che hanno già dei metodi preordinati e permettono di crearne di nuovi secondo le
varie necessità.
9.2.5 Multi Tenancy
Il package multiTenancy contiene delle classi che gestiscono la multi tenancy, devono con-
trollare quale utente fa la richiesta e a quale tenant appartiene di modo da collegarsi al
database corretto, e nel caso le tabelle non sono ancora state create (lo schema non è pos-
sibile crearlo dinamicamente, quindi deve già esistere), bisognerà eseguire degli script che
le inizializzano in modo corretto. La classe MultiTenantInterceptor esegue proprio il lavoro
di intercettare la chiamata al server e apportare tutte le modifiche necessarie.
Figura 9.6: MultiTenantInterceptor.java
Nel mio caso l’interceptor guarda quale tenant ha fatto la richiesta e controlla se è pre-
sente nella lista attuale di tenant gestita da Spring dataSources = MultitenantConfigura-
tion.getResolvedDataSources(); se non è presente, aggiorna la lista, esegue lo script che
Applicazione web Giornale di bordo per hotel
36 implementazione
crea le tabelle sul database, imposta il tenant come corrente e crea un nuovo file nella
cartella tenant in resources contenente tutte le proprietà per la connessione al database.
Questo interceptor non basta crearlo ma bisogna anche aggiungerlo al registro di Spring in
modo che ci pensi lui a gestirlo.
Figura 9.7: WebMvcConfiguration.java
I file creati dall’interceptor servono ad aggiungere direttamente tutti i tenant gia esistenti alla
lista quando si avvia l’applicazione Spring. Ho adottato questa soluzione perchè purtroppo
nella fase di avvio di Spring non è possibile leggere da database, uno dei motivi potrebbe
essere che le repository non sono ancora state configurate/istanziate.
Applicazione web Giornale di bordo per hotel
37
Figura 9.8: MultitenantConfiguration.java
9.2.6 Security
In questo package sono contenute le classi riguardanti la webSecurity di spring e i filtri JWT.
Nel progetto diary è presente la classe JWTAuthorizationFilter che controlla se l’utente è
autorizzato a procedere, prendendo dall’header della richiesta il parametro Authorization.
Mentre nel progetto user è presente la classe JWTAuthenticationFilter che controlla se lo
user è presente su database, se lo è, creerà un nuovo token jwt che dovrà essere utilizzato
Applicazione web Giornale di bordo per hotel
38 implementazione
ad ogni richiesta per poter ottenere l’autorizzazione. La configurazione sul tipo e sulla durata
dek token sono nella classe SecurityConstants.
I filtri andranno successivamente aggiunti alla catena di filtri di spring nella classe WebSe-
curity, in questo modo verranno utilizzati ad ogni richiesta.
Figura 9.9: JWTAuthenticationFilter.java
9.2.7 Localizzazione
Il servizio di localizzazione si rende necessario dal momento in cui gli utenti che vi acce-
dono appartengono a paesi linguisticamente diversi. In precedenza le pagine tradotte era
localizzate sul database di Hoxell ma il committente del progetto preferisce una soluzione
più elegante e pulita. A questo proposito Spring permette la localizzazione tramite un file
Applicazione web Giornale di bordo per hotel
39
di configurazione contenente tutte le parole che vogliamo siano tradotte per l’utente. Come
mostrato nella figura seguente, per scegliere la lingua corretta devo passare un parametro
alla richiesta "lang".
La localizzazione è necessaria se gli utenti che utilizzano l’applicazione parlano lingue dif-
ferenti. In Hoxell le traduzioni sono tenute su database in una tabella e chiaramente non gli
va bene, vogliono qualcosa di più pulito. Spring offre la possibilità di utilizzare la localizza-
zione tramite dei file di proprietà, uno per ciascuna lingua. In questi file di configurazione si
inseriscono tutte le parole che vogliamo siano tradotte, per utilizzarle dobbiamo aggiungere
l’interceptor al manager Spring per settare la lingua che verrà passata come parametro della
richiesta "lang".
Figura 9.10: WebMvcConfiguration.java
Applicazione web Giornale di bordo per hotel
40 implementazione
Applicazione web Giornale di bordo per hotel
41
Capitolo 10
conclusione
10.1 Problematiche
Il problema principale riscontrato durante lo sviluppo è stato analizzare e comprendere il
flusso del codice legacy, per capire dove/come interfacciarmi con la mia applicazione, que-
sta parte ha preso molto tempo. In particolare è stato complesso gestire i conflitti con i loro
css, dato che il mio frammento di pagina viene caricato all’interno della loro. Un altro proble-
ma affrontato durante la fase di sviluppo è stato attendere che il committente decidesse la
forma e il design che voleva per l’applicazione: per esempio la struttura del database riguar-
dante il servizio diary doveva essere rifatta e concordata dai diretti utilizzatori, ma alla fine
ho deciso io come impostarla perchè non mi è arrivata nessuna comunicazione a riguardo.
10.2 Sviluppi futuri
Come si è potuto intuire dallo sviluppo del progetto, il risultato finale del mio lavorò è l’inizio
di un progetto molto più grosso e che dovrà portare all’abbandono completo dell’applica-
zione monolitica. Quindi in futuro andranno sviluppati altri microservizi riguardanti altre
funzionalità.
Per quanto riguarda il diary invece ci sarà da migliorare l’aspetto grafico per renderlo più user
friendly. Bisognerà ripensare a tutta la struttura di alcune tabelle, dopo aver fatto un brain
storm con i colleghi della produzione, per capire cosa i clienti vogliono dal modulo diary e
cosa è giusto tenere. Un’altro punto che sarà sicuramente da rivedere sono i permessi/ruoli,
dato che ora nella loro applicazione usano un metodo molto spartano per i permessi di
visibilità (tramite delle lettere che rappresentano i dipartimenti), sarà necessario stabilire dei
ruoli in modo da filtrare le news in modo corretto.
Applicazione web Giornale di bordo per hotel
42 conclusione
10.3 Considerazioni Finali
L’obbiettivo principale di questo progetto consiste nello studio delle tecnologie open source
disponibili sul mercato per effettuare il refactoring dell’applicazione al minor costo possibi-
le. L’implementazione dell’applicazione web ha portato a galla altre richieste da parte del
committente, con le relative problematiche.
Ad esempio man mano che l’applicazione cresceva sono sorte richieste del tipo multy-
tenancy, localizzazione e autenticazione single sign on. Queste si sono aggiunte all’iniziale
difficoltà di non sapere quali fosserò le caratteristiche ultime che l’applicazione avrebbe
dovuto avere.
In particolare lo sviluppo della multi tenancy è stato molto interessante e costruttivo, dato
che mi ha dato un’idea molto ampia di come funzionano le applicazioni che gestiscono molti
clienti, e di come sia difficile gestirne le richieste specifiche.
Anche se a volte ho incontrato degli ostacoli, ho sempre cercato di fronteggiarli in maniera
individuale poiché penso che sia importante trovare le soluzioni ai problemi da solo, affinché
quando arriverà il momento per me di entrare a far parte del mondo del lavoro sarò pronto ad
affrontare questa nuova esperienza in maniera preparata e in autonomia. L’implementazione
di questo progetto in maniera autonoma mi ha portato notevoli benefici, in quanto penso
abbia contribuito ad una grande crescita personale. Mi ha permesso inoltre di consolidare
la conoscenza di alcuni framework.
I risultati ottenuti hanno soddisfatto le attese, ricevendo quindi un riscontro positivo. Il
lavoro sarà portato avanti e se arriveranno i fondi necessari diventerà parte integrante