Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee

Università degli Studi di Trieste
Facoltà di Ingegneria

Tesi di Laurea Triennale in Ingegneria Informatica

Studio e Realizzazione di un SW per la gestione
dei profili e delle versioni di applicazioni web
in ambiente JEE.

Relatore: Laureando:
Prof. Maurizio FERMEGLIA Francesco FERONT

Anno Accademico: 2009/2010

Pag. 1/39

A me stesso.

Fanculo tutti!

1 - Introduzione Pag. 2/39

Indice generale
1 - Introduzione.................................................................................................................4
2 - Sommario.....................................................................................................................5
3 - Analisi...........................................................................................................................6
3.1 - Maven...................................................................................................................6
3.1.1 - Struttura dei file Pom.xml.............................................................................7
3.1.2 - SCM, Software Configuation Management..................................................8
3.1.3 - Repository.....................................................................................................8
3.1.4 - Property e Filtraggio delle Risorse..............................................................10
3.1.5 - Profili...........................................................................................................11
3.2 - Gestione delle Versioni.......................................................................................12
3.2.1 - SVN, Subversion..........................................................................................13
3.3 - Continuous Integration.......................................................................................13
3.3.1 - Apache Continuum......................................................................................14
3.4 - FTP, Modalità di Rilascio.....................................................................................15
3.5 - Stesura dei Requisiti............................................................................................16
3.6 - Realizzazione modello Concettuale E-R..............................................................18
3.6.1 - Stesura dei Requisiti del Sistema Informativo............................................18
3.6.2 - Glossario dei Termini...................................................................................19
3.6.3 - Schema concettuale E-R..............................................................................20
4 - Realizzazione...............................................................................................................22
4.1 - Interazione tra Sistemi e Ruolo degli Attori........................................................22
4.2 - Diagrammi di sequenza.......................................................................................23
4.3 - Progettazione Logica e Fisica della base dati......................................................25
4.4 - Implementazione................................................................................................27
4.5 - Tecnologie e Framework utilizzati.......................................................................28
4.5.5 - Hibernate e Gestione della Persistenza......................................................29
4.6 - Definizione dei Servizi.........................................................................................30
4.6.1 - ScmService..................................................................................................30
4.6.2 - CisService....................................................................................................31
4.7 - Interfaccia...........................................................................................................32
4.7.1 - Installazione e Configurazione....................................................................32
4.7.2 - Esempio d'uso.............................................................................................34
4.8 - Configurazione delle Applicazioni da Gestire.....................................................36
5 - Conclusioni.................................................................................................................38
6 - Riferimenti..................................................................................................................39


1 - INTRODUZIONE

In questo lavoro di tesi si tratterà delle tematiche relative alla gestione dei rilasci di
applicazioni web, basate sull'ambiente Java, da parte di una software house. In
particolare si affronta la questione delle personalizzazioni, dette anche profili, che
debbono essere realizzate sulle diverse applicazioni per venire incontro alle esigenze e
alle specifiche configurazioni dei clienti.

Tali personalizzazioni, alle volte anche significative, diventano un problema per le
software house che devono gestire i propri applicativi mantenendo al tempo stesso le
personalizzazioni già effettuate per i clienti. Il rischio in cui si incorre in assenza di un
adeguato sistema di tracciatura dei rilasci è di imbattersi in incongruenze, possibili bug
e disagi per le nuove implementazioni. Inoltre, la difficoltà che si riscontra nella
installazione di applicazioni fortemente personalizzabili, diviene tale da rendere
impossibile una netta separazione tra gli sviluppatori e gli addetti al cosiddetto
“deploy”, ovvero la procedura di messa in produzione, che necessiteranno
inevitabilmente di aiuti.

Come scopo finale, si vorrebbe realizzare una applicazione che permetta di gestire da
un lato la possibilità di definire un profilo di compilazione specifico per il dato cliente e
dall'altro mantenere traccia di quanto viene rilasciato e in che contesto.

Attualmente, soluzioni software che permettano la gestione dei profili esistono solo
all'interno di specifici ambienti di sviluppo, ovvero necessitano dell'adozione di
standard tecnologici e di implementazioni forzate nella realizzazione delle applicazioni.
Tale situazione implica che, la scelta di adottare una soluzione esistente, viene ad
essere subordinata all'attuale contesto di sviluppo della software house.

Per realizzare questo lavoro si è dunque proceduto alla analisi della situazione attuale
di una grossa azienda di produzione software, nello specifico INSIEL MERCATO (Insiel
Mercato S.p.A. con unico socio, località Padriciano 99 - AREA Science Park - 34149
Trieste). L'azienda è impegnata nello sviluppo di applicazioni per la pubblica
amministrazione e per la sanità, e fornisce i propri applicativi a diversi clienti per i qua li
è necessario effettuare delle differenziazioni anche notevoli. Il reparto tecnologico che
si è preso in considerazione è quello delle applicazioni web basate su ambiente java
JEE. Successivamente si è analizzato l'insieme di tecnologie utilizzate per gli sviluppi
delle suddette applicazioni, e tra queste si è ricercato il contesto comune che
permettesse la possibilità di realizzare delle personalizzazioni con una modalità
facilmente adottabile da tutti gli applicativi attualmente in rilascio, con il minimo sforzo
di adattamento. Il passo finale ha consistito nel realizzare una applicazione che si
occupasse di tenere traccia di tali personalizzazioni.


In concomitanza con la redazione di tale tesi, l'azienda stava procedendo
all'introduzione di Maven, strumento dichiarativo per la gestione dei progetti Java in
termini di compilazione del codice, distribuzione, documentazione e collaborazione del
team di sviluppo. L'uso di questo supporto è dunque diventato un vincolo di progetto.

2 - SOMMARIO

La seguente trattazione illustrerà l'analisi effettuata per la comprensione della tematica
che si intende affrontare con successiva elaborazione dei dati risultanti.

• Raccolta delle informazioni sulla situazione corrente della azienda per conto
della quale si sta operando;
• Identificazione di Maven come principale punto in comune tra i diversi prodotti
realizzati dalla azienda, avente le possibilità di gestire in modo opportuno i
profili;
• Studio di Maven e delle modalità con cui questo effettua il filtraggio delle
risorse statiche e di come tale operazione venga influenzata dalla definizione di
un profilo;
• Interazione con sistemi di subversion;
• Studio dei concetti e delle possibilità offerte dai sistemi di Continuous
Integration;
• Analisi del prodotto Apache Continuum e del suo utilizzo da remoto;
• Studio della possibilità di realizzazione di plugin personalizzati per Maven;
• Studio delle tecnologie necessarie alla realizzazione della interfaccia
dell'applicativo;
• Studio del diagramma ER (Entità/Relazione) della base dati;

In un secondo tempo, verranno descritti i modi in cui tali considerazioni entrano in
gioco per lo sviluppo concreto dell'applicativo nella sua parte di business logic.

• Modellazione dell'applicativo ed integrazione con sistemi esterni;
• Definizione dei diversi moduli che compongono lo strato di Service;
• Progettazione logica della base dati e implementazione di Hibernate;
• Identificazione dei flussi applicativi, con particolare attenzione ai ruoli previsti
per gli utenti;
• Modifiche richieste alle applicazioni che verranno interessate dal sistema di
rilascio.

Una breve sezione riguarderà l'implementazione dell'indispensabile interfaccia per
l'interazione con l'utente.

• Sviluppo di una applicazione web per l'interazione tra utente e sistema;
• Illustrazione delle modalità di installazione e configurazione della applicazione;

2 - Sommario Pag. 5/39

• Delucidazione sui casi d'uso più comuni per la applicazione.

