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

iv ELENCO DELLE FIGURE

Applicazione web Giornale di bordo per hotel

v

Elenco delle tabelle

9.1 Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Applicazione web Giornale di bordo per hotel

vi ELENCO DELLE TABELLE

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

2 Abstract

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

4 Progetto assegnato

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

6 Introduzione

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

10 Pianificazione

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

14 ColdFusion

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

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

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