Architettura Applicativa FSE - OSCAT

FSE – Architettura Applicativa
Architettura Applicativa FSE
reingegnerizzazione
componenti applicative
1
FSE – Architettura Applicativa
sommario
Architettura Applicativa FSE ................................................................................................ 1
1 Introduzione e scopo del documento ............................................................................ 3
2 Versione in produzione ................................................................................................. 4
2.1
Modulo CGI-BIN .................................................................................................... 5
2.2
Modulo DDW ......................................................................................................... 5
2.3
Modulo Java .......................................................................................................... 5
3 Reingegnerizzazione dell’applicazione FSE ................................................................. 6
3.1
Sostituzione del modulo CGI-BIN .......................................................................... 6
3.2
Sostituzione del modulo DDW ............................................................................... 8
4 Integrazione con il sistema di gestione sicurezza SRTY .............................................. 8
4.1
Integrazione delle JSP tradotte con il framework SRTY ........................................ 9
4.2
Integrazione dei moduli Java con il framework SRTY ........................................... 9
4.3
Gestione della configurazione SRTY ..................................................................... 9
5 Adeguamenti architetturali successivi ......................................................................... 10
5.1
Sostituzione delle JSP tradotte con un modulo Java in architettura MVC ........... 10
5.2
Sostituzione delle librerie proprietarie di interfacciamento al database ............... 10
2
FSE – Architettura Applicativa
1 Introduzione e scopo del documento
Lo scopo del documento è quello di spiegare l’architettura applicativa Fondo Sociale
Europeo, evidenziando gli interventi effettuati per uniformare il sistema.
L’applicativo prima dell’intervento d’omogeneizzazione effettuato si componeva di tre
moduli (CGI-BIN, DDW, Java), oggi abbiamo ottenuto un ambiente uniforme per
piattaforma e run-time.
I vecchi moduli che non utilizzavano tecnologia java sono stati riscritti (CGI-BIN), o
convertiti (DDW) utilizzando un tool sviluppato e messo a disposizione da Regione
Toscana in questo caso è stato necessario ritoccare il codice ottenuto. Ogni singolo
modulo è stato testato.
L’altro intervento effettuato sul sistema FSE è stato adeguato allo standard SRTY di
Regione Toscana.
Uniformando l’applicativo abbiamo ottenuto notevoli vantaggi in termini di manutenibilità e
facilità amministrative.
3
FSE – Architettura Applicativa
2 Versione in produzione
La versione dell’applicazione FSE attualmente in produzione è una web application che
utilizza tre diverse tecnologie software. Le funzionalità che il sistema implementa sono
state realizzate in tempi diversi utilizzando tecnologie diverse, perciò si è venuta a creare
un’architettura applicativa eterogenea che suddivide le funzionalità in moduli separati:
1. Modulo CGI-BIN
2. Modulo DDW
3. Modulo Java
(Schemi, Docenti, Profili)
(Progetti, Attività, Allievi, Rilevazione Spesa, Enti)
(Azioni, Bandi, Impegni, Aiuti, Monitoraggio obbiettivo, Voucher)
Web Server
Tomcat
1.1
2.1
3.1
3.2
Apache
Modulo
Java
Client HTTP
(browser)
1.2
3.3
2.2
Modulo
CGI-BIN
Apache
CGI-BIN
1.3
Modulo
DDW
DB Server
Informix
Database Server
Figura 1 - Architettura dell’applicazione FSE in produzione
Questa suddivisione non è rigorosa: in alcuni casi all’interno di un modulo alcune
funzionalità sono state implementate utilizzando la tecnologia di un altro modulo.
4
FSE – Architettura Applicativa
2.1 Modulo CGI-BIN
Il modulo CGI-BIN è stato sviluppato in linguaggio C++ e la sua esecuzione avviene
all’interno di un modulo apposito che estende le funzionalità dell’HTTP Server Apache.
2.2 Modulo DDW
Il modulo DDW è stato sviluppato utilizzando un linguaggio di scripting proprietario della
piattaforma Informix che consente di realizzare pagine web dinamiche che si interfacciano
al database. La sua esecuzione avviane direttamente all’interno del database server.
2.3 Modulo Java
Il modulo Java è stato sviluppato utilizzando le tecnologie Servlet e JSP (Java Server
Pages) che fanno parte della piattaforma tecnologica Java2 Enterprise Edition. Tale
modulo viene eseguito all’interno del Tomcat, che rappresenta il web container standard di
riferimento.
JavaBean
Servlet
Oggetto
2
CentralServlet
1
COMMAND
6
3
Client HTTP
(browser)
Oggetto
MANAGER
JSP
4
7
Pagina JSP
Oggetto DAO
proprietario
5
Database Server
DB Informix
Figura 2 - Architettura modulo Java in produzione
5
FSE – Architettura Applicativa
L’architettura applicativa implementata utilizza una variante del pattern MVC (Model-ViewController). Il pattern MVC rappresenta una soluzione standard che tende a suddividere la
struttura dell’applicazione in layer separati.

Strato che gestisce l’interazione con l’utente
(controller)

Strato di logica applicativa - business logic
(model)

Strato di presentazione
(view),
Utilizzando la piattaforma Java2 Enterprise Edition, a ciascun layer si associa una diversa
tecnologia:

Controller
Java Servlet

Model
JavaBeans / EnterpriseJavaBeans

View
Java Server Pages
In questo caso è stata utilizzata una variante che prevede una unica servlet
(CentralServlet) come punto di ingresso per tutte le richieste effettuate all’applicazione;
tale servlet agisce come dispatcher demandando ad un oggetto Command il ruolo di
controller. Lo strato di logica applicativa (business logic) è stato realizzato implementando
degli oggetti Manager i quali a loro volta utilizzano lo strato di oggetti DAO (Data Access
Objects) per l’accesso al database.
Lo strato che effettua l’accesso al database (layer DAO) è stato sviluppato utilizzando
librerie proprietarie non standard per le quali non è possibile ottenere alcun supporto. E’
evidente che tale scelta risulta in contrasto con l’orientamento generale della Regione
Toscana che tende ad utilizzare nelle architetture software i framework e le librerie che
rappresentano degli standard open-source (Java, Apache, Tomcat, Hibernate, etc.) per i
quali è rintracciabile tutta la documentazione ed il relativo supporto da parte della
community.
3 Reingegnerizzazione dell’applicazione FSE
La reingegnerizzazione dell’applicazione FSE prevede la sostituzione dei moduli CGI-BIN
e DDW con moduli che implementano le stesse funzionalità in tecnologia Java, in modo
tale da ottenere un’applicazione che utilizzi un’unica piattaforma tecnologica ed un unico
ambiente di run-time con tutti i vantaggi in termini di manutenibilità e facilità di
amministrazione che ne conseguono.
3.1 Sostituzione del modulo CGI-BIN
6
FSE – Architettura Applicativa
La sostituzione del modulo CGI-BIN prevede la riscrittura totale delle funzionalità presenti
mediante l’implementazione delle stesse in codice Java e l’integrazione di tale codice
nell’architettura del modulo Java già esistente. Questo significa che le funzionalità
realizzate avranno sempre la CentralServlet come punto d’ingresso delle richieste, ed a
ciascuna sarà associato uno specifico oggetto Command. Allo stesso tempo la
generazione della presentazione verrà affidata ad una opportuna pagina JSP.
Per quanto riguarda l’implementazione dello strato di logica applicativa, si è ritenuto di non
utilizzare le librerie proprietarie di accesso al database che sono attualmente impiegate sul
modulo Java in produzione, preferendo l’utilizzo del framework Hibernate, considerato
ormai lo standard open-source per questo tipo di soluzioni. Gli oggetti command utilizzano
i servizi del framework Hibernate attraverso degli oggetti DAO opportunamente sviluppati
che incapsulano all’interno di metodi statici tutte le chiamate relative ad una singola
funzionalità applicativa.
JavaBean
Servlet
2
CentralServlet
1
6
Client HTTP
(browser)
Oggetto
COMMAND
3
Oggetto
DAO
JSP
7
4
Pagina JSP
Layer
HIBERNATE
5
Database Server
DB Informix
Figura 3 - Architettura modulo Java in sostituzione del modulo CGI-BIN
7
FSE – Architettura Applicativa
3.2 Sostituzione del modulo DDW
La sostituzione del modulo DDW prevede la generazione di un insieme di pagine JSP che
realizzano le stesse funzionalità. Tale generazione avviene con l’ausilio di un tool
sviluppato da Regione Toscana che consente di effettuare una traduzione automatica
dalle pagine DDW alle pagine JSP corrispondenti. Le pagine JSP così ottenute
necessitano di un’ulteriore attività di codifica manuale per poter essere integrate
nell’applicazione. L’architettura di questo modulo, anche se basata su tecnologia Java,
risulta quindi molto diversa dagli altri due moduli, poiché non vi alcuna suddivisione in
layer distinti ed il codice che esegue la logica applicativa è incorporato all’interno della JSP
stessa.
JSP
1
Database Server
Client HTTP
(browser)
Pagina JSP
tradotta
2
DB Informix
3
Figura 4 - Architettura modulo Java in sostituzione del modulo DDW
4 Integrazione con il sistema di gestione sicurezza SRTY
Il sistema SRTY (Security) è lo strumento che Regione Toscana utilizza per la gestione
dell’autenticazione e dell’autorizzazione degli accessi alle applicazioni Java. La gestione
avviene mediante l’associazione dei ruoli (a cui appartengono gli utenti) ai profili (a cui
appartengono le funzionalità applicative). Questo sistema è implementato attraverso un
vero è proprio framework applicativo che vincola lo sviluppo delle applicazioni ad una ben
determinata architettura. Tale architettura, basata sul pattern MVC, prevede di
8
FSE – Architettura Applicativa
memorizzare in un database tutti i passi dell’applicazione, cioè tutti i passaggi da una
pagina di presentazione JSP all’altra come risultato della richiesta ad una funzionalità
applicativa, così come previsto dalla navigazione dell’applicazione. Ciascun passo
risulterà autorizzato o meno se esiste l’associazione tra il profilo applicativo a cui
appartiene la funzionalità del passo ed il ruolo a cui appartiene l’utente. Se la funzionalità
richiesta è autorizzata allora il framework invoca dinamicamente l’oggetto di business logic
associato all’operazione per inoltrare il risultato della sua esecuzione alla pagina di
presentazione successiva ed effettuare quindi il passo. Questo comporta una completa
configurazione dell’applicazione sull’SRTY memorizzando su database tutte le
informazioni relative alle funzionalità, alle pagine di presentazione, ai passi, ai profili, ai
ruoli e le associazioni tra i profili applicativi e i ruoli.
4.1 Integrazione delle JSP tradotte con il framework SRTY
L’integrazione delle JSP tradotte con il framework SRTY prevede principalmente
l’adattamento al pattern MVC. Ciò implica la scrittura di un oggetto di business fittizio (cioè
che non esegue alcuna logica applicativa) per ciascuna JSP. Inoltre a ciascuna JSP vanno
aggiunti i parametri necessari all’invocazione del servizio sul SRTY.
4.2 Integrazione dei moduli Java con il framework SRTY
L’integrazione dei moduli Java con il framework SRTY prevede di adattare gli oggetti di
business logic alla struttura prevista dal SRTY. Questa operazione va effettuata sia per il
modulo Java presistente sia per il modulo nuovo. Ciascun oggetto dovrà implementare
una determinata interfaccia per essere dinamicamente invocato dal framework. All’interno
di ciascuna JSP di presentazione vanno inseriti i parametri necessari all’invocazione del
servizio.
4.3 Gestione della configurazione SRTY
La gestione della configurazione dell’SRTY prevede di inserire attraverso l’apposito tool
grafico tutte le informazioni necessarie al funzionamento del framework stesso e quindi di
censire di tutte le informazioni relative ai passi previsti dalla navigazione dell’applicazione:

Inserimento delle informazioni relative agli oggetti di business, alle operazioni, alle
funzionalità, alle pagine JSP di presentazione e ai passi.

Trasferimento delle informazioni che attualmente consentono di gestire
direttamente nell’applicazione FSE
l’autorizzazione degli utenti, all’interno
dell’SRTY attraverso l’associazione dei passi ai ruoli
9
FSE – Architettura Applicativa
5 Adeguamenti architetturali successivi
La reingegnerizzazione dell’applicazione FSE sostituisce i moduli CGI-BIN e DDW con
moduli Java ottenendo così un’applicazione basata su un’unica piattaforma tecnologica ed
in grado, quindi, di funzionare all’interno di un unico ambiente di run-time (web container).
Sono evidenti i vantaggi in termini di manutenibilità, estensibilità e semplicità di
amministrazione dell’applicazione grazie a questa nuova configurazione architetturale.
Nonostante ciò l’applicazione presenta ancora un’architettura disomogenea e fuori
standard:

Il modulo realizzato con le JSP tradotte non rispetta il pattern architetturale MVC
con cui sono stati implementati gli altri moduli e risulta di difficile manutenzione.

Le librerie di interfacciamento al database utilizzate nel modulo Java preesistente
sono proprietarie e non hanno più supporto e/o sviluppo.
5.1 Sostituzione delle JSP tradotte con un modulo Java in architettura
MVC
La sostituzione del modulo basato sulle JSP tradotte prevede la riscrittura delle
funzionalità esistenti attraverso un’implementazione che rispetti il pattern MVC ed
utilizzando il framework Hibernate per l’accesso al database.
5.2 Sostituzione delle librerie proprietarie di interfacciamento al
database
La sostituzione delle librerie proprietarie di interfacciamento al database presenti nel
modulo Java preesistente comporta la riscrittura dello strato di gestione della logica
applicativa in modo tale da utilizzare i servizi e gli oggetti forniti dal framework Hibernate.
L’obbiettivo
finale
sarà
ottenere
che
l’applicazione
FSE
abbia
un’architettura
assolutamente omogenea ed aderente agli standard e che tutti i suoi moduli siano basati
su pattern MVC e utilizzino Hibernate per l’accesso al database.
10