Mokabyte

Dal 1996, architetture, metodologie, sviluppo software

  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Menu
  • Argomenti
    • Programmazione & Linguaggi
      • Java
      • DataBase & elaborazione dei dati
      • Frameworks & Tools
      • Processi di sviluppo
    • Architetture dei sistemi
      • Sicurezza informatica
      • DevOps
    • Project Management
      • Organizzazione aziendale
      • HR
      • Soft skills
    • Lean/Agile
      • Scrum
      • Teoria della complessità
      • Apprendimento & Serious Gaming
    • Internet & Digital
      • Cultura & Società
      • Conferenze & Reportage
      • Marketing & eCommerce
    • Hardware & Tecnologia
      • Intelligenza artificiale
      • UX design & Grafica
  • Ultimo numero
  • Archivio
    • Archivio dal 2006 ad oggi
    • Il primo sito web – 1996-2005
  • Chi siamo
  • Ventennale
  • Libri
  • Contatti
Cerca
Chiudi

Nel numero:

236 febbraio
, anno 2018

Vert.x: un toolkit per applicazioni reattive

IV Parte: Accesso ai dati e comunicazione tra Verticle

Marco Rotondi

Marco Rotondi

Ho cominciato con l'informatica da piccolo, prima con un MSX 2 e poi partendo da un 286 fino alle macchine dei giorni nostri.

Dopo gli studi di informatica, ho cominciato seriamente a lavorare prima con compiti di sistemista e gestione reti in una piccola realtà dell'altomilanese, e poi come come programmatore in varie società di consulenza per clienti medio-grandi.

Uso Java dalla versione 1.0... ma apprezzo anche altri linguaggi di programmazione come C# e php. Credo che non esista un linguaggio in generale migliore degli altri: semplicemente occorre essere bravi a scegliere quello che meglio aiuta a risolvere il problema nel migliore dei modi.

MokaByte

Vert.x: un toolkit per applicazioni reattive

IV Parte: Accesso ai dati e comunicazione tra Verticle

Marco Rotondi

Marco Rotondi

  • Questo articolo parla di: Frameworks & Tools, Programmazione & Linguaggi

Introduzione

Dopo aver visto come testare la nostra applicazione utilizzando le funzionalità del toolkit, passiamo ora a mettere un po’ di codice sul fuoco, andando ad implementare la parte che si occupa dell’accesso ai dati, come provvede alla comunicazione tra differenti Verticle, tramite l’event bus. Questa è una caratteristica nativa di Vert.x [1] creato per la gestione delle comunicazione in maniera asincrona e non bloccante.

Vi ricordo che trovate tutto il codice sul mio account github [2]: viene diviso per branch e riportato sul master (usiamo git) una volta completata la stesura dell’articolo.

 

Il DataBase

Cominciamo come di consueto a creare il nostro branch di lavoro (data-store). Aggiungiamo una directory di nome conf sotto src/main dove andremo a creare il nostro file di configurazione.

Vert.x prevede come formato dei file di configurazione il formato json. Al suo interno definiamo le info per la configurazione del datasource, come nel codice riportato sotto.

vertx-4_fig01

Come potete vedere ho scelto il database H2, che tramite una semplice dipendenza di maven [3] ci permette di avere tutto embedded alla nostra applicazione.

Andiamo ora a modificare il nostro pom.xml per aggiungere le dipendenze necessarie:

  • H2 db (comprende anche i driver di accesso necessari);
  • libreria per la definizione del DataSource;
  • librerie aggiuntive del toolkit di Vert.x per la gestione asincrona dell’accesso ai dati;
  • tool per la creazione automatica del DB e per la gestione delle modifiche in maniera automatica.

Più che altro per non annoiarvi, vi rimando direttamente al codice per vedere quali librerie ho utilizzato,.

Refactoring

Il refactor sul codice parte dalla classe Todo.java: nel metodo start ho modificato la sequenza dei deploy dei nostri verticle inserendo la parte che si occupa della gestione dell’accesso ai dati (DataStoreVerticle.java) e la chiamata a un metodo che inizializza il DB utilizzando Flyway [4].

Il tutto viene gestito tramite una composizione di Future, andando a verificare che tutte e tre le operazioni siano eseguite correttamente e non ci siano errori, come nel codice riportato di seguito.

vertx-4_fig02

Il metodo all di CompositeFuture si occupa di fare la verifica che le tre operazioni che restituiscono una Future siano completate correttamente; in caso di errore, eventualmente il metodo all si occuperà di gestire la fine dell’applicazione.