Infine trovano posto le conclusioni tecniche-oggettive e personali raggiunte al termine
dello sviluppo. Per le note informative che esulano da questa trattazione si è
predisposta una appendice di approfondimento cui si fa svariate volte riferimento.

3 - ANALISI

Prima di procedere con la progettazione e la successiva realizzazione del progetto,
occorre stabilire a priori quelli che sono i requisiti che si vuole vengano rispettati nello
sviluppo. Per poter tracciare un ben definito elenco di requisiti è indispensabile
effettuare una analisi approfondita della problematica che si vuole affrontare, dello
stato dell'arte, delle tecnologie che sono disponibili al momento e delle possibili
soluzioni che vengono offerte da queste.

Il punto centrale da cui inizia questa analisi è il tool di sviluppo Maven. Tale strumento
è presente in tutti i progetti che si vuole gestire con il futuro applicativo e permette di
controllare un gran numero di funzionalità.

In questa analisi si cercherà dunque di analizzare Maven, mettendo in risalto le
modalità con cui questo tool riesce a interagire con gestione delle versioni, uso dei
profili e modalità di rilascio.

3.1 - Maven

Maven, può essere considerato principalmente come uno strumento per la gestione di
progetti software Java, in termini di compilazione del codice, testing, distribuzione,
documentazione e collaborazione del team di sviluppo. Si tratta dunque di un tentativo
di applicare pattern ben collaudati all'infrastruttura del build dei progetti cercando di
coprirne tutti gli ambiti.

Si tratta di promuovere la comprensione e la produttività del team coinvolto nello
sviluppo, fornendo un percorso chiaro all'utilizzo di best practice. Per questo motivo
Maven è definito, sinteticamente, tool per la gestione e comprensione dei progetti.
Esso è quindi contemporaneamente un insieme di standard, una struttura di repository
e un'applicazione che servono alla gestione e alla descrizione di progetti software. Esso
definisce un ciclo di vita standard per il building, il test e il deployment di file di
distribuzione Java.

Le caratteristiche di Maven fanno sì che diverse persone, anche inizialmente estranee
al progetto, possano lavorare insieme produttivamente senza dover trascorrere molto

3 - Analisi Pag. 6/39

tempo per comprendere la struttura del progetto, il suo funzionamento, il processo di
build, etc. Tutti coloro che si sono trovati, almeno una volta nella loro vita, a dover
intervenire in progetti di grandi dimensioni in corso d'opera, sicuramente conoscono la
frustrazione causata da dover capire rapidamente l'interazione delle varie parti del
progetto, l'ordine e le dipendenze del processo di build, etc.

Le aree prese in considerazione da Maven sono: build, documentazione, reportistica,
gestione delle dipendenze, SCMs (Software Configuration Management), rilascio e
distribuzioni di nuove versioni. In effetti tutti i progetti, indipendentemente dal loro
dominio, dalla loro estensione e dalla tecnologia impiegata, presentano una serie di
necessità standard, quali ad esempio:
• la conversione dei sorgenti in codici "eseguibili" (build);
• la verifica (test);
• l'assemblaggio;
• la documentazione;
• eventualmente il "dispiegamento" e la relativa configurazione (deployment).

3.1.1 - Struttura dei file Pom.xml

Uno dei principali componenti di Maven è il file pom.xml (Project Object Model,
modello ad oggetti del progetto). Esso mantiene i meta-dati del progetto memorizzati
utilizzando il formato xml.

Il file POM presenta una struttura piuttosto articolata e complessa. Tuttavia la maggior
parte delle funzionalità vengono implementate di base con un comportamento di
default che risulta essere perfettamente compatibile con la maggioranza dei progetti.
Inoltre un file POM personalizzato per un dato progetto può essere facilmente
riutilizzato per i successivi, con variazioni minime.

La complessità del POM che può inizialmente spaventare chi non è pratico
dell'ambiente, offre al tempo stesso un punto di forza per chi volesse alterare il
comportamento di Maven. Questa elevata versatilità sarà il punto di partenza per lo
sviluppo di questo progetto.

Tralasciando la struttura generica del POM, che esula da questa trattazione, nei
paragrafi successivi si affrontano con più attenzione, le parti che hanno una relazione
con quanto si discute in questa analisi. Si vedranno dunque le modalità di filtraggio
delle risorse, la definizione di property, la gestione dei profili e dei riferimenti a server
SCM e di rilascio.


3.1.2 - SCM, Software Configuation Management

Il software per la gestione della configurazione, detto in inglese Software Configuation
Management o più semplicemente con l'acronimo SCM, è il software dedicato alla
gestione dei file sorgenti e risolvono il problema del Version Control.

Per la connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM.
Questo fornisce un'interfaccia comune per accedere alle diverse implementazioni SCM
(CVS, Subversion, IBM ClearCase, etc.).

<project>
...
<scm>
<connection>scm:svn:https://scmsever.com/myPrj/trunk/</connection>
<developerConnection>
scm:svn:https://subversion.scmsever.com/svn/myPrj/trunk/
</developerConnection>
<tag>trunk</tag>
<url>scm:svn:https://scmsever.com/myPrj/trunk/myPrj</url>
</scm>
...
</project>

Gli elementi SCM (listato appena visto) sono:
• connection e developerConnection permettono di definire le diverse modalità
di connessione al sistema di controllo del versionamento attraverso Maven. In
particolare, mentre la connessione utilizzata da Maven (connection) richiede un
accesso di sola lettura necessaria per permettere a Maven di localizzare e
leggere il codice sorgente, la connessione degli sviluppatori
(developerConnection), invece, richiede un accesso in lettura/scrittura. Per la
connessione con i sistemi SCM, Maven utilizza un proprio plug-in: Maven SCM.
Questo fornisce un'interfaccia comune per accedere alle diverse
implementazioni SCM (CVS, Subversion, IBM ClearCase, etc.). Questa interfaccia
è basata su una API ispirata al seguente formato URL: scm:[provider]:
[provider_specific]. Nel listato riporato sopra è presente una configurazione
contenente una connessione protetta (HTTPS) al server Subversion.
• tag permette di specificare l'etichetta (la radice dell'SCM) dalla quale è possibile
accedere al progetto.
• url, permette di specificare l'indirizzo URL che permette di navigare il repository

3.1.3 - Repository

Mentre le sezioni repository del POM permettono di specificare le posizioni e le
modalità con cui Maven è in grado di effettuare il download dei vari manufatti
necessari al POM, questa sezione, all'interno dell'elemento distributionManager,


permette di specificare dove e come memorizzare i manufatti del progetto, in fase di
deployment, all'interno del repository. Qualora la sezione snaposhotRepository non sia
definita, le impostazioni dell'elemento repository sono utilizzati anche per la
distribuzione di tipo snapshot. Ecco il listato che illustra le sezioni snapshotRepository e
Repository all'interno della sezione distributionManagement.

<project>
...
<distributionManagement>
<repository>
<uniqueVersion>false</uniqueVersion>
<id>corp1</id>
<name>Corporate Repository</name>
<url>scp://repo1/maven2</url>
<layout>default</layout>
</repository>
<snapshotRepository>
<uniqueVersion>true</uniqueVersion>
<id>propSnap</id>
<name>Propellors Snapshots</name>
<url>sftp://propellers.net/maven</url>
<layout>legacy</layout>
</snapshotRepository>
...
</distributionManagement>
...
</project>

