Applicazione web Giornale di bordo per hotel

Trisolini Christian

Ceppi Patrick

CLHS

Ingegneria informatica

(Informatica TP)

M00002 - Progetto di diploma

2018

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

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

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

Elenco delle tabelle

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)

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

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.

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.

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

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.

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.

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.

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.

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

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’apun’ap-plicazione 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 sapespiega-re 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

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.

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.

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.

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 sisrisultan-tema distribuito molto più facile da ragionare e le nuove risultan-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

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

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 hanno bisogno

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,

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.

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 softwarende-re, 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.

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.

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.

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 spermet-tesso linguaggio (Java); per la parpermet-te 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.

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.

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.

32 implementazione

9.2

Descrizione classi

9.2.1

Class Diagrams

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

34 implementazione

Tabella 9.1: Model Nome Descrizione

HoxUser Classe che rappresenta gli utenti all’interno dell’applicativo News Classe che rappresenta le news inserite all’interno dei widget Role Classe che rappresenta i ruoli degli utenti

Tenant Classe che rappresenta i tenant ovvero gli hotel e contiene i dati per la connessione al suo db

Widget Classe che rappresenta il contenitore delle news e a cui è associato un widgetDetails

WidgetDetails 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

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

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.

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

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

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 configuralocalizza-zione 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".

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 è que-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.

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.

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/.