Non mi dilungo troppo su Flyway che da solo meriterebbe due articoli… Dirò solamente che Flyway è un’ottima libreria di versioning dei DB: ci permette di creare degli script SQL che inizializzano il DB o modificano la situazione attuale in maniera automatica, tenendo traccia del numero di versione applicato. Vi rimando al sito [4] per ulteriori approfondimenti.

Lanciare l’applicazione

Lanciamo la nostra applicazione:

java -jar target\todolist-project-1.0-SNAPSHOT.jar -conf src\main\conf\app-conf.json

Scorrendo i log possiamo vedere Flyway che inizializza il nostro DB e i nostri verticles deployati. L’unica modifica è il metodo deploy che adesso, grazie all’oggetto DeploymentOptions, permette di passare la nostra configurazione esterna.

 

DataStoreVerticle

DataStoreVerticle è la classe che si occupa di eseguire le query SQL per la manipolazione delle nostre “cose da fare”. Essendo la classe implementata come Verticle, per poter comunicare con altri, deve utilizzare per forza un qualche tipo di comunicazione.

Per risolvere questo problema in maniera asincrona e non bloccante, la soluzione che il nostro toolkit ci offre è di utilizzare l’Event Bus.

vertx-4_fig03

Nel codice qui sopra, possiamo vedere lo scheletro della nostra classe con i metodi che si occupano di implementare il CRUD della nostre attività.

Nel metodo start() ci occupiamo di creare una connessione al DB e, una volta ottenutala, passiamo a creare gli handler necessari che sono in ascolto sul nostro bus di eventi. Tutto questo usando le Future [5] di Java.

 

Event Bus

Come più volte detto, Vert.x utilizza un Event Bus per comunicare con i vari verticles o, più in generale, con le varie istanze deployate.

La semplicità di utilizzo è imbarazzante: il toolkit non utilizza nessuno schema particolare per definire gli indirizzi, ma usa semplicemente delle stringhe per definire i canali. Se proprio volgiamo avere una definizione, allora possiamo utilizzare i punti (dot notation) per definire il namespace, per esempio: europe.news.feed

Messaggistica

Come paradigma per mandare i messaggi possiamo usare:

  • Publish / Subscribe
  • Point to Point
  • Request – Response

In base alle nostre esigenze abbiamo quindi massima libertà di utilizzo. Per mantenere semplice l’utilizzo, Vert.x utilizza come metodo per l’invio dei messaggi il “Best Effort Delivery”: detto in parole semplici, non abbiamo la garanzia che il messaggio sia consegnato in caso di problemi che possono esserci sul bus.

Per il contenuto dei messaggi, possiamo utilizzare sia qualunque primitiva che il linguaggio ci mette a disposizione, sia i buffer tipici di Vert.x. La maniera più semplice risulta essere quella di mandare un Json dei nostri dati, ma nulla ci vieta di definire dei codec per implementare il nostro messaggio nella maniera a noi più congeniale.

Implementare il tutto si traduce più o meno con queste righe di codice:

final EventBus eventBus = getVertx().eventBus();
eventBus.consumer(“todo.find.all”, message -> findAll(message, conn.result()));

In soldoni, recuperiamo un’istanza del nostro EventBus e, con una semplice stringa, definiamo di voler “consumare” un canale specifico. Passiamo anche un handler che si occuperà di gestire il messaggio ed eseguire le operazioni necessarie. Il tutto con una logica di tipo Request – Response.

 

Implementazione

Sulla parte puramente di query al DB, non starò molto a dilungarmi: una volta creata la connessione, abbiamo alcuni metodi del Toolkit per eseguire letture, modifiche o l’inserimento di nuovi dati, il tutto con la possibilità di eseguire eventuali store procedure presenti, ma anche di effettuare sequenze di operazioni in batch mode, o di leggere grandi quantità di dati utilizzando gli stream.

Gestendo il tutto dal nostro verticle, abbiamo — automaticamente — la gestione delle connessioni al DB, soprattutto per quanto riguarda la chiusura delle risorse.

Qui sotto potete vedere il codice che gestisce la creazione di una nuova TODO e la lettura di una specifica.

vertx-4_fig04

 

Test: verifica del funzionamento

Ora che abbiamo messo insieme tutti i nostri handler per gestire la parte di lettura e modifica dei dati, verifichiamo che tutto funzioni.

Il problema è che non abbiamo ancora completato la nostra pagina web, almeno io… quindi l’unica soluzione che abbiamo è creare una classe di test e verificare che tutto funzioni.

