Cinque regole, da tenere bene in mente, nell’implementazione di un’architettura di servizi, per evitare di cadere nella trappola dei “più comuni passi falsi” sulla strada verso le Soa: Trattare le Soa alla stregua delle tradizionali architetture distri …
Cinque regole, da tenere bene in mente, nell’implementazione di un’architettura
di servizi, per evitare di cadere nella trappola dei “più comuni
passi falsi” sulla strada verso le Soa:
Trattare le Soa alla stregua delle tradizionali architetture distribuite: molti,
nel passato recente, sono caduti nella trappola di assimilare (e trattare di
conseguenza in modo analogo) le Soa come le architetture distribuite che, in
realtà, hanno orientamenti e paradigmi del tutto diversi. Comprendere
queste differenze è fondamentale per riuscire a creare logiche di automazione
realmente orientate ai servizi.
Non standardizzare: la mancanza di definizioni comuni su come i dati debbano
essere rappresentati, su quale sia l’interfaccia privilegiata per quel
servizio o sulla sua semantica, possono comportare non pochi problemi. Le Soa
promuovono la creazione di un ambiente di sviluppo che astrae, di fatto, il
processing dal backend, che potrà quindi essere in grado di eseguire
delle applicazioni in modo indipendente. La standardizzazione è necessaria
per assicurare una certa consistenza e unità logica nello sviluppo e
nell’interazione tra i servizi che incapsulano queste logiche di backend.
Non creare un piano di transizione: la mappatura dei singoli servizi e la definizione
dei possibili percorsi degli stessi, potrebbe portare alla ridefinizione dell’ambiente
infrastrutturale. L’adozione di un piano di transizione permetterà
di controllare tutte le fasi di migrazione alla Soa, sia sotto il profilo tecnologico
che sotto quelli architetturale e organizzativo. Gli elementi chiave di questo
piano sono: l’analisi d’impatto (che dovrebbe prevedere le ripercussioni
delle Soa sulle attuali risorse, processi e tecnologie); l’analisi della
transizione delle architetture (che mappa tutti i possibili stadi intermedi
dalla situazione attuale verso l’adozione definitiva di un’architettura
di servizi) e l’analisi speculativa (che dovrebbe valutare gli sviluppi
futuri dei servizi Web in azienda e stimare le necessità correlate in
termini di tecnologie di supporto).
Non partire con un’architettura fondata su Xml: l’eXtensible markup
language, infatti, è lo standard fondamentale per la rappresentazione
dell’architettura dati, anche se, nel corso degli anni, altre specifiche
si sono candidate a sostituirlo in questi compiti. Le questioni relative alla
struttura e alla validazione dei dati sono, infatti, fondamentali anche se molto
spesso vengono trascurate. L’implementazione di un livello di rappresentazione
dei dati fondato su Xml risulta, invece, necessaria e la sua mancanza può
inficiare anche un ottimo lavoro di sviluppo.
Non comprendere le implicazioni delle performance: l’adozione di un’architettura
fondata su legami “deboli” (loose coupling) all’interno dei
suoi singoli elementi non è facile. Occorre, infatti, introdurre diversi
livelli di processing dei dati, che si stratificano, e tenere in conto l’impatto
sulle performance complessive dell’architettura dovuta a queste stratificazioni.
Ragionando su scala ridotta, è facile creare soluzioni che funzionano
e rispondono bene. Tuttavia, quando la pervasività delle Soa aumenta
e molte nuove funzionalità sono integrate, il volume delle comunicazioni
aumenta considerevolmente e i processi potrebbero subire una forte latenza.
Ecco perché risulta fondamentale riuscire a comprendere da subito quali
sono le implicazioni a livello di prestazioni, ovvero testare le capacità
di processing dei messaggi dell’infrastruttura di comunicazione (message
bus) e valutare attentamente le caratteristiche dei servizi, in modo da riuscire
a garantire un compromesso accettabile tra velocità di trasmissione,
“peso” delle trasmissioni e altri elementi che potrebbero influenzare
negativamente le prestazioni della soluzione.
