Home > java > Architettura Esagonale

Architettura Esagonale

15 ottobre 2013

Translate in English with Google Translate

Evoluzione architettura enterprise
Nel corso degli anni l’architettura software ha subito delle continue innovazione sia per motivi commerciale che a seguito di evoluzioni tecnologiche. Focalizzandosi sulle evoluzioni tecnologiche si è passati da architetture centralizzate ad architetture distribuite.
Inizialmente le architetture erano basate su Mainframes e l’accesso avveniva esclusivamente tramite Terminali, tutto il software era residente su un singolo server, il Mainframe.

mainframe

Mainframe

Negli anni ’80 si è passati ad architetture di tipo Client-Server in cui il Client o Fat-Client si occupava di gestire le logiche di visualizzazione mentre il Server gestiva le logiche di business e la gestione dei dati.

client/server

Client / Server

Con l’avvento di internet si è passati ad architetture di tipo 3-tier in cui il Client o Thin-Client era rappresentato da semplici programmi, come il browser, per accedere tramite la rete al Server che presentava una suddivisione delle competenze ripartite in presentation, business e data layer. Il presentation layer si occupava delle logiche di presentazione, il business layer delle logiche di elaborazione ed il data layer della gestione dei dati. Tali compiti venivano delegati rispettivamente a Web Server, Application Server ed al Database.

3-tier

Three Tier

Dando uno sguardo alle modalità di intercomunicazione si è passata da una architettura di tipo EAI, ad una SOA per arrivare ai nostri giorni al Cloud.
Una architettura EAI ( Enterprise Application Integration ) si basa sulla presenza di un Hub, un Canale o Bus di comunicazione, che consente di mediare e centralizzare la comunicazione tra i sistemi coinvolti, evitando di configurare le connessioni secondo una modalità point-to-point e generare un sorta di “spaghetti connection”. Le comunicazione tra sistemi eterogenei sono resi possibili dall’ausilio di Adapter che “adattano” cioè traducono i messaggi provenienti dai diversi linguaggi in un formato riconoscibile.

EAI

EAI

Con l’introduzione delle architetture SOA (Service Oriented Architecture) si è passati ad introdurre ulteriori componenti: ESB, BPM, Registry, Web Services ecc; l’architettura è orientata intorno al concetto di servizio e  di composizione di servizio.

soa

SOA

L’avvento del Cloud Computing ha introdotto un grado di astrazione all’architettura sottostante che viene ridimensionata in base alle esigenze e ciò consente di ridurre quel gap tra il business e l’IT consentendo all’impresa di guadagnare quel Time-to-Market ossia essere veloce nel rispondere alle esigenze del mercato. Ma tutto diventa un servizio vendibile: il software, la piattaforma e l’infrastruttura. Come non essere daccordo con Richard Stallman che vede in questo una politica di marketing che porta ad un progressivo vendor lock-in, forse inevitabile.

cloud

Cloud

Conseguenze evolutive
L’evoluzione dell’architettura ha generato una frammentazione delle competenze, basti guardare alla differenza tra una architettura basata su mainframe rispetto ad una architettura SOA.
Sicuramente questo consente di gestire in modo sempre più preciso una serie di requisiti non funzionali: sicurezza, performance, manutenibilità, scalabilità ecc.
Questo ha comportato che l’applicazione ha intensificato notevolmente la sua rete di comunicazione con una fitta serie di componenti:

  • sistemi esterni: vari device come cellulari, palmari, pc, tablet ecc che comunicano in formati diversi
  • sistemi interni automatici: come sistemi di monitoraggio, test automatizzati, gestori di eventi
  • sistemi interni inter-applicativi: componenti utilizzati dall’applicazione: Identity Access Manager, Datasource, Sistemi legacy.