La classe sarà simile a quella già creata per il test della nostra API Rest: avremo il nostro runner JUnit presente nel toolkit e tramite un oggetto DeploymentOptions, le properties che servono alla creazione del datasource.

Per il test non useremo un DB persistente su filesystem, ma utilizzeremo un DB temporaneo in memoria, in modo tale che ad ogni lancio del test venga ricreato il tutto e si possa avere sempre un ambiente pronto senza dati sporchi.

Per creare quanto appena detto, ci affideremo come visto precedentemente al nostro Flyway. Grazie a Vert.x, il codice effettivo dei test risulta essere semplice.

  • recupero del riferimento all’EventBus;
  • invio dei messaggi sui canali;
  • verifica che l’operazione sia andata a buon fine, utilizzando le assert.

Qui sotto vi mostro due esempi di test, il primo per l’inserimento per una nuova todo e il secondo per la lettura tramite id.

vertx-4_fig05

 

Conclusioni

Siamo quasi arrivati alla fine di questa serie: nella prossima puntata limeremo le ultime cose che, con l’aggiunta del datastore e del codice implementato per far funzionare il nostro test, ha portato qualche problema al Verticle che gestisce la parte di API Rest. Lascio per ora ai lettori il compito di controllare cosa non va. Creeremo infine la nostra pagina web di gestione.

La mia idea è di fornire una carrellata sulle altre caratteristiche del toolkit, mettendo qualche snippet di codice relativo. Alla prossima.

 

Facebook
Twitter
LinkedIn
Marco Rotondi

Marco Rotondi

Ho cominciato con l'informatica da piccolo, prima con un MSX 2 e poi partendo da un 286 fino alle macchine dei giorni nostri.

Dopo gli studi di informatica, ho cominciato seriamente a lavorare prima con compiti di sistemista e gestione reti in una piccola realtà dell'altomilanese, e poi come come programmatore in varie società di consulenza per clienti medio-grandi.

Uso Java dalla versione 1.0... ma apprezzo anche altri linguaggi di programmazione come C# e php. Credo che non esista un linguaggio in generale migliore degli altri: semplicemente occorre essere bravi a scegliere quello che meglio aiuta a risolvere il problema nel migliore dei modi.

Marco Rotondi

Marco Rotondi

Ho cominciato con l'informatica da piccolo, prima con un MSX 2 e poi partendo da un 286 fino alle macchine dei giorni nostri. Dopo gli studi di informatica, ho cominciato seriamente a lavorare prima con compiti di sistemista e gestione reti in una piccola realtà dell'altomilanese, e poi come come programmatore in varie società di consulenza per clienti medio-grandi. Uso Java dalla versione 1.0... ma apprezzo anche altri linguaggi di programmazione come C# e php. Credo che non esista un linguaggio in generale migliore degli altri: semplicemente occorre essere bravi a scegliere quello che meglio aiuta a risolvere il problema nel migliore dei modi.
Tutti gli articoli
Nello stesso numero
Loading...

Sbagliando si impara?

Elenco ragionato degli errori tipici nella pratica Scrum

Git, the stupid content tracker

XI parte: Il “viaggio” dei file e delle loro modifiche

Product Ownership e strategie di prodotto

III parte: Validiamo la nostra strategia

Introduzione alla tecnologia Blockchain

II parte: Primi passi con la Blockchain in Java

Nella stessa serie
Loading...

Vert.x un toolkit per applicazioni reattive

V Parte: La nostra app Vert.x

Vert.x: un toolkit per applicazioni reattive

III parte: Test, test, test

Vert.x: un toolkit per applicazioni reattive

II parte: La nostra prima app in Vert.x

Vert.x: un toolkit per applicazioni reattive

I parte: Storia e caratteristiche

Mokabyte

MokaByte è una rivista online nata nel 1996, dedicata alla comunità degli sviluppatori java.
La rivista tratta di vari argomenti, tra cui architetture enterprise e integrazione, metodologie di sviluppo lean/agile e aspetti sociali e culturali del web.

Imola Informatica

MokaByte è un marchio registrato da:
Imola Informatica S.P.A.
Via Selice 66/a 40026 Imola (BO)
C.F. e Iscriz. Registro imprese BO 03351570373
P.I. 00614381200
Cap. Soc. euro 100.000,00 i.v.

Privacy | Cookie Policy

Contatti

Contattaci tramite la nostra pagina contatti, oppure scrivendo a redazione@mokabyte.it

Seguici sui social

Facebook Linkedin Rss
Imola Informatica
Mokabyte