Applicazione web Giornale di bordo perhotel
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
i
Indice
1 Abstract 1
2 Progetto assegnato 3
3 Introduzione 5
3.1 Premessa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.2 Scopo del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4 Pianificazione 7
4.1 Pianificazione iniziale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.1.1 Repository manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2 Strumenti e tecnologie utilizzate . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.1 Java . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.2 Mysql . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4.2.3 Spring MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.4 HTML5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.5 CSS3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.6 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.7 JQuery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.8 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.9 Coldfusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.2.10 Gridstack.js . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2.11 Intellij Idea . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5 ColdFusion 11
5.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.2 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
5.3 Svantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.4 Hoxell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Applicazione web Giornale di bordo per hotel
ii INDICE
6 Analisi 15
6.1 Funzionalità Richieste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.2 Analisi tecnologiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.3 Ambiente di Sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.4 Analisi Sistema Attuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.5 Analisi Nuovo Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.5.1 Architettura della Rete . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.5.2 Architettura del Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7 MicroServices 21
7.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.1.1 Autonomia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2 Benefici Chiave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2.1 Eterogeneità delle Tecnologie . . . . . . . . . . . . . . . . . . . . . . 22
7.2.2 Robustezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.2.3 Scaling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.4 Ease of Deployment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7.2.5 Organizational Alignment . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.6 Composability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
7.2.7 Optimizing for Replaceability . . . . . . . . . . . . . . . . . . . . . . . 26
7.3 What About Service-Oriented Architecture? . . . . . . . . . . . . . . . . . . . 26
8 Multi Tenancy 27
9 implementazione 29
9.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9.1.1 GridStack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.2 Descrizione classi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2.1 Class Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.2.2 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2.3 Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.2.4 Repository . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
9.2.5 Multi Tenancy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.2.6 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.2.7 Localizzazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
10 conclusione 41
10.1 Problematiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.2 Sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.3 Considerazioni Finali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Applicazione web Giornale di bordo per hotel
iii
Elenco delle figure
4.1 loghi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1 logo Hoxell . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Snippet codice Coldfusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1 Trasformazione da monolite a micro servizi.java . . . . . . . . . . . . . . . . . 17
6.2 Network architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.3 Progetto IntelliJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1 Schema microservices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 I Microservices possono permetterti di sfuttare diverse tecnologie più facil-
mente . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
7.3 È possibile scegliere di ridimensionare solo per quei microservizi che ne
hanno bisogno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
8.1 Multi-tenancy Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
9.1 Package Security: Diary a sinistra e User a destra . . . . . . . . . . . . . . . 29
9.2 Interfaccia grafica Diary.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
9.3 Interfaccia grafica Diary.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
9.4 Diary Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
9.5 User Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9.6 MultiTenantInterceptor.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
9.7 WebMvcConfiguration.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
9.8 MultitenantConfiguration.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
9.9 JWTAuthenticationFilter.java . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.10 WebMvcConfiguration.java . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Applicazione web Giornale di bordo per hotel
v
Elenco delle tabelle
9.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Applicazione web Giornale di bordo per hotel
1
Capitolo 1
Abstract
Il progetto prevede la realizzazione di un’applicazione web per l’Azienda CHLS, la quale
offre agli hotel un software che integra e semplifica tutte le relazioni interne ed esterne e tutta
la gestione dell’ospitalità in un unico programma interfacciato ad un property management
system (PMS), l’obbiettivo consiste nel rifattorizzare il loro software legacy passando ad una
architettura microservizi utilizzando un framework robusto e flessibile.
Attualmente il software è stato implementato in coldfusion di Adobe,è molto complesso ma
ricco di funzionalità. Si tratta di una piattaforma per applicazioni web con un linguaggio
dedicato di markup semplice e immediato da capire. Il problema principale della soluzione
attuale è il codice: backend e frontend sono mischiati e quindi molto accoppiati, questo ha
reso molto difficile il mantenimento e l’aggiunta di altre funzionalità senza generare bug.
Siccome il codice è troppo complesso per essere riscritto da zero si è deciso di suddividere
l’applicazione in servizi indipendenti utilizzando un framework più moderno e consolidato
(Spring).
The project involves the creation of a web application for the CHLS Company, which of-
fers hotels software that integrates and simplifies all internal and external relations and all
the management of hospitality in a single program interfaced with a property management
system (PMS), the goal is to refactor their legacy software by switching to a microservice
architecture using a robust and flexible framework.
Currently the software has been implemented in Adobe’s coldfusion, it is very complex but
full of functionality. It is a platform for web applications with a dedicated markup language
that is simple and immediate to understand. The main problem of the current solution is the
code: backend and frontend are mixed and therefore very coupled, this has made it very
difficult to maintain and to add other features without generating bugs.
Since the code is too complex to be rewritten from scratch, it was decided to divide the
application into independent services using a more modern and consolidated framework
(Spring)
Applicazione web Giornale di bordo per hotel
3
Capitolo 2
Progetto assegnato
• Descrizione CLHS è un’impresa che si dedica allo sviluppo di soluzioni software per
hotels. Da qualche anno CLHS è presente sul mercato con Hoxell, un’applicazione
web per Hotel focalizzata sulla “Guest Experience” che integra funzioni di comunica-
zione agli ospiti con funzioni operative dell’Hotel. Hoxell è una piattaforma con pro-
iezione internazionale e in continua crescita, che attualmente è usata dal personale
e dagli ospiti di quasi 100 Hotel in Svizzera, Italia, Francia, Inghilterra, Maldive. Di
pari passo con l’acquisizione di nuovi clienti, crescono le necessità di nuovi sviluppi
e adeguamento tecnologico. Attualmente è presente un modulo elementare di ge-
stione del giornale di bordo integrato con l’attività dell’Hotel. Si vorrebbe estendere e
disaccoppiare questo modulo dall’applicazione principale in modo da modernizzarlo
e renderne lo sviluppo indipendente.
• Compiiti
– comprendere l’architettura e le funzionalità del sistema Hoxell
– analizzare i requisiti utente, tecnologici e di integrazione per l’applicazione web
da realizzare
– Definire le funzionalità compatibilmente con le risorse disponibili, il feedback di
uso attuale e la visione di evoluzione del prodotto.
– progettare l’applicazione Giornale di Bordo.
– Rendere l’interfaccia grafica più semplice e personalizzabile.
– Implementare l’applicazione Web responsive (tablet/smartphone) e integrarla
con il sistema Hoxell esistente
– documentare il lavoro svolto
• Obiettivi Progettare e realizzare l’applicazione Giornale di Bordo in modo che sia inte-
grata nel sistema Hoxell ma sia al contempo concepita come un servizio indipendente
Applicazione web Giornale di bordo per hotel
5
Capitolo 3
Introduzione
3.1 Premessa
Nel seguente documento è descritto il progetto di diploma del corso bachelor d’ingegneria
informatica Supsi che consiste nella realizzazione di un prodotto. software in un periodo di
8 settimane. Lo scopo del documento in oggetto è di sostenere la gestione del progetto e, di
conseguenza, all’interno contiene tutte le informazioni raccolte durante lo sviluppo, a partire
dai primi contatti fino alla fine del progetto.
Il progetto è stato commissionato dalla ditta CLHS di lugano, la quale ha la necessità di
rifattorizzare dalle fondamenta il proprio codice, in quanto implementare nuove funzionalità,
applicare migliorie o anche solo fare bug fixing è diventato troppo complesso, tutto ció a
causa del codice legacy e del linguaggio utilizzato e dal tipo di architettura.
3.2 Scopo del progetto
Lo scopo del progetto è quello di capire quali architetutre, tecnologie e framework utilizzare
per rifattorizzare completamente il software attuale. L’applicazione è stata sviluppata per
molti anni e presenta del codice molto complesso , mal strutturato, difficile da gestire. La
strategia che si vuole utilizzare è suddividere il software in servizi ,in modo da collegarli
man mano e rendere il tutto seamless, fino ad arrivare al core del software e ad ottene-
re un sistema a microservizi. Il modulo che verrà rifattorizzato sarà il modulo diary ,che
permette allo staff degli hotel di scrivere news su clienti in arrivo o che sono già arrivati.
Oltre a rifattorizzare il codice backend si vuole ricreare anche il front end rendendolo più
customizzabile.
Applicazione web Giornale di bordo per hotel
7
Capitolo 4
Pianificazione
4.1 Pianificazione iniziale
Ho deciso di affrontare il progetto con la tecnica di programmazione agile, basata su una
continua interazione con il committente, oltre a lavorare direttamente da loro in azienda di
modo da ridurre i tempi nel caso avessi dei dubbi riguardanti il loro applicativo. Questo
permette di adattarsi maggiormente alle richieste e di apportare eventuali modifiche alla
pianificazione iniziale affinché il prodotto finale sia quanto più possibile in accordo con le
esigenze dell’azienda. Ci siamo prefissati degli sprint della durata di una settimana o due
settimane a dipendenza del lavoro da fare e dalla disponibilità degli sviluppatori.
4.1.1 Repository manager
La gestione dei repository è stata affidata ai servizi gratuiti di GitLab.com. In questo caso
l’iscrizione come studente ha permesso di ottenere tutte le funzionalità.
4.2 Strumenti e tecnologie utilizzate
4.2.1 Java
Java Platform, Enterprise Edition è una specifica le cui implementazioni vengono principal-
mente sviluppate in linguaggio Java e utilizzata per lo più nella programmazione web. In
accordo con il committente, ho deciso di utilizzare java come linguaggio di programmazione
in quanto è il più conosciuto ed è stato utilizzato maggiormente durante il bachelor.
4.2.2 Mysql
MySQL è un database relazionale open source. Utilizzato insieme a hibernate permette di
rendere persistenti i dati. Inoltre, supporta il linguaggio SQL.
Applicazione web Giornale di bordo per hotel
8 Pianificazione
4.2.3 Spring MVC
Spring MVC è un framework per realizzare applicazioni web basate sul modello MVC su
piattaforma Java. Ho utilizzato questo framework durante i corsi di applicazione web, in
particolare offre dei moduli di sicurezza, login, connessione al db.
4.2.4 HTML5
HTML5 è un linguaggio di markup per la strutturazione delle pagine web.
4.2.5 CSS3
CSS è un linguaggio per definire la formattazione di documenti HTML.
4.2.6 Bootstrap
Bootstrap è una raccolta di strumenti liberi per la creazione di siti e applicazioni per il Web.
E’ stato utilizzato l’impaginazione delle pagine HTML e migliorarne la navigabilità.
4.2.7 JQuery
jQuery è una libreria JavaScript utilizzata per applicazioni web e ha l’obiettvo di semplificare
la selezione di elementi dal DOM, gestire eventi nonché implementare le funzionalità AJAX,
motivo per cui è stata ampiamente impiegata nello sviluppo dell’applicazione.
4.2.8 Hibernate
Hibernate è un middleware open source per lo sviluppo di applicazioni Java, fornisce un
servizio di ORM, che aiuta nella gestione della persistenza dei dati sul database attraverso
la rappresentazione e il mantenimento su database relazionale di un sistema di oggetti
Java. Questo middleware mi ha permesso di risparmiare molto tempo, fin dalla creazione
delle tabelle sul database. Inoltre, con la sua integrazione in Spring Data il suo utilizzo è
semplificato.
4.2.9 Coldfusion
ColdFusion è una tecnologia server creata da Allaire, ora distribuita da Adobe, che elabora
pagine con l’estensione .cfm, .cfml e .cfc. Si serve del linguaggio di programmazione CFML
(ColdFusion Markup Language), supportato da molti Java EE application server. Venne
distribuito per la prima volta nel 1995, e l’ultima versione è stata resa disponibile nel febbraio
2016. È un linguaggio di scripting server-side, come ad esempio PHP, ASP e Perl. CFML è
basato su html ma ne aumenta le capacità, aggiungendo operatori condizionali, costruzioni
di funzioni e comunicazioni con database ma ne aumenta anche la complessità riducendo
la chiarezza del codice
Applicazione web Giornale di bordo per hotel
9
4.2.10 Gridstack.js
Gridstack.js è un plugin jQuery per widget layout. E’ una griglia drag-n-drop multi colonna.
permette di costruire layout draggable e responsive compatibili con bootstrap.
4.2.11 Intellij Idea
IntelliJ IDEA è un ambiente di sviluppo integrato (IDE) per il linguaggio di programmazione
Java. Sviluppato da JetBrains (prima conosciuto come IntelliJ), è disponibile sia in licenza
Apache che in edizione proprietaria commerciale.
Figura 4.1: loghi
Applicazione web Giornale di bordo per hotel
11
Capitolo 5
ColdFusion
5.1 Introduzione
ColdFusion è una piattaforma di sviluppo rapido per la creazione di moderne applicazioni
web. ColdFusion è progettato per essere espressivo e potente. La caratteristica espressiva
consente di eseguire attività di programmazione a un livello superiore rispetto alla maggior
parte delle altre lingue. Questa caratteristica dà l’integrazione con funzionalità importanti
per le applicazioni web come l’accesso al database, l’accesso a MS Exchange, la creazione
di moduli PDF e altro ancora.
La piattaforma ColdFusion è costruita su Java e utilizza il contenitore J2EE Apache Tomcat.
I file ColdFusion utilizzeranno l’estensione file ".cfc" per gli oggetti e ".cfm" per le pagine.
CFML richiede molto meno sforzo e infrastrutture rispetto al tipico java offrendo allo stesso
tempo un’esperienza di sviluppo significativamente più rapida.
5.2 Vantaggi
• Uno dei principali vantaggi di ColdFusion è che ha una curva di apprendimento veloce
in cui una persona può facilmente cogliere i concetti e come usarli nel giro di pochi
giorni o settimane. Se il programmatore conosce l’HTML, è ancora più facile imparare
ColdFusion poiché l’intero linguaggio è basato su di esso.
• ColdFusion può essere eseguito su Java, consentendo al programma sviluppato di
funzionare in una miriade di sistemi operativi, tra cui Windows e Linux.
• ColdFusion richiede meno codice di qualsiasi altro linguaggio di programmazione.
È facile da leggere. I tag personalizzati in esso contenuti facilitano la gestione dei
modelli di siti Web.
Applicazione web Giornale di bordo per hotel
12 ColdFusion
5.3 Svantaggi
• ColdFusion non è un’applicazione di programmazione "open source". Il suo costo
inizia da quasi 1,300 dollari per la versione più economica e così via.
• Sono state fatte molte critiche riguardo alla scarsa programmazione che è stata fatta
con ColdFusion. Ciò accade perché la natura di ColdFusion di essere un linguaggio di
programmazione facile e veloce, i programmatori spesso sacrificano la qualità rispetto
alla quantità.
• Il fatto di rendere più facile e veloce la programmazione in ColdFusion, ha comportato
un significativo accoppiamento dei suoi componenti. Il backend ed il frontend sono
mischiati fra di loro, in questo modo man mano che l’applicazione cresce diventa
sempre più complessa e legacy, rendendola estremamente difficile da gestire .
5.4 Hoxell
L’azienda CLHS utilizza ColdFusion per l’applicativo Hoxell da circa 10 anni. In questo mo-
mento sono arrivati al punto dove il software è molto complesso e lo stile di programmazione
CFML, oltre alle cattive abitudini dei programmatori, ha reso il codice legacy. Lo sviluppo di
nuove funzionalità e il bug fixing è molto complesso.
Figura 5.1: logo Hoxell
La mia esperienza con il software Coldfusion è stato impegnativo e time consuming. Il
codice è come si dice in gergo uno spaghetti code: come si puo vedere in figura 5.2: non
si capisce dove inizia e dove finisce un’operazione, la maggior parte dei tag html hanno
uno stile inline ed ogni genere di operazione è scritta nella stessa pagina. Tutte queste
problematiche hanno incrementato notevolmente il tempo necessario per capire il flusso
delle operazione e quindi come interfacciarsi con i servizi spring.
Applicazione web Giornale di bordo per hotel
13
Figura 5.2: Snippet codice Coldfusion
Come si puo vedere dallo snippet di codice, in una sola schermata si puo vedere : html,
javascript, chiamate ajax, codice coldfusion per modificare lo stile, css inline e addirittura
query a database per caricare il menu.
Applicazione web Giornale di bordo per hotel
15
Capitolo 6
Analisi
Analisi del monolite e studio delle soluzioni possibili.
6.1 Funzionalità Richieste
• Scomposizione dell’applicazione in microservizi
– microservizi scritti in Spring boot
• Multi tenancy
– Schema separato per ogni tenant
– Nome del database in base al dominio
– Creazione del database automatica
• Personalizzazione pagina (stile widget)
– Dimensione dei widget
– Posizione dei widget
– Salvataggio automatico
– Interfaccia user friendly
• Autenticazione sicura
• Struttura database del diary
• Mantenimento menu originale
• Deployment seamless
Applicazione web Giornale di bordo per hotel
16 Analisi
6.2 Analisi tecnologiche
Il progetto è stato svolto sul pc portatile:
• Asus k501UQ
– OS Name Microsoft Windows 10 Pro Version 10.0.17134 Build 17134
– Processor Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz, 2592 Mhz, 2 Core(s),
4 Logical Processor(s)
– Installed Physical Memory (RAM) 8,00 GB
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
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
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
dell’applicazione Hoxell.
Applicazione web Giornale di bordo per hotel
43
Bibliografia
[1] SUPSI DTI. http://progettistudio.dti.supsi.ch/index.php.
[2] Spring MVC https://spring.io/.
[3] Bootstrap. http://getbootstrap.com/.
[4] GridStack.JS http://gridstackjs.com/.
[5] Sam Newman building microservices designing fine grained systems. 30 Gennaio 2014
[6] ColdFusion http://www.learncfinaweek.com/.
[7] JWT https://jwt.io/.
[8] Multi Tenancy https://bytefish.de/blog/spring_boot_multitenancy/.
Applicazione web Giornale di bordo per hotel
Top Related