Scegliere un’architettura: linee guida e ruolo del middleware

Come già trattato nell’articolo precedente “Dallo studio di fattibilità; alla software selection: analisi e scelta degli strumenti e delle tecnologie“, un team di sviluppo ha a disposizione un insieme ragionevolmente ampio di scelte e alternative. Inoltre, i diversi stili architetturali possono essere combinati per ottenere strutture e architetture complesse. I criteri principali (e iniziali) si riferivano alla scelta tra prodotti/applicazioni industriali e prodotti/applicazioni Open Source.

Introduzione metodologica alla scelta architetturale

Come si sceglie un’architettura?
Come si giunge a scegliere uno stile architetturale (o una combinazione di stili) tra i tanti possibili?

Se è vero che l’architettura di un sistema non è derivabile in modo diretto dalla natura e struttura del problema, quali criteri e linee guida occorre seguire nel progettare la soluzione? In realtà questo passaggio costituisce uno degli elementi più critici e complessi del lavoro iniziale della analisi architetturale.
In questa fase entrano in gioco aspetti quali l’esperienza del team di sviluppo, della sua capacità di analisi e sintesi, ma anche di intuito e di creatività. Il problema da risolvere in ordine allo sviluppo e/o reengineering di un sistema informativo è stato “osservato e studiato”.
In generale, è difficile ricondurre la scelta di una soluzione architetturale a un mero processo o metodo sistematico che determina in modo meccanico quale alternativa preferire. Ci sono peraltro una serie di criteri e di linee guida che possono essere seguiti come qui di seguito andiamo ad enunciare.

Linee guida e aspetti considerati

a) Scelte architetturali già perseguite in casi simili: il DSSA – Domain Specific Software Architecture, l’ambiente e le caratteristiche del dominio applicativo dell’azienda.

Esempio: DSSA Domain Specific Software Architecture Activity Flow
(Fonte: The Domain-Specific Software Architecture Program)

In primo luogo, esistono soluzioni architetturali per specifici settori applicativi. Per esempio, nel caso dei sistemi di controllo, vi sono architetture di riferimento che possono essere raffinate e adattate al caso specifico. Nel mondo delle applicazioni per Internet, la stessa architettura J2EE (Java Platform, Enterprise Edition) identifica una serie di elementi e componenti per la costruzione di applicazioni distribuite client-server multilivello.
Il team di progetto, a fronte di un problema, può quindi innanzitutto valutare le scelte architetturali già perseguite in casi simili e che si sono rivelate efficaci per quel tipo di problemi. Negli anni scorsi, è stata creata l’espressione Domain Specific Software Architetture proprio per indicare soluzioni architetturali ottimali per “specifici domini applicativi”.

b) L’analisi dei requisiti e dalle caratteristiche

Occorre chiedersi: quale architettura è più coerente con le richieste del committente?
Più in generale, la definizione dell’architettura di un sistema complesso viene effettuata studiando i requisiti (vedi anche “Implementazione di un CRM: un confronto tra approccio applicativo e organizzativo“) e le caratteristiche del problema sia da un punto di vista funzionale che non funzionale.
I risultati di queste analisi sono confrontati con le caratteristiche e proprietà tipiche dei diversi stili e da questo nascono le ipotesi architetturali. Se il problema, per esempio, è l’integrazione di archivi dati gestiti da organizzazioni autonome, è evidente che nascono (almeno) due possibilità:
– o si consolidano tutti i dati in un archivio centrale, con un sistema client-server (magari a più livelli per ottimizzare le prestazioni complessive)
– oppure si adotta un’architettura P2P – Peer-to-Peer, nella quale ciascuno continua a essere “padrone e gestore unico” dei propri dati. In questo secondo caso, si pone il problema di come propagare query e operazioni di aggiornamento delle informazioni. Quindi si potrebbe pensare a un sistema P2P ibrido oppure a un’architettura composita P2P + publish-subscribe.