Gli elementi di queste sezioni sono:
• id, name: entrambi i campi servono per identificare il repository. Mentre il
campo id è un identificatore univoco, il nome serve per rendere il campo
leggibile.
• uniqueVersion: è un attributo di carattere booleano il cui valore true serve ad
incaricare Maven del versionamento dei vari manufatti pubblicati (generazione
di un numero di versione univoco da associare ai manufatti memorizzati nel
repository). Il valore false invece indica che la versione è definita come parte
dell'indirizzo.
• url: come lecito attendersi rappresenta l'informazione principale dell'elemento
repository. Il formato URL, permette di specificare sia l'ubicazione sia il
protocollo di trasporto da utilizzare per il trasferimento dei manufatti generati
dal processo di build.
• layout: come visto in precedenza permette di specificare la struttura del
repository. In particolare: default indicata la struttura introdotta con Maven 2,
mentre legacy rappresenta la struttura precedente.


3.1.4 - Property e Filtraggio delle Risorse

Per filtraggio delle risorse si intende la sostituzione di variabili sui file di configurazione
costituenti il nostro progetto.

Per far si che le risorse vengano filtrate occorre abilitare il filtering nel tag resources. Se
il filtraggio delle risorse è attivo, prima di qualsiasi operazione di compilazione, il
framework si preoccupa di controllare tutti i file di risorsa (di default si trovano nella
cartella /src/main/resources) e di sostituirne le variabili con alcuni valori preimpostati.
Tali valori possono essere definiti come properties del progetto generico oppure, come
si vedrà in seguito, definiti a livello di profilo.

<project>
...
<properties>
<jdbc.driverclassname>com.mysql.jdbc.Driver</jdbc.driverclassname>
<jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url>
<jdbc.username>dev_user</jdbc.username>
<jdbc.password>s3cr3tw0rd</jdbc.password>
</properties>
...
<build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>

Come esempio si consideri un file di properties, facente parte di un dato progetto, in
cui vengono specificati i parametri di connessione verso la base dati. Tale file deve
essere configurato in modo differente in base al contesto di compilazione (macchina
locale dello sviluppatore, server di sviluppo, clienti). Il file che si troverà nei sorgenti del
progetto, sarà dunque formattato come indicato di seguito:

driver=${jdbc.driverclassname}
url=${jdbc.url}
username=${jdbc.username}
password=${jdbc.password}

Si può vedere che il file non è valorizzato ma, in fase di compilazione, verranno
utilizzate le properties definite nel POM del progetto per sostituire i placeholder
definiti da ${<chiave>}.


3.1.5 - Profili

Una caratteristica introdotta a partire dalla versione 4.0 dei POM sono i profili. Queste
sezioni permettono di variare opportune impostazioni in funzione dell'ambiente di
build. Ciascun profilo include sia una sezione opzionale dedicata all'attivazione (una
sorta di trigger per un profilo) sia un insieme di variazioni da apportare al POM qualora
il relativo profilo venga attivato. Un esempio classico consiste nel far in modo che un
progetto realizzato per eseguire determinati test faccia riferimento ad un diverso
database a seconda dell'ambiente di esecuzione. Un altro esempio consiste nel far sì
che il sistema, a seconda della versione del JDK utilizzata, prelevi opportune
impostazione da diversi repository.

<project>
...
<profiles>
<profile>
<id>test</id>
<activation>...</activation>
<build>...</build>
<modules>...</modules>
<repositories>...</repositories>
<pluginRepositories>...</pluginRepositories>
<dependencies>...</dependencies>
<reporting>...</reporting>
<dependencyManagement>...</dependencyManagement>
<distributionManagement>...</distributionManagement>
</profile>
</profiles>
</project>

Gli elementi del profilo permettono di ridefinire elementi già presenti all'interno del
POM, pertanto ne ricopiano la struttura, come si può vedere nel precedente listato.

E' possibile riunire le possibilità di filtering delle risorse e gestione dei profili ottenendo
la possibilità di valorizzare differentemente determinate risorse statiche mediante l'uso
dei profili. Il risultato è un listato simile al seguente.

<project>
...
<properties>
<jdbc.driverclassname>com.mysql.jdbc.Driver</jdbc.driverclassname>
<jdbc.url>jdbc:mysql://localhost:3306/development_db</jdbc.url>
<jdbc.username>dev_user</jdbc.username>
<jdbc.password>s3cr3tw0rd</jdbc.password>
</properties>
...
<build>
<resources>
<resource>
<directory>src/main/resources</directory>


<filtering>true</filtering>
</resource>
</resources>
</build>
...
<profiles>
<profile>
<id>production</id>
<properties>
<jdbc.driverclassname>
oracle.jdbc.driver.OracleDriver
</jdbc.driverclassname>
<jdbc.url>jdbc:oracle:thin:@proddb01:1521:PROD</jdbc.url>
<jdbc.username>prod_user</jdbc.username>
<jdbc.password>s00p3rs3cr3t</jdbc.password>
</properties>
</profile>
</profiles>
</project>

3.2 - Gestione delle Versioni

Si definisce controllo delle versioni, la gestione di versioni multiple di un insieme di
informazioni. Viene usato prevalentemente nello sviluppo di progetti informatici per
gestire la continua evoluzione dei documenti digitali come il codice sorgente del
software. Le modifiche a questi file sono identificate incrementando un numero o un
codice associato ad essi, denominato "numero di versione", "etichetta di versione", o
semplicemente "versione", e sono etichettate con il nome della persona che ha
apportato la modifica.

Gli strumenti software per il controllo versione sono sempre più riconosciuti essere
necessari per la maggior parte dei progetti di sviluppo software.

Nell'ingegneria del software, il controllo delle versioni è costituito da qualunque pratica
che tenga traccia e permetta di controllare i cambiamenti al codice sorgente. Gli
sviluppatori software talvolta usano il controllo versione software anche per i file di
documentazione e di configurazione, oltre che per il codice sorgente. In teoria, il
controllo versione può essere applicato a qualunque tipo di registrazione di
informazioni.

Riassumendo, l'obiettivo fondamentale di tutti i software che si occupano del controllo
di versione è permettere a diversi sviluppatori di lavorare contemporaneamente su
diversi file o addirittura sullo stesso file, automatizzando compiti come:
• tenere traccia di chi sta modificando che cosa;
• unire le modifiche una volta complete;
• segnalare eventuali conflitti;
• tenere una copia di ogni precedente versione e fare in modo che sia facilmente
recuperabile.


3.2.1 - SVN, Subversion

Subversion (noto anche come SVN, che è il nome del suo client a riga di comando) è un
sistema di controllo versione progettato da CollabNet Inc. con lo scopo di essere il
naturale successore di CVS, oramai considerato superato.

Rispetto a CVS, Subversion introduce:
• versionamento delle directories: con CVS il controllo di versione era applicato
solo ai file, quindi le operazioni di copia e spostamento tra diverse directory non
era gestito adeguatamente. Con Subversion viene tenuta traccia anche del
contenuto di ogni singola directory e quindi lo spostamento di un file è a tutti gli
effetti considerata una modifica, quindi rintracciabile e reversibile.
• commits atomici: una serie di modifiche viene applicata solo in blocco – se
anche solo una di esse crea errori, non viene applicata nessuna delle modifiche
inviate. Questo evita la creazione di versioni incomplete che dovrebbero poi
essere corrette a mano.
• versionamento dei metadati: è possibile assegnare a file e directory delle
proprietà personalizzate – dei veri e propri metadati – e mantenere lo storico
anche delle modifiche a queste proprietà.
• astrazione dal livello di rete: l'accesso dal client al repository (cioè al deposito
centralizzato dei files) può avvenire attraverso il protocollo HTTP (sfruttando un
apposito modulo di Apache), attraverso un apposito server standalone
(SVNServe), o direttamente attraverso il filesystem (ma solo nel caso in cui il
repository sia situato sulla stessa macchina). In tutti questi casi, i comandi e le
operazioni fondamentali non cambiano, così come non cambia la struttura del
repository e delle copie di lavoro locali.

