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.
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…
Utilizziamo i cookie per favorire la migliore esperienza di navigazione sul nostro sito. Continuando a utilizzare questo sito accetti l'uso dei cookie.OKMaggiori informazioni