La scelta tra queste diverse alternative deve considerare il trade-off (vantaggi e svantaggi della scelta, considerando anche gli aspetti di costo-opportunità) che ciascuna soluzione comporta.
Se per esempio le funzioni e operazioni svolte da ciascun nodo autonomo sono le stesse e avvengono su dati assolutamente identici, non ha senso avere una replicazione dei sistemi: un sistema centralizzato (magari ridondato per garantire fault-tolerance e affidabilità) è la soluzione più conveniente dal punto di vista economico e gestionale. Se invece i diversi nodi hanno, almeno in parte, dati diversi con funzioni che possono mutare o evolvere in modo indipendente, è preferibile (se non obbligatorio) attuare una strategia distribuita P2P.
In ogni caso, è evidente che il team di progetto si trova di fronte a un insieme non limitato di alternative.
Spesso, esse non sono presenti solo o principalmente a livello di stile architetturale, ma anche e soprattutto a livello di variante o specifica implementazione dello stile o di combinazione di stili.
Sono l’esperienza, le competenze, l’intuito e la professionalità di un team di progetto a costituire la chiave di volta per affrontare questo passaggio in modo efficace e convincente.

c) Il deployment le infrastrutture IT: le prestazioni e l’efficienza del sistema

La scelta di un’architettura deve essere guidata anche da considerazioni di carattere prestazionale. Potrebbe essere necessario, per garantire un certo tipo di prestazioni, dover valutare quale architettura risulti più conveniente, oppure come una certa architettura debba essere rivista o adattata per conformarsi al problema specifico.

– Per esempio, dovendo gestire un alto carico di richieste in un sistema client-server multi-tier, potrebbe essere utile avviare studi che valutano, dal punto di vista della capacità complessiva di risposta, architetture a tre o quattro livelli, con diversi meccanismi di distribuzione delle funzioni applicative o dei criteri di replica e gestione dei tier intermedi.
– Da tempo, questo tipo di analisi è condotto simulando e studiando il comportamento delle diverse architetture tramite modelli matematici basati sulla teoria delle code (o tecniche simili). Tali approcci sono piuttosto diffusi in molti settori dell’ingegneria e sono certam
ente di ausilio anche al team di progetto.

d) II ruolo del middleware (Orchestration, ESB – Enterprise Service Bus e WorkFlow)

Da Wikipedia: con il termine middleware
oggi si intendono una serie di strumenti come DBMS, Web server, Application server, sistemi di gestione dei contenuti ed altri strumenti basati sul concetto di sviluppo e pubblicazione di applicazioni e contenuti. Gli sviluppi attuali si dirigono verso XML, SOAP, servizi Web e architetture orientate ai servizi.
Un aspetto importante che influisce in modo significativo sull’attività di progettazione è la scelta del middleware. Infatti, è indubbio, e alcuni studi lo hanno dimostrato, che l’utilizzo di una particolare tecnologia di middleware influisce sulle scelte architetturali. Può persino accadere che l’adozione di un tipo di middleware renda più o meno facile (e persino possibile) la realizzazione di una soluzione basata su una specifica architettura.

– Tecnologie a eventi
Un caso esemplare è costituito dalle tecnologie di middleware a eventi (tipo JMS – Java Message Service).
Queste tecnologie forniscono operazioni e servizi per gestire la pubblicazione e ricezione di eventi: offrono il dispatcher e i servizi di publish, subscribe, push e pull.

– Architettura publish-subscribe
Dovendo realizzare un’architettura publish-subscribe, è indubbio che la disponibilità di questo tipo di tecnologia faciliti grandemente tutto il processo di sviluppo.
Il team di progetto può concentrarsi nell’identificazione dei diversi componenti dell’architettura, dei tipi di eventi da scambiare e della gestione della chiamata dei servizi offerti dal middleware, ignorando gli aspetti implementativi della gestione degli eventi.Questa architettura consente un’elevata scalabilità.

– Sistema client-server
Al contrario, se si dovesse realizzare un sistema client-server utilizzando un middleware a eventi, il team di progetto si troverebbe di fronte a problemi non marginali. Certamente è possibile realizzare una chiamata sincrona attraverso pubblicazioni di eventi e sottoscrizioni, ma il compito del team di progetto sarebbe alquanto ostico.
Chi richiede un servizio deve pubblicare un evento con le informazioni sul servizio richiesto.
Il ricevente deve essersi già sottoscritto a quel tipo di evento. In caso contrario, la richiesta va persa e il richiedente rimane inascoltato (senza avere meccanismi efficienti per venirlo a sapere in tempi rapidi).
Quando chi offre il servizio riceve l’evento di richiesta, deve generare un nuovo evento con la risposta.
Il richiedente del servizio deve essersi registrato per tempo, per poter essere sicuro di ricevere l’evento di risposta.
Come si può facilmente desumere, pensare di gestire interazioni client-server con questo meccanismo è semplicemente improponibile: appare quindi evidente che la scelta del middleware possa avere un’influenza più o meno significativa sull’architettura (e viceversa).