3.3 - Continuous Integration

Con il termine Continuous Integration si intende una pratica di sviluppo software in cui
i membri di un team devono integrare il proprio lavoro con la linea di sviluppo


principale. Con elevata frequenza si considera almeno una integrazione al giorno per
ogni membro del team. Tali integrazioni vengono verificate da una compilazione
automatica (che comprende anche l'esecuzione di test) per rilevare errori di
integrazione il più rapidamente possibile. Molti team trovano che questo approccio
porta a ridurre significativamente i problemi di integrazione e permette di sviluppare
software più rapidamente.

I sistemi che eseguono la integrazione continua, come Cruise Control, Apache
Continuum, TeamCity, e così via, sono ormai presenti in ogni progetto che si rispetti. Si
tratta di sistemi che, su richiesta, o ad intervalli predefiniti (ogni ora, durante le ore
notturne) eseguono il processo di build dell'intero progetto.

3.3.1 - Apache Continuum

Apache Continuum è uno dei principali applicativi open source per l'integrazione
continua progettato per build java. Una caratteristica che lo distingue da altri strumenti
similari è la gestione della sicurezza basata sui ruoli. Questa funzione fornisce il
controllo su quali aspetti della compilazione possono essere visti e gestiti dai diversi
utenti. Nel complesso, le caratteristiche principali sono simili a quelle appartenenti ad
altri applicativi di build management come Hudson e Cruise Control (gestione dei
rilasci, notifica e-mail, integrazione con i più diffusi strumenti di compilazione,
integrazione con Maven e integrazione con sistemi di SCM come SVN o CVS).

Lo strumento di interfaccia utente è web based, e dopo che il server è stato avviato si
può accedere da browser con un collegamento a http://localhost:8080/continuum.

Apache Continuum offre inoltre la possibilità di accedere alle proprie funzionalità
anche da remoto mediante un client XML-RPC. Il client è accessibile mediante un
collegamento a http://localhost:8080/continuum/xmlrpc.


3.4 - FTP, Modalità di Rilascio

Il File Transfer Protocol (protocollo di trasferimento file o FTP), è un Protocollo per la
trasmissione di dati tra host basato su TCP. Gli obiettivi principali di FTP descritti nella
sua RFC ufficiale sono:
• Promuovere la condivisione di file (programmi o dati);
• Incoraggiare l'uso indiretto o implicito di computer remoti;
• Risolvere in maniera trasparente incompatibilità tra differenti sistemi di
stoccaggio file tra host;
• Trasferire dati in maniera affidabile ed efficiente.

E' stato necessario interessarsi al protocollo FTP perché questo metodo di distribuzione
viene utilizzato per effettuare i rilasci in Insiel Mercato così come in moltissime altre
aziende ed è una delle principali modalità con cui vengono effettuati i trasferimenti di
file di grosse dimensioni.

Per permettere a Maven di interagire con un repository FTP, è necessario utilizzare una
particolare estensione del plugin wagon (utilizzato per prelevare e memorizzare file in
server remoti).

<project>
...
<build>
...
<extensions>
<extension>
<groupId>org.apache.Maven.wagon</groupId>


<artifactId>wagon-ftp</artifactId>
<version>1.0-alpha-3</version>
</extension>
</extensions>
...
</build>
...
</project>

3.5 - Stesura dei Requisiti

Nei paragrafi precedenti, si sono esaminate le tecnologie comuni alle applicazioni
attualmente sviluppate dalla azienda Insiel Mercato, e su queste si sono esaminate le
caratteristiche che sembrano poter offrire la soluzione al problema della gestione di
profili e versioni.

Il risultato dell'analisi si riassume nelle seguenti note:
• Il tool Maven offre la possibilità di gestire dei profili in modo tale che, in fase di
compilazione del progetto, gli attributi che vengono definiti nel file POM dei
progetti, siano sovrascrivibili o comunque modificabili.
• Un particolare punto di interesse nella nota precedente è costituito dalle
properties, associazioni tra chiavi e valori configurabili da profilo, che possono
essere utilizzate come placeholder all'interno delle risorse statiche dei progetti;
• I profili maven, così come le properties, possono trovarsi anche esternamente al
POM, ed essere iniettati durante la fase di compilazione.
• Ad ogni versione di un progetto Maven, corrisponde un tag su SVN.
Considerando che un tag non rappresenta una linea di sviluppo ma un punto (è
dunque non è modificabile), non si può pensare di modificare i sorgenti del
progetto per poter integrare il profilo all'interno del pom del progetto stesso.
• Sulla base della nota precedente, si comprende come sia necessario che i profili
vengano definiti all'interno di un sistema che sia indipendente dal gestore del
versionamento. Tale sistema dovrà essere in grado, non solo di memorizzare i
profili, ma anche di crearli e di poterli associare ai clienti.
• Si riscontra che sia possibile utilizzare un sistema di Continuous Integration per
eseguire delle operazioni Maven, che questi abbiano delle interfacce remote, e
che Maven consenta di effettuare il deploy di un compilato su di un server FTP.

Le note sopra esposte definiscono non solo il risultato della analisi ma anche il
documento dei requisiti che l'applicativo che si vuole realizzare dovrà essere in grado di
soddisfare. In particolare, sulla base di quanto appena illustrato si vuole realizzare una
applicazione che sia in grado di:
• creare dei profili di compilazione per progetti Maven in base alle configurazioni
dei clienti;
• memorizzare i suddetti profili, e le relazioni con progetti e clienti, in un archivio
locale;
• utilizzando i profili creati, far eseguire ad un motore di Continuous Integration il


rilascio dell'applicazione per il dato cliente su di un server FTP.

Dalla rielaborazione delle note e delle considerazioni appena esposte, si possono
enunciare i seguenti requisiti di progetto.

• L'applicazione dovrà essere in grado di distinguere la figura dello sviluppatore
da quella dell'addetto alla messa in produzione e per ciascuno di essi fornire le
funzionalità strettamente necessarie all'esercizio delle proprie funzioni. In tal
modo si riusciranno ad isolare le responsabilità e meglio definire gli standard di
esecuzione.
• Deve essere possibile, all'interno della applicazione, gestire le connessioni verso
i build manager o continuous integration system, verificandone la corretta
raggiungibilità e permettendo l'importazione di progetti da essi.
• Devono essere registrabili e modificabili le definizioni dei clienti.
• Deve essere possibile importare progetti dal sistema di integrazione continua e
registrarli all'interno dell'applicativo oppure, viceversa, da questo, dopo aver
inserito i parametri fondamentali, effettuare un export verso in sistema esterno.
• L'applicativo deve possedere, per ogni progetto, i riferimenti al posizionamento
su di un sistema SCM.
• Dai riferimenti SCM di ogni progetto deve essere possibile effettuare il checkout
dei sorgenti e da questi ricavare un template di definizione dei profili,
caratteristico del progetto che si sta profilando.
• Sulla base dei template dei profili ed in associazione con progetto e cliente,
deve essere possibile per l'utente, inserire i parametri che caratterizzano il
profilo e salvare quest'ultimo nella base dati.
• L'applicazione deve poter far eseguire, ad un sistema di Continuous Integration
remoto, un comando maven di compilazione di un progetto, in base al profilo
voluto.
• Il risultato del comando di build indicato precedentemente deve avere come
esito positivo, il deploy del compilato del progetto su di un server FTP. Tale
compilato deve contenere la configurazione definita nel profilo.
• In seguito al deploy eseguito con successo, deve essere registrata l'esecuzione
del rilascio per il dato cliente.
• Con una ulteriore interrogazione del sistema SCM, si preleva un secondo
template che specifica le informazioni importanti che occorre registrare per il
dato progetto.
• Sulla base del template sopra esposto, deve essere possibile registrare le
informazioni ottenute dal cliente sull'ambiente specifico di installazione.
• L'applicativo deve permettere ricerche esaustive sulla base di progetti, versioni
e clienti.


3.6 - Realizzazione modello Concettuale E-R

Essendo necessario l'utilizzo di una base dati per immagazzinare le informazioni
relative a progetti, clienti, profili e rilasci, si rende indispensabile effettuare una
corretta progettazione della stessa. Un errore durante questa fase si ripercuoterebbe
sull'intero progetto, mentre una base di dati ben progettata risulterebbe invece più
efficiente e semplificherebbe lo sviluppo delle applicazione.

Il procedimento per la progettazione di una base di dati segue i seguenti passi:
• Stesura dei requisiti del sistema informativo in linguaggio naturale;
• Glossario ed identificazione delle entità;
• Realizzazione del Modello ER.

Nel capitolo relativo alla realizzazione, vengono effettuati ulteriori elaborazioni dello
schema E-R fino a giungere allo schema logico e fisico.

3.6.1 - Stesura dei Requisiti del Sistema Informativo

Si produce una prima versione dei requisiti in linguaggio naturale, raggruppando frasi
descrittive relative a categorie diverse di dati.

Frasi riguardanti i progetti:
• Un Continuous Integration System viene utilizzato per il testing dei progetti.
• I progetti vengono compilati da un Continuous Integration System.
• I progetti sono versionati su un gestore di versioni SCM.
• Gli sviluppatori depositano i progetti su SCM e Continuous Integration System.

Frasi relative ai Profili:
• Il profilo è la definizione della personalizzazione di un progetto.
• Ogni cliente può volere uno o più profili dello stesso progetto.
• Ogni compilazione viene eseguita con un certo profilo.
• Il template del profilo viene preso dai sorgenti versionati del progetto.
• I deployer sono incaricati della realizzazione dei profili.

Frasi relative al build:
• Il build viene fatto dal Continuous Integration System.
• Tutti i progetti sono gestiti dal Continuous Integration System.
• Il Continuous Integration System riceve i profili dall'applicazione rudra.
• Un build riuscito può essere rilasciato al cliente.
• I deployer installano i progetti dai clienti.

Frasi relative al cliente:
• Il cliente richiede il rilascio di un progetto;


• Il progetto rilasciato viene configurato per il cliente.
• Al cliente viene installato il prodotto richiesto.

Frasi relative ai rilasci:
• Se un build da esito positivo può essere installato.
• Ad ogni installazione corrisponde un buildn di un progetto.
• Le installazioni vengono fatte dai deployer.

Frasi relative agli sviluppatori:
• Ogni progetto ha uno o più sviluppatori.
• Gli sviluppatori utilizzano il server SCM per versionare i progetti.
• Gli sviluppatori monitorano i progetti con i CIS.

Frasi relative ai deployer:
• I deployer creano i profili per i progetti.
• Una installazione corrisponde all'intervento di un deployer su un progetto.

3.6.2 - Glossario dei Termini

Analizzando le frasi espresse in linguaggio naturale, raggruppate per categoria di dati, si
possono identificare dei termini ricorrenti e tra questi delle relazioni.

Termine Descrizione Collegamenti
Progetto Prodotto venduto dalla azienda Sviluppatore, Profilo,
CIS, SCM, Build
Profilo Personalizzazione del progetto per il cliente Deployer, Progetto,
Cliente, Build
Cliente Colui a cui si vende il progetto personalizzato Installazione, Profilo
Sviluppatore Sviluppa i Progetti Progetto
Deployer Crea i profili e installa i progetti compilati Profilo, Installazione
Build Rappresenta il processo con cui si crea il Progetto, Profilo,
compilato e i suoi risultati Installazione
CIS Continuous Integration Systema Progetto
Installazione Installazione del progetto compilato presso il Deployer, Cliente, Build
cliente
SCM Sistema di versionamento Progetto


3.6.3 - Schema concettuale E-R

Traducendo il glossario in uno schema concettuale basato su Entità e Relazioni si
ottiene lo schema indicato di seguito. Questo è lo schema scheletro dal quale si parte
con l'analisi che condurrà alla realizzazione dello schema E-R vero e proprio.

Dallo schema precedente si può immediatamente evincere che le entità Sviluppatore e
Deployer possono essere considerate delle specializzazioni della figura del Dipendente.

Inoltre dalla comprensione delle frasi in linguaggio naturale e dalla analisi del contesto
costituito dal sistema informativo che si vuole realizzare, è possibile definire sia gli
attributi che le singole entità (e nel caso, anche le relazioni) debbano avere, sia la
cardinalità con cui le entità entrano in relazione tra loro. Questa analisi è di
fondamentale importanza per lo sviluppo dello schema logico e fisico che si andrà a
svolgere nel capitolo relativo alla realizzazione della base dati.


Di seguito viene quindi esposto lo schema Entità-Relazione su cui si è strutturata la
base dati del progetto Rudra.

4 - Realizzazione Pag. 21/39

4 - REALIZZAZIONE

In considerazione del fatto che l'applicativo in realizzazione necessiterà di essere
utilizzato da diverse figure professionali (sviluppatori, addetti alla messa in produzione,
project manager, ecc..) e in diversi contesti (tutti però localizzabili all'interno
dell'azienda), si è deciso di realizzare una applicazione web. Tale scelta permette una
maggiore semplicità d'uso ed è ottimizzata per l'uso intranet. Essa viene inoltre
giustificata dagli stretti legami con altri applicativi ad uso intranet come sistemi di
continuous integration, repository per il controllo delle versioni, repository maven
interni, server ftp per i rilasci, server ldap per le autenticazioni e sistemi di issue
tracking.

4.1 - Interazione tra Sistemi e Ruolo degli Attori

Si vuole realizzare una applicazione capace di gestire un elenco di progetti posti in un
sistema di Continuous Integration. Di tali progetti deve essere possibile ricavare i
riferimenti al server di versionamento SCM da cui a sua volta si estraggono le
informazioni necessarie alla compilazione di un profilo. Successivamente, in base alle
informazioni appena fornite dal sistema SCM, si procede alla creazione di un nuovo
profilo per il dato cliente associandolo al progetto stesso all'interno del database
dell'applicazione Rudra. Tale profilo viene poi utilizzato per la generazione del progetto
personalizzato da parte del sistema di continuous integration che provvederà al deploy
del compilato finale su di un server FTP per la distribuzione. Inoltre si vuole registrare
l'operazione di rilascio, arricchendola di informazioni specifiche del progetto e del
cliente, all'interno del database.

In tutto questo processo, gli utenti che compiono le diverse attività possono essere
categorizzati in due attori principali, ovvero:

• Sviluppatore: Colui che sviluppa e mantiene i progetti. Stabilisce i rilasci delle
versioni e in concomitanza con questi eventi si occupa di realizza i tag sul
sistema di versionamento e porre l'applicazione appena versionata su un
sistema di continuous integration.
• Deployer: Colui che si occupa della messa in produzione degli applicativi. Non
ha competenze riguardo al funzionamento dei progetti o delle tecnologie con
cui questi sono stati realizzati. Si occupa di ricavare dai clienti le informazioni
sul contesto in cui le applicazioni si troveranno ad operare, a configurarle
adeguatamente realizzando un profilo, e a porre in produzione il compilato
che potrà ricavare dal server FTP.


Come si può facilmente vedere dallo schema precedente, grazie all'introduzione di
questo meccanismo di rilascio, non esistono punti in comune tra la figura dello
sviluppatore e quella del deployer.

4.2 - Diagrammi di sequenza

I due attori principali che interagiranno con il progetto Rudra saranno dunque i
deployer e gli sviluppatori. Per ciascuno di essi sono stati realizzati i seguenti diagrammi
di sequenza.

Per la figura dello sviluppatore si hanno le seguenti operazioni:

• registrazione di un sistema di Continuous Integration;
• richiesta del progetti importabili dal CIS;
• importazione di un progetto.


Per la figura del deployer si hanno le seguenti operazioni:

• richiesta form per creazione del profilo;
• salvataggio profilo;
• richiesta rilascio;
• salvataggio dettaglio rilascio.


4.3 - Progettazione Logica e Fisica della base dati

Non esistono DBMS in grado di operare direttamente sui concetti di schemi E-R. Risulta
quindi necessario tradurli in altri schemi di dati chiamati logico relazionali. Questa
traduzione può essere eseguita in modo semi-automatico seguendo una determinata
serie di operazioni da eseguire.

Il progetto logico presenta in generale una soluzione standard determinabile in modo
semplice e diretto. A seconda dei casi, sono però disponibili anche soluzioni
alternative, che possono rivelarsi più o meno convenienti. In queste occasioni si deve
tenere conto dell’efficienza dello schema logico risultante e delle operazioni da
effettuare (derivanti da flussi e processi).


Per ottenere lo schema logico della base dati è necessario dunque procedere a
trasformazioni e traduzioni dello schema E-R seguendo le fasi indicate di seguito:
• Eliminazione delle generalizzazioni;
• Identificazione delle chiavi primarie;
• Traduzione di entità e associazioni in schemi di relazioni.

Durante la realizzazione di queste fasi, si devono compiere le seguenti valutazioni, che
permettono una ottimizzazione dello schema logico risultante dalla interpretazione
dello schema E-R:
• Previsioni sulla natura e la frequenza delle operazioni;
• Valutazioni quantitative sui volumi di dati (entità, associazioni, percentuali di
copertura di gerarchie, percentuali di valori nulli).

In tutti quei casi in cui sono possibili scelte alternative, occorre prestare la dovuta
attenzione alle seguenti considerazioni, molto spesso intuitive:
• Le proprietà logiche sono comunque primarie rispetto ai motivi di efficienza;
• Tenere sulla stessa entità informazioni che verranno di frequente consultate
insieme;
• Tenere su entità separate informazioni che verranno consultate separatamente;
• Limitare l’incidenza di valori nulli per attributi opzionali.

L'applicazione delle regole e delle considerazioni precedenti, porta alla stesura delle
seguenti trasformazioni da applicare allo schema E-R:
• la relazione esistente tra CIS e Progetto ha cardinalità 1,1 sulla seconda entità, e
su questa viene accorpata;
• vista la cardinalità 1,1 della relazione tra SCM e Progetto, la prima entità viene
completamente accorpata nella seconda (questa soluzione facilita anche la
gestione dei progetti e della interfaccia.);
• gli argomenti del Profilo, essendo molteplici, vengono estratti dall'entità Profilo
e posizionati in una tabella a parte di cui il profilo è chiave esterna (tabella
Profile_Property);
• le dipendenze aggiuntive che possono essere richieste da un Profilo possono
essere molteplici, quindi vengono estratte dall'entità Profilo e posizionate in
una tabella a parte di cui l'identificativo del profilo è chiave esterna (tabella
Profile_Dependency);
• gli argomenti della Installazione, essendo molteplici, vengono estratti dall'entità
Installazione e posizionati in una tabella a parte di cui l'identificativo del profilo
è chiave esterna (tabella Release_Property);
• in tutti i casi in cui la cardinalità con cui una entità entra in relazione è 1,1, la
relazione viene accorpata alla entità stessa;
• l'identificazione delle chiavi primarie segue le indicazioni già fornite nello
schema E-R realizzato.

All'interno degli applicativi sviluppati da Insiel Mercato, la gestione di autenticazioni ed
autorizzazioni degli utenti, viene svolta da un kernel di funzionalità, condiviso tra tutte
le applicazioni, che utilizza una base dati condivisa. Trattandosi dunque di una


soluzione già esistente e proprietaria, essa non viene trattata in questo studio.

Il risultato di tutte queste considerazioni, applicate sullo schema entità-Relazione che è
stato elaborato nella fase di Progettazione di questa tesi, ha prodotto lo schema logico
che ha come prodotto il seguente schema fisico.

4.4 - Implementazione

L'applicazione web che si intende sviluppare presenterà tre diversi strati software.

Il primo, ovvero lo stato dei controller sarà recettivo delle richieste http inviate dal
browser dell'utente. Si occuperà dunque di verificare autenticazioni ed autorizzazioni e
di fornire successivamente una risposta in base a ciò che verrà restituito dai servizi che
verranno di volta in volta richiamati.

Il secondo strato è uno strato di servizi che rispettano il pattern meglio noto come
Facade. Tali servizi permettono di nascondere la complessità delle operazioni ai
controller o agli altri servizi chiamanti. In tal modo la complessità di certe operazioni
complesse viene ad essere concentrato in un punto, ed essendo i servizi realizzati nel
modo più generico e astratto possibile, il codice sviluppato è estremamente riusabile.


Il terzo strato è quello dedicato alla persistenza. Tale livello non è sempre presente.
Grazie all'utilizzo di un motore di persistenza come Hibernate, non sarebbe necessario
realizzare uno strato che si occupi delle operazioni di scrittura e lettura sulla base dati,
ma in quei casi in cui le operazioni di lettura e scrittura possono essere più complesse e
magari ricorrenti all'interno dei diversi servizi, allora si preferisce estrarre il codice
relativo e posizionarlo in una classe di appoggio.

L'interazione con i servizi di versionamento SCM e di Continuous Integration CIS sono
gestiti da appositi servizi.

4.5 - Tecnologie e Framework utilizzati

Per la realizzazione dell'applicazione web si è scelto di utilizzare il framework Spring.
Spring è un framework open source per lo sviluppo di applicazioni che rappresenta al
momento il tentativo più riuscito per semplificare lo sviluppo di applicazioni
"enterprise" di una certa complessità nell'ambito Java. Spring interpreta nel modo
migliore i nuovi modelli di programmazione definiti dall'IoC e dall'AOP e permette di
raggiungere un livello di disaccoppiamento degli strati applicativi impedito invece dalla
natura "invasiva" della tecnologia EJB.

Si prestano molto bene alla realizzazione del progetto anche alcuni sotto-framework di
spring, quali Spring MVC (per la miglior gestione del pattern Model-View-Control) e
Spring Security (per la gestione di autenticazioni e autorizzazioni).

Le view che vengono restituite agli utenti sono generate grazie alle JSP la cui
composizione viene realizzata dal framework Tiles 2. Tiles permette agli sviluppatori di


definire frammenti di pagine jsp che possono essere assemblate in una pagina
completa in fase di esecuzione. Questi frammenti possono essere utilizzati come
semplice include, al fine di ridurre la duplicazione degli elementi di pagina comuni o
incorporato in altri frammenti al fine di sviluppare una serie di modelli riutilizzabili.

4.5.5 - Hibernate e Gestione della Persistenza

Hibernate (talvolta abbreviato in H8) è una piattaforma middleware open source per lo
sviluppo di applicazioni Java che fornisce un servizio di Object-relational mapping
(ORM), ovvero che gestisce la rappresentazione e il mantenimento su database
relazionale di un sistema di oggetti Java.

L'obiettivo di Hibernate è quello di esonerare lo sviluppatore dall'intero lavoro relativo
alla persistenza dei dati. Hibernate si adatta al processo di sviluppo del programmatore,
sia se si parte da zero sia se da un database già esistente. Hibernate genera le chiamate
SQL e solleva lo sviluppatore dal lavoro di recupero manuale dei dati e dalla loro
conversione, mantenendo l'applicazione portabile in tutti i database SQL. Hibernate
fornisce una persistenza trasparente per "Plain Old Java Object".

In questa tesi sono state utilizzate le annotazioni JAXB per personalizzare la mappatura
tra oggetti java, i cosiddetti POJO, e tabelle e altri costrutti SQL. Di seguito si riporta un
esempio di classe di modello mappata con hibernate.

...
@SuppressWarnings("serial")
@Entity
@Table(name = "project", uniqueConstraints = {
@UniqueConstraint(columnNames={"group_id","artifact_id","version"})})
public class Project implements Serializable {

@Id
@GeneratedValue(strategy = GenerationType.IDENTITY)
protected Long id;

@Column(name = "group_id", nullable = false)
protected String groupId;

@Column(name = "artifact_id", nullable = false)
protected String artifactId;

@Column(name = "version", nullable = false)
protected String version;

@Column(name = "scm_url", nullable = false)
protected String scmUrl;

@Column(name = "scm_username", nullable = false)
protected String scmUsername;

@Column(name = "scm_password", nullable = false)


protected String scmPassword;

@ManyToOne(cascade = CascadeType.ALL)
protected ContinuousIntegrationSystem cis;

@Column(name = "cis_project_id")
protected Long cisProjectId;

@Column(name = "invalidate", nullable = false)
protected Boolean invalidate = false;
...
// getter e setter per gli attributi della classe

L'annotazione @Entity permette ad Hibernate di riconoscere la classe come
referenziata su di una tabella, l'annotazione @Id ne riconosce la chiave primaria e
l'annotazione @ManyToOne permette di definire una chiave esterna con un'altra
entità.

4.6 - Definizione dei Servizi

Come già detto,

4.6.1 - ScmService

Per interagire con il sistema di versionamento è necessario l'utilizzo di librerie esterne.
Dopo una ricerca a riguardo si è scelto, per la particolare implementazione del servizio
verso un sistema SVN, di utilizzare il progetto SVNKit. Tale libreria, tra l'altro, è anche
utilizzata dallo stesso IDE Eclipse utilizzato per la realizzazione del progetto.

Per importare la libreria nel progetto occorre definire nel POM la seguente dipendenza

...
<dependency>
<groupId>org.tmatesoft.svnkit</groupId>
<artifactId>svnkit</artifactId>
<version>1.3.5</version>
</dependency>
...

Per poter effettuare delle operazioni sul server SVN occorre conoscerne i riferimenti. Si
riporta un esempio della connessione vai codice effettuata nel servizio.

...
DAVRepositoryFactory.setup();

SVNUpdateClient client = new SVNUpdateClient(
SVNWCUtil.createDefaultAuthenticationManager(


project.getScmUsername(), project.getScmPassword()),
SVNWCUtil.createDefaultOptions(true));

client.doCheckout(SVNURL.parseURIDecoded(scmUrl), outputFolder,
SVNRevision.UNDEFINED, SVNRevision.HEAD, SVNDepth.INFINITY, true);
...

4.6.2 - CisService

Per connettersi remotamente ad una istanza di Continuum, occorre utilizzare il jar
continuum-xmlrpc-client. Tale libreria può essere aggiunta come dipendenza al file pom
del progetto.

...
<dependency>
<groupId>org.apache.continuum</groupId>
<artifactId>continuum-xmlrpc-client</artifactId>
<version>1.4.0</version>
</dependency>
...

Per connettersi a Continuum con il client xml-rpc indicato è necessario utilizzare la
classe ContinuumXmlRpcClient, ilcui costruttore ha 3 parametri:
• url, l'url a cui risponde il listener xmlrpc (http://host:port/continuum/xmlrpc);
• user, l'username dell'utente di Continuum;
• password, la password dell'utente.

Per ottenere l'istanza del client nel codice java:

...
URL url = new URL( "http://localhost:8080/continuum/xmlrpc" );
ContinuumXmlRpcClient client = new ContinuumXmlRpcClient( url,
username, password );
...

Per ottenere la lista dei progetti:

...
List<ProjectSummary> ps = client.getProjects( projectGroupId );
...

Per richiamare il build di un progetto:

...
client.buildProject( project.getId(), buildDefinitionId );
...


4.7 - Interfaccia

L'interfaccia dell'applicativo è stata realizzata per permettere una facile interazione con
l'utente. I contesti in cui si possono eseguire le operazioni sono rappresentati come dei
Tab nella parte alta dell'interfaccia. Per ognuno di essi è presente un sotto menu che
permette l'esecuzione delle varie operazioni. Un barra di navigazione permette di
tenere traccia della posizione in cui ci si trova durante la navigazione della applicazione.

4.7.1 - Installazione e Configurazione

L'installazione dell'applicativo Rudra è piuttosto semplice. La sola cosa da fare è creare
uno schema di database vuoto (in questa tesi si è utilizzata una base dati postgres, ma
con pochissimi accorgimenti si può utilizzareq ualsiasi altro RDMS di uso comune) e
indicarne i riferimenti nel file:

rudraWEB-INFapplication-configpersistence-config.xml

...
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource"
destroy-method="close">
<property name="driverClassName" value="org.postgresql.Driver" />
<property name="url" value="jdbc:postgresql:rudra" />
<property name="username" value="rudra" />
<property name="password" value="rudra" />
</bean>
...

Una volta mandato in esecuzione l'application server (in questo caso si è utilizzato
Tomcat), hibernate si occuperà di realizzare lo schema della base dati sulla base degli
oggetti di modello che sonos tati mappati con le annotazioni JAXB.

Per poter configurare l'applicazione in modo corretto, l'amministratore o uno degli
sviluppatori deve accedere alla applicazione effettuando il login.


La prima operazione che deve essere eseguita è l'associazione di un sistema di
Continuous Integration. In questa schermata devono essere inseriti i parametri relativi
alla connessione remota.

Una volta associato il CIS, occorre importare i progetti da voler rilasciare. Questi
vengono selezionati da una lista di tutti i progetti attualmente disponibili sul sistema
CIS precedente mente associato.

La pressione del tasto importa, permette di registrare i progetti sulla base dati e di
gestirli dal progetto Rudra.


4.7.2 - Esempio d'uso

Le seguenti schermate indicano le operazioni che normalmente vengono eseguite dal
gruppo degli addetti ai rilasci. Una volta eseguito il login, essi verificano l'esistenza del
cliente oppure, in caso contrario, lo inseriscono.

Si procede dunque alla generazione del profilo richiesto indicando esplicitamente il
progetto che si vuole rilasciare e il relativo cliente.

Una volta che viene eseguita la registrazione del profilo, si procede con il checkout del
progetto dal repository SCM su cui esse viene versionato, e se ne estrae il template di
definizione dei placeholder.


Il template ottenuto contiene le indicazioni relative ai nomi delle chiavi dei placeholder
e la descrizione di che cosa indicano. Tali template e tali note descrittive note sono
state preventivamente indicati dagli sviluppatori prima di effettuare il tag del progetto.

Il deployer si occupa dunque di compilare il form per l'immissione dei dati del profilo
aiutato in questa operazione dalla descrizione. Successivamente vedrà l'elenco dei
profili, indicato di seguito, dal quale potrà richiedere la compilazioen remota e il deploy
sul server di rilascio FTP.

Nell'arco di pochi secondi o pochi minuti a seconda della dimensione dle progetto e
delle performance della rete intranet, sarà possibile interrogare il server FTP sul quale
si troverà il file compilato richiesto.


4.8 - Configurazione delle Applicazioni da Gestire

Affinché un progetto gestito tramite Maven possa usufruire del sistema descritto in
questa tesi, esso deve necessariamente:
• avere i propri file sorgenti versionati su di un sistema SCM raggiungibile;
• i file sorgenti sopra indicati debbono essere sottoposti ad un sistema di
Continuous Integration raggiungibile;
• avere nella root dei sorgenti, la definizione dei template che permettono la
definizione dei Profili e dei Rilasci;

Per poter utilizzare la generazione dei profili in Rudra, è necessario che i progetti da
gestire abbiano al loro interno un file di definizione dei placeholder da sostituire in fase
di compilazione. Il file viene posto nella root del progetto a pari livello del pom.xml e si
chiama:

/rudra-profile-template.properties

In questo file sono presenti le coppie di chiave/descrizione, come illustrato
nell'esempio:


rudra.db.driver=Se si utilizza un database Oracle, utilizzare il
driver Oracle Thin JDBC: "oracle.jdbc.driver.OracleDriver".
rudra.db.url=Contiene il nome della sorgente di dati nella forma
"jdbc:oracle:thin:@<server_name>:<db_port>:<SID>". Il valore
server_name è l'indirizzo IP o il nome assegnato dall'admin
del sistema al server di database. Il valore SID è l'identificatore
del sistema di database. Se sullo stesso sistema sono in esecuzione
più database Oracle, usare SID per distinguerli. Ad esempio, se il
server si chiama Aristotle, la porta del database è la 1343 e su
tale server è stato definito un SID di database di nome patients,
immettere il seguente valore:
"jdbc:oracle:thin:@Aristotle:1343:patients".
rudra.db.username=Nome utente per l'accesso alla base dati.
rudra.db.password=Password dell'utente.

Nel file pom devono essere presenti le seguenti sezioni. Tali modifiche vengono
eseguite per poter utilizzare le modalità di deploy effettuate tramite il plugin wagon.

Definizione del repository per il deploy:

<distributionManagement>
<repository>
<id>ftp-repository</id>
<url>ftp://192.168.1.104/home/ftp-user</url>
</repository>
</distributionManagement>

Estensione del plugin Wagon:

<extensions>
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-beta-6</version>
</extension>
</extensions>

NB: Nello sviluppo di questo progetto si è deciso di utilizzare il plugin wagon di Maven
per il deploy degli artefatti compilati sul server FTP, mediante l'estensione del plugin.
Tale soluzione è efficace e stabile, in quanto wagon è un plugin intrinseco di Maven.

Si consideri però che l'utilizzo un plugin così specifico, può causare dei fastidi nel
momento in cui si volessero effettuare delle modifiche alle modalità di deploy. Basti
pensi al caso in cui si volesse far deployare il file compilato in una determinata cartella
con allegati altri documenti, come guida all'installazione, o file connessi che comunque
non riguardano il build in se stesso.

In tal caso la soluzione che si consiglia di adottare è di realizzare un plugin
personalizzato di Maven da far in seguito inglobare in tutti i POM dei progetti gestiti
tramite Rudra.


5 - CONCLUSIONI

L'obiettivo di questo lavoro di tesi era la realizzazione di una sistema software che
permettesse di tenere traccia dei rilasci degli applicativi java web prodotti da una
azienda di sviluppo software, con particolare attenzione alla gestione dei profili. Tale
obiettivo si può dire pienamente raggiunto. Inoltre, grazie al fatto che i progetti della
azienda erano gestiti con il tool Maven, si è potuto, non solo tenere traccia dei profili
dei vari clienti, ma anche crearli direttamente nell'applicativo, grazie a dei template
predefiniti. La successiva interazione con un sistema di Continuous Integration ha poi
permesso che la generazione dei compilati da rilasciare avvenisse in modo
assolutamente automatico e trasparente per il personale incaricato della messa in
produzione.

Il progetto realizzato vanta una quasi immediata integrazione all'interno di un sistema
preesistente, se dotato di gestione delle versioni (Subversion) e testing mediante
meccanismi di continuous integration (Apache Continuum). Ciò significa che è possibile
adottarlo senza incorrere nella necessità di dover riscrivere parti di applicazioni
preesistenti o di dover modificare ambienti di lavoro. Il suo sviluppo ha richiesto
notevole studio delle tecnologie disponibili e una buona conoscenza degli ambienti e
delle meccaniche aziendali. La realizzazione vera e propria del progetto ha comportato
alcuni mesi. Grazie al fatto che il codice è stato strutturato a moduli tra loro
indipendenti, e che questi sono stati resi il più generici possibile, una buona parte del
codice sviluppato nella parte di “business intelligence” può essere facilmente
riutilizzato per altre applicazioni che ne debbano aver bisogno.

Personalmente, ritengo che tale progetto si possa definire di grande utilità per le
aziende di produzione software, sia per quanto riguarda l'organizzazione e la
reperibilità dei dati relativi a clienti ed installazioni, sia in termini di tempi e costi dovuti
ad installazione, sviluppo e manutenzione dei prodotti. Nel caso specifico, ritengo che
l'adozione di questo applicativo all'interno di Insiel Mercato, permetterà grandi
evoluzioni nella fase di “deploy” dei prodotti, evitando i vari disagi in cui spesso capita
di incorrere. Consentirà inoltre di aumentare velocità ed efficacia della manutenzione e
di nuovi sviluppi, avendo sottomano una chiara mappatura della situazione della
distribuzione dei progetti tra i clienti.

Il progetto realizzato verrà ulteriormente sviluppato nel corso dei prossimi mesi ed è
prevista la sua entrata in produzione presso il laboratorio tecnico di sviluppo per la
pubblica amministrazione di Insiel Mercato, nel mese di settembre. Prima del suo uso
effettivo, se ne vogliono aumentare le caratteristiche, integrandovi il sistema di
gestione di autenticazioni e autorizzazioni presente nell'azienda, fornendo l'interazione
con JIRA (un sistema di issue tracking, ovvero un software che ha il compito di
raccogliere e mantenere organizzate tutte le informazioni e le segnalazioni relative a
gestione, sviluppo e programmazione di una applicazione), un servizio di invio notifiche

5 - Conclusioni Pag. 38/39

tramite posta digitale e personalizzare maggiormente quello che è al momento il
comportamento dell'applicativo nella fase di deploy del compilato sul server ftp.

A completamento di questo lavoro di tesi vengono considerati i sorgenti del software
realizzato, nonché i documenti specifici della applicazione, consistenti nella guida di
installazione e configurazione.

6 - RIFERIMENTI

[1] Maven,
http://maven.apache.org/

[2] Luca Vetti Tagliati, Mokabyte
"Maven: best practice applicate al processo di build e rilascio di progetti Java. "

[3] Apache Continuum,
http://continuum.apache.org/

[4] SVNKit, subversion for java,
http://svnkit.com/

[5] Maven Wagon FTP,
http://maven.apache.org/wagon/wagon-providers/wagon-ftp/

[6] Martin Fowler, “Continuous Integration”,
http://martinfowler.com/articles/continuousIntegration.html

[7] Controllo Versioni,
http://it.wikipedia.org/wiki/Controllo_versione

[8] Guida Subversion, Francesco Abeni, programmazione.html.it

[9] The Best Continuous Integration Tools,Vlad Kofman
http://www.developer.com/

[10] Hibernate, Wikipedia
http://it.wikipedia.org/wiki/Hibernate

[11] Hibernate, Reference
http://docs.jboss.org/hibernate/core/3.6/reference/en-US/html_single/

Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (8)

Semelhante a Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee

Semelhante a Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee (20)

Último

Último (9)

Studio e realizzazione di un sw per la gestione dei profili e delle versioni di applicazioni web in ambiente jee