Luca Vetti Tagliati ha conseguito il PhD presso il Birkbeck College (University of London) e, negli anni, ha applicato la progettazione/programmazione OO, Component Based e SOA in diversi settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java EE. Dopo aver lavorato a lungo nella City di Londra per le più importanti banche di investimento (Goldman Sachs, Lehman, Deutsche Bank, UBS, HSBC) ricopre attualmente l'incarico di Senior Lead Global Architect per importanti gruppi bancari nel sud della Svizzera. Ha collaborato attivamente con John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È autore del libro "UML e ingegneria del software", pubblicato nel 2003 da HOPS/Tecniche Nuove, di "Java Best Practice: i migliori consigli per scrivere codice di qualità", pubblicato nel 2008 dal medesimo editore, e dell'ebook "Verso Java 8. Appunti per lo sviluppatore in Java SE 7" pubblicato da MokaByte e scaricabile dal nostro sito. È stato invitato a Los Angeles e Boston per presentare i suoi paper in convegni inerenti Software Engineering & Architecture. Nel 2015 ha ricevuto il prestigioso ICMG Award.
Maven: Best practice applicate al processo di build e rilascio di progetti Java
I file pom.xml (Project Object Model, modello ad oggetti del progetto) contengono i meta-dati del progetto memorizzati secondo il formato xml. Abbiamo visto quanto sia importante una loro corretta configurazione. Vediamo in questo articolo una serie di utili esempi.
Introduzione
Come visto nel corso degli articoli precedenti, i file pom.xml (Project Object Model, modello ad oggetti del progetto) contengono i meta-dati del progetto memorizzati secondo il formato xml. Pertanto, è importante dar luogo ad una loro corretta configurazione, non solo per consentire una efficace gestione del progetto, ma anche per minimizzare l‘impiego di tempo destinato per la relativa manutenzione. Gli esempi presentati in questo articolo sono stati selezionati per una serie di motivi. In primo luogo, corredando con la dimensione pratica le illustrazioni teoriche degli articoli precedenti, dovrebbero concorrere ad aumentare il grado di comprensione della struttura del file pom.xml, molto articolata e non sempre di immediata comprensione, soprattutto in relazione ad un utilizzo in progetti di medie-grandi dimensioni. Inoltre, dovrebbero evidenziare come, anche per progetti non semplici ed abbastanza articolati, non sia assolutamente necessario impostare tutti gli elementi di questo file ed anzi, come i vari file tendano ad essere piuttosto semplici, soprattutto dopo aver impostato correttamente il pom genitore. Infine, le varie configurazioni riportate dovrebbero prestarsi ad essere riutilizzate, con minime variazioni, in altri progetti, magari in quelli in cui lavorano i vari lettori che, attualmente, non fanno uso di Maven. In effetti, è assolutamente normale preparare i vari file POM per un primo progetto, è poi, con minime variazioni, riutilizzarli in progetti successivi. I vari file pom riportati sono stati corredati con pochissime informazioni supplementari, questo perché la struttura del file è stata abbondantemente discussa nel corso degli articoli precedenti (cfr.: [7] e [8]). Pertanto si rimanda a questi per maggiori informazioni. Inoltre, sebbene i vari file pom riportati di seguito sono stati attinti da un progetto reale, alcune informazioni, come per esempio gli indirizzi URL dei vari server, sono state volontariamente alternate per ovvi motivi di sicurezza/privatezza. Infine, viste le dimensioni dei singoli file pom, per ovvi motivi di spazio, in questo articolo è stato possibile presentarne solo una piccola selezione.
Breve presentazione del progetto
I file pom presentati di seguito appartengono al progetto del sistema Sentinel disegnato per fornire servizi di sicurezza necessari alla gestione di sistemi software di medie grandi dimensioni costituiti da una rete di sistemi cooperanti.ÃÂ I principali servizi forniti, sono:
autenticazione: il sistema verifica che l‘utente/sistema (subject) connesso sia veramente chi/cosa dichiara di essere;
autorizzazione: il sistema verifica che il profilo del subject precedentemente autenticato sia abilitato ad eseguire il determinato servizio (o insieme) richiesto;
data-privacy: il sistema verifica che il subject riceva o tenti di manipolare solo il sottoinsieme di dati di cui possiede l‘autorizzazione.
Figura 1 – Organizzazione del progetto in sotto-progetti. Le linee tratteggiate rappresentano relazioni di dipendenza. Come si può notare, la versione non è specificata in quando la relativa gestione è demandata a Maven.
Il progetto Sentinel è stato organizzato nei seguenti sotto-progetti mostrati in figura 1:
sentinel-security-dto: questo progetto contiene le classi DTO (Data Transfer Object). Questi non sono altro che normali POJO con specifico significato architetturale. In particolare sono utilizzati come parametri dell‘interfaccia business del sistema. Trattandosi di un sistema di sicurezza, in questo contesto i servizi business sono i quelli della sicurezza descritti poc‘anzi. Questi DTO possono essere utilizzati direttamente dai vari client (invocazione RMI) o per mezzo di serializzazioni/deserializzazioni XML/ Web Service (invocazioni: JMS, HTTP);
sentinel-client-api: la libreria prodotta da questo progetto incapsula i DTO del punto precedente e vi aggiunge una serie di servizi messi a disposizione dei sistemi client, come per esempio il marshalling e unmarshalling dei messaggi XML. Ciò permette ai vari client di interagire con il sistema Sentinel impostando una serie di oggetti Java (i DTO del punto 1) e quindi trasformarli da e verso XML attraverso i servizi offerti da questa libreria;
sentinel-admin-dto: è un progetto molto simile al primo (sentinel-security-dto), con l‘eccezione che i DTO contenuti in questo sono utilizzati dai servizi di amministrazione del sistema Sentinel. I due insiemi di DTO sono stati separati in quanto i client business del sistema (gli altri sistemi che necessitano di usufruire dei servizi di sicurezza), tipicamente, non sono assolutamente abilitati ad eseguire i servizi di amministrazione, riservati ai sistemi UI di Sentinel;
sentinel-admin-ui: contiene il codice necessario per l‘implementazione dell‘interfaccia grafica di Sentinel. La tecnologia utilizzata è AJAX, tramite il framework Echo2. Questo progetto, il cui obiettivo è consentire agli utenti abilitati di configurare Sentinel, utilizza gli stessi servizi di Sentinel per risolvere i propri requisiti di sicurezza. Sebbene Sentinel riesegua al proprio interno i vari controlli di sicurezza, questi sono utilizzati anche dalla GUI per migliorare l‘esperienza dell‘utente. Per esempio, servizi di cui l‘utente non possiede i necessari permessi non sono mostrati, i dati vengono pre-filtrati, etc. Questo progetto quindi necessita sia dei DTO amministrativi sia quelli relativi alla sicurezza.
sentinel-security-endpoint: questo progetto include la servlet invocata dai sistemi client per accedere ai servizi Sentinel qualora il protocollo utilizzato sia HTTP (precisamente HTTPS);
sentinel-test-client: l‘obiettivo di questo progetto dovrebbe essere auto-esplicativo.
File pom genitore
Una caratteristica molto potente e unica di Maven, come visto abbondantemente nel corso degli articoli precedenti, è la possibilità di relazionare tra loro i progetti con veri e propri legami di ereditarietà . Questo permette di definire tutta una serie di impostazioni comuni nel file pom genitore e di ereditarle automaticamente nei vari file pom discendenti. La conseguenza è che è possibile sia centralizzare la gestione di molte informazioni (non si tratta solo di evitare una serie di copy&paste, ma anche di assicurarsi che i vari sotto-progetti utilizzino determinate librerie, che le relative versioni sia quelle selezionate, ecc.), sia di semplificare la stesura dei vari pom per i sotto-progetti. Ciò fa sì che questi ultimi, per la maggior parte dei casi, si possano limitare ad accettare le impostazioni del pom genitore. Progetti di dimensioni medio-grandi richiedono di predisporre il file system destinato ad ospitare i vari progetti secondo una determinata gerarchia di directory, in cui la prima, in questo caso denominata sentinel, è la radice dell‘intero progetto. Proprio in questa va memorizzato il file pom genitore. Da questa directory poi è possibile dar luogo una sub-directory per ogni sotto-progetto. Per esempio: …sentinelsentinel-client-api, nella cui root va memorizzato il relativo file pom.
Il file riportato nel precedente listatino non dovrebbe presentare novità rispetto a quanto illustrato nel corso degli articoli precedenti. Pertanto, per eventuali delucidazioni si rimanda ai precedenti articoli di questa serie ([7] e [8]). Ciò nonostante, è possibile evidenziare alcuni interessanti elementi. In primo luogo, è possibile notare che si tratta di un progetto “genitore” in quanto il campo packaging è impostato al valore POM. Inoltre, tutta una serie di impostazioni come quelle relative al scm (software configuation management, software per la gestione della configurazione), ai vari repository, alla gestione delle distribuzioni (distribution management), etc. sono impostate nel solo pom genitore ed ereditate, così come definite, da tutti i file pom discendenti. Mentre per quanto attiene la sezione build, come lecito attendersi, le impostazioni riportate nel file pom genitore tendono a subire alcune variazioni necessarie alla natura del relativo progetto.
Sotto-progetto admin-DTO
Questo progetto è destinato alla produzione della libreria (file JAR) con incluse le classi necessarie all‘interfaccia amministrativa del sistema Sentinel.
ÃÂ ÃÂ sentinel-admin-dto ÃÂ Admin DTO ÃÂ jar ÃÂ http://mbit0164570.develop.mb.net:8085/display/security/home ÃÂ ÃÂ ÃÂ This project includes the DTOs (POJOs) used by the Sentinel architecture. ÃÂ ÃÂ They represent the object graphs used in the admin services ÃÂ ÃÂ exposed by the system itself. ÃÂ
Come si può facilmente notare, il file pom presentato nel listatino precedente è piuttosto semplice, questo sia per via delle limitate esigenze intrinseche del progetto (si tratta esclusivamente di una serie di classi POJO), sia per la presenza del file pom generatore. Questo è dichiarato nella sezione parent definita nelle primissime righe del file.
Sotto-progetto server
Questo progetto è destinato alla produzione del lato server del sistema Sentinel. Come è possibile evincere dalle impostazioni relative alle risorse, alle dipendenze, etc. la tecnologia selezionata è il framework Spring con Hibernate utilizzato per il mapping con il database.
In questo articolo abbiamo presentato un esempio pratico di utilizzo di Maven al fine di fornire una proiezione operativa ai due precedenti articoli riguardanti il file pom.xml. In particolare, si è deciso di utilizzare i file pom preparati per un progetto commerciale denominato Sentinel, il cui scopo è quello di fornire una serie di servizi di sicurezza per sistemi di dimensioni medio-grandi. Per ovvie esigenze di spazio, è stato possibile riportare solo una minima selezione di questi file. In particolare, sono stati selezionati il file pom genitore, quello del sotto progetto relativo ai DTO di amministrazione e quello relativo all‘implementazione server-side. Questi listati, lunghi ma esemplificativi, sono stati scelti per mostrare una serie di importanti caratteristiche di Maven, come per esempio la relazione di ereditarietà , le dipendenze tra file pom, la semplicità con cui è possibile inserire plug-in e così via. La lettura di questo articolo dovrebbe aver facilitato la comprensione sia della struttura dei file pom, sia del loro funzionamento. Inoltre, dovrebbe aver evidenziato come, sebbene la struttura del file pom sia piuttosto articolata e non sempre di facile comprensione, non è assolutamente necessario impostarne tutti gli elementi; anzi, in progetti reali spesso è sufficiente utilizzare un sotto-insieme piuttosto limitato. Pertanto la complessità del file pom è un‘assicurazione di completezza, è l‘ereditarietà di un ampio grado di maturità e non una limitazione di utilizzo. Infine, i vari file pom rappresentano un‘ottima base di partenza per l‘adozione di Maven per progetti attualmente sprovvisti di tale risorsa.
Riferimenti
[1] Giovanni Puliti, “Ant, La Formica Operosa che beve Caffè”, Mokabyte 112 e 113
Luca Vetti Tagliati ha conseguito il PhD presso il Birkbeck College (University of London) e, negli anni, ha applicato la progettazione/programmazione OO, Component Based e SOA in diversi settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java EE. Dopo aver lavorato a lungo nella City di Londra per le più importanti banche di investimento (Goldman Sachs, Lehman, Deutsche Bank, UBS, HSBC) ricopre attualmente l'incarico di Senior Lead Global Architect per importanti gruppi bancari nel sud della Svizzera. Ha collaborato attivamente con John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È autore del libro "UML e ingegneria del software", pubblicato nel 2003 da HOPS/Tecniche Nuove, di "Java Best Practice: i migliori consigli per scrivere codice di qualità", pubblicato nel 2008 dal medesimo editore, e dell'ebook "Verso Java 8. Appunti per lo sviluppatore in Java SE 7" pubblicato da MokaByte e scaricabile dal nostro sito. È stato invitato a Los Angeles e Boston per presentare i suoi paper in convegni inerenti Software Engineering & Architecture. Nel 2015 ha ricevuto il prestigioso ICMG Award.
Luca Vetti Tagliati ha conseguito il PhD presso il Birkbeck College (University of London) e, negli anni, ha applicato la progettazione/programmazione OO, Component Based e SOA in diversi settori che variano dal mondo delle smart card a quello del trading bancario, prevalentemente in ambienti Java EE. Dopo aver lavorato a lungo nella City di Londra per le più importanti banche di investimento (Goldman Sachs, Lehman, Deutsche Bank, UBS, HSBC) ricopre attualmente l'incarico di Senior Lead Global Architect per importanti gruppi bancari nel sud della Svizzera. Ha collaborato attivamente con John Daniels (coautore del libro "UML components") e Frank Armour (coautore del libro "Advanced Use Case Modeling"). È autore del libro "UML e ingegneria del software", pubblicato nel 2003 da HOPS/Tecniche Nuove, di "Java Best Practice: i migliori consigli per scrivere codice di qualità", pubblicato nel 2008 dal medesimo editore, e dell'ebook "Verso Java 8. Appunti per lo sviluppatore in Java SE 7" pubblicato da MokaByte e scaricabile dal nostro sito. È stato invitato a Los Angeles e Boston per presentare i suoi paper in convegni inerenti Software Engineering & Architecture. Nel 2015 ha ricevuto il prestigioso ICMG Award.