In generale, ogni tecnologia di middleware, in modo più o meno invasivo, induce uno o più stili architetturali. Esistono tecnologie di middleware molto semplici e flessibili che possono essere utilizzate per tutti gli stili architetturali.
Altre sono particolarmente adatte a realizzare solo uno o pochi stili.

– Adozione della RMI – Remote Method Invocation
Per esempio, con l”adozione della RMI – Remote Method Invocation, invocazione remota di metodi) si utilizza una tecnologia che consente a processi Java distribuiti di comunicare attraverso una rete.
Questa tecnologia include una API (application programming interface) il cui scopo esplicito è quello di rendere trasparenti al programmatore quasi tutti i dettagli della comunicazione su rete.
Essa consente, infatti, di invocare un metodo di un oggetto remoto (cioè appartenente a un diverso processo, potenzialmente su una diversa macchina) quasi come se tale oggetto fosse “locale” (ovvero appartenente allo stesso processo in cui è eseguita l’invocazione). In questo senso, la tecnologia RMI può essere ricondotta, da un punto di vista concettuale, all’idea di chiamata di procedura remota riformulata per il paradigma object-oriented (in cui, appunto, le procedure sono sostituite da metodi).
Con RMI è possibile realizzare sistemi client-server a più livelli e, con un po’ di programmazione aggiuntiva, anche sistemi P2P. Le architetture J2EE (Java Platform, Enterprise Edition) sono particolarmente adatti a sistemi client-server multi-tier con codice mobile di tipo COD (tramite gli applet), mentre può risultare (nella sua configurazione completa) particolarmente pesante e onerosa per gestire sistemi P2P con funzioni RE (Remote Evaluation).

Avendo scelto uno stile architetturale, è quindi necessario assicurarsi che il middleware prescelto sia compatibile con la scelta fatta. Il middleware gioca inoltre un ruolo importante anche nella scelta di componenti da integrare in un sistema informatico esistente o già parzialmente implementato.
Infatti, se il componente utilizza meccanismi di middleware e logiche di funzionamento (interfacce) non compatibili con il “sistema ricevente”, si ha una situazione di integrazione impossibile (“rigetto”) o estremamente costosa (è necessario costruire adattatori che facciano da interprete tra le diverse parti).
Ancora una volta, emerge un problema di scelta progettuale che vede il team di progetto giocare un ruolo essenziale. Nel determinare l’architettura del sistema e il middleware di supporto, il team di progetto deve assicurarsi che non vi sia architectural mismatch, cioè incompatibilità architetturali tra i diversi elementi dell’architettura e in particolare tra essi e il mid
dleware scelto per implementarli.

Da dove partire: l’approccio Top-down e Bottom-up

In diverse circostanze, è emerso un tema particolarmente rilevante: nella progettazione e realizzazione di un sistema informatico si procede in modo top-down o bottom-up?
– L’approccio Top-down
Deriva direttamente dalla logica dello stepwise refinement:
si parte dall’astrazione massima e progressivamente la si raffina in funzioni elementari e quindi in codice. Più in generale, si definisce l’architettura del sistema e si raffinano i ai diversi componenti ed elementi che ne emergono.
“Scendendo” a livello di componente si giunge a progettare il modulo e quindi il codice dei singoli metodi o procedure.
– L’approccio Bottom-up
Si parte da componenti già pronti o facilmente realizzabili e li si assembla progressivamente fino a costituire il sistema completo.
È l’approccio che sfrutta al meglio i cicli di vita basati sul riuso di componenti (component-based development).

Leonardo Milan

Technorati Tag: Studio di fattibilità,Software Selections,percorso decisionale e implementativo