Il terzo articolo di questa miniserie sullo sviluppo di un applicativo
“enterprise” verterà sull’architettura dell’applicativo.
The Architecture – L’Architettura
GeRi è una piattaforma
software che nasce con lo scopo di gestire tutte le attività, dirette e
indirette, connesse ad una centro assistenza.
Analizziamo di seguito alcune
scelte di tipo architetturale, prima di passare direttamente alla fase di design
dell’applicativo.
SOA - Service Oriented
Application.
Come è stato evidenziato nei precedenti articoli,
la nostra piattaforma deve essere in grado di “agganciarsi” a servizi di
fornitori esterni per espletare alcune operazioni.
Un esempio su tutti è la
necessità di inviare messaggi SMS.
Ma oltre ad usufruire di servizi
esterni, la nostra piattaforma deve essere anche in grado di erogare
servizi, acquisendo e garantendo quindi un certo grado di flessibilità con
il mondo dell’integrazione.
Erogare/esporre servizi, significa anche
permettere facilmente a sistemi esterni (magari realizzati con linguaggi e
tecnologie differenti) in prima istanza di dialogare con il nostro sistema, e in
seconda istanza di implementare moduli di integrazione con la nostra
piattaforma.
Ad esempio non è da ritenersi rara la possibilità di
“integrazione” del nostro sistema con sistemi di fatturazione di terze parti.
Per questo motivo ritengo valido scegliere un’architettura di tipo SOA
ovvero “Orientata ai Servizi”.
Architectural View
Avendo ben chiaro il contesto architetturale nel quale
intendiamo realizzare la nostra applicazione, analizziamo di seguito alcune
scelte su come organizzare l’architettura dell’applicativo.
L’applicazione sarà organizzata secondo una classica architettura di tipo
N-Tier.
Ma cos’è un applicazione N-Tier?
Una
architettura di tipo N-Tier indica una particolare architettura software che
prevede la suddivisione del sistema in N diversi livelli (logici e fisici) che
svolgono funzionalità diverse (opzionalmente su nodi diversi della rete).
Ad
esempio esiste il livello per la gestione dell’interfaccia utente
(UI Layer), quello per la logica funzionale
(Business Layer) e quello per la gestione della
persistenza dei dati (Data Access Layer).
In
questo modo, ciascuno degli N livelli può essere modificato o sostituito
indipendentemente dagli altri.
Nella maggior parte dei casi, si intende
anche che i diversi livelli siano distribuiti su
diversi nodi di una rete anche eterogenea.
Questo è alla base della distinzione tra Layer e Tier.
- Un Layer indica un raggruppamento logico delle funzionalità
- Un Tier indica un raggruppamento fisico delle funzionalità
Un esempio tipico di architettura N-Tier, dove N=3, detta appunto
three-tier prevede, per esempio:
- un Tier di presentazione identificato da un PC dedicato all'interfaccia utente
grafica (su cui persiste quindi il layer di presentazione o UI Layer)
- un Tier di Business Logic indentificato da una workstation o un application
server per l’esecuzione di business logic
- un Tier di Database indentificato da un database server o un mainframe per
la gestione dei dati.
In merito alla nostra applicazione avremo quindi i seguenti
Layers :
- Data Access Layer (da ora in poi DAL) è il livello di
interazione con la base di dati, dove si effettuano le connessioni e si eseguono
query di selezione, inserimento, aggiornamento o cancellazione.
- Business Layer (da ora in poi BL) è il livello che ha la
responsabilità di gestire le richieste utente ricevute attraverso l’Uil o SL, di
effettuare il routing di queste richieste agli appropriati elementi di business,
di processare i risultati dell'elaborazione e ritornare i dati necessari all’Uil
o SL per la successiva presentazione all'utente.
- Service Layer (da ora in poi SL) è il livello che svolge la
funzione di “collante” tra il BL e l’UiL ed è caratterizzato da un numero di
servizi che espongono al “mondo esterno” le funzionalità business.
- User Interface Layer (da ora in poi UiL) è il livello che
si occupa della presentazione e della logica di interazione con l'utente,
interagendo con il BL per l'accesso ai servizi richiesti.
Organizzati nei seguenti Tiers :
- Database Tier, ovvero il livello fisico su cui deployeremo il nostro
Database.
- Application Server Tier, ovvero il livello fisico su cui deployeremo il BL e
il SL.
- Presentation Tier, ovvero il livello fisico su cui deployeremo l’interfaccia
grafica della nostra applicazione.
Ritengo concluso il terzo articolo della serie, che è servito a delineare
l’aspetto architetturale su cui si fonda la soluzione da implementare.
Scopo
del prossimo articolo sarà quello di “creare gli use cases” e quindi
"disegnare il nostro Core".
Non mi resta quindi che finire con il
classico :
See u in the next
episode
(Fonte : Alessandro Forte - http://www.alessandroforte.it/)