Questa fitta rete di comunicazione e di interscambio dati, se da un lato consente di distribuire le competenze, produce un disorientamento in termini di sviluppo applicatico ed esecuzione di test.

  • In termini di sviluppo: il software non è più centralizzato in un unico posto ma è distribuito su diversi server oltrettuto replicati, pertanto occorre effettuare degli specifici interventi, per esempio modificare la presentazione (JSP, Tag file, JSF, HTML, Javascript, CSS), la logica (classi, file di configurazione ecc). Quindi anche lo sviluppo è diventato distribuito, non esiste più un concetto di “centro”, il centro è semplicemente ciò che ci interessa in quel momento. E’ un pò come cercare il centro in uno spazio infinito, esistono infiniti centri!
  • In termini di test: la loro esecuzione è sempre più spostata verso i test di integrazione più che verso i test unitari. Ce ne accorgiamo quando dobbiamo testare delle funzionalità, solo quando tutti i sistemi sono startati riusciamo a fare una semplice prova. A volte anche testare una nuova form html diventa un’impresa: configurare LDAP per l’autenticazione, il database per l’accesso ai dati, il CICS per i dati legacy, i Web Services per i servizi di profilazione ecc. Ovviamente a seconda del caso occorre configurare i sistemi di riferimento.

Tutto ciò sposta l’attenzione e richiede delle competenze trasversali.

Architettura Esagonale
Un approccio interessante a questo problema è presentato dall’Architettura Esagonale, anche conosciuto come pattern “Ports and Adapters” di Alistar Cockburn, che si propone di centralizzare l’attenzione sull’applicazione e decentralizzare tutti i sistemi esterni.
L’applicazione dialoga con i sistemi esterni tramite delle porte le quali utilizzano un adapter per dialogare con diveri sistemi. A loro volta i sistemi esterni passando per una porta applicativa, vengono filtrati da un Adapter che si occupa di tradurre il messaggio in un formato conosciuto e permettere il dialogo. Pertanto sia l’applicazione che i sistemi esterni sono ignoranti in merito alla natura del sistema contattato, sono interessati solamente al messaggio.
Il sistema prevede una comunicazione I/O, di input/output, entrata/uscita, da/verso i sistemi esterni.

Vediamo cosa dice l’autore:

Create your application to work without either a UI or a database so you can run automated regression-tests against the application, work when the database becomes unavailable, and link applications together without any user involvement.
Allow an application to equally be driven by users, programs, automated test or batch scripts, and to be developed and tested in isolation from its eventual run-time devices and databases. (Alistar Cockburn)

esa

Questa architettura ha molti punti in comune con la “Onion Architecture” cioè “Architettura a cipolla” proposta da Jeffrey Palermo.

Vediamo quali sono le principali caratteristiche di questa architettura e le sue differenze rispetto ad una architettura n-tier:

  • In una classica architettura n-tier, la chiave di lettura è da sinistra a destra, oppure dall’alto al basso; in questo caso la chiave di lettura è dal centro verso l’esterno, ossia dall’applicazione ai sistemi esterni.
  • Questa architettura pone sullo stesso piano tutti i sistemi esterni all’applicazione pertanto tratta in modo simmetrico tutti gli attori. In una architettura n-tier, esiste invece una asimmetria tra utenti e sistemi contattati, gli utenti sono gli attori principali, ossia coloro che guidano l’applicazione mentre i sistemi contattati sono gli attori secondari, ossia coloro che sono guidati dall’applicazione.
  • per ogni Port è possibile assiciare diversi Adapter che hanno l’obiettivo di comprendere le diverse implementazioni dello stesso servizio. Per esempio una Port può essere utilizzata per l’accesso al database che a sua volta può essere Oracle, MySql, un database in-memory, un mock.
  • le Port possono essere utilizzate dai vari attori: utenza web, utenza applicative, utenze amministrative
  • la rappresentazione in forma esagonale consente di visualizzare l’interazione dei sistemi esterni con l’applicazione passando per una dimensione, si riceve l’input dell’utente e si interroga il database per estrarre i dati. Ma l’applicazione spesso interagisce con molti sistemi e questo comportamento può essere rappresentato in modo più efficace e comprensibile utilizzando una rappresentazione esagonale in cui si evidenziano le multi dimensioni
  • l’applicazione non deve essere vista come una sequenza di passi che vede ad un estremo l’utente che interagisce con l’applicazione e dall’altro estremo il database; l’applicazione invece deve essere vista come un corpo centrale indipendente dai sistemi esterni che può vivere autonomamente senza avere la necessità di interagire con essi.
  • l’architettura applicativa può essere paragonata all’architettura di un sistema operativo, l’applicazione è paragonabile al kernel, gli adapter sono paragonabili ai moduli del kernel, i sistemi esterni sono i device, mentre i messaggi sono delle system call.
esagon

Kernel/Port/Adapter

Per altri approfondimenti potete vedere qui, qui e qui

Categorie:java
%d blogger cliccano Mi Piace per questo: