|
Negli
scorsi articoli abbiamo parlato di SOA sia dal punto
di vista architetturale (vedere [MOKA_SOA_I]) che delle
metodologie di analisi e di design (vedere [MOKA_SOA_II])
.
Un’azienda
che decide di evolvere il proprio sistema informativo
verso una architettura SOA deve fare diverse scelte
e fronteggiare numerose sfide. In
[MOKA_SOA_III] abbiamo visto come sia indispensabile
capire quanto l’organizzazione che vuole utilizzare
architetture a servizi sia matura per l’effettiva
adozione di queste. Implicitamente ciò significa
confrontare il grado di maturità tecnologica
di un’azienda con un “maturity model”,
quindi in pratica effettuare un’operazione di assessment.
Una volta capito/stabilito quanto un’azienda è
matura nella sua implementazione di un’architettura
SOA-oriented, è possibile definire i passi da
intraprendere: l'insieme di questi passi definisce la
Roadmap per l'evoluzione dell'organizzazione verso un'adozione
di SOA più matura.
Roadmap
Una
volta capito/stabilito quanto un’azienda è
matura nella sua implementazione di un’architettura
SOA-oriented, è possibile definire i passi da
intraprendere.
SOA
è una strategia da adottare non a big-ben sull’ambiente
IT esistente ma bensì deve essere integrata con
l’esistente in modo incrementale e razionale: la
roadmap è la descrizione dei passi aziendali
(organizzativi, tecnici, metodologici e culturali) che
devono definire un processo evolutivo ed incrementale.
L'esempio di roadmap che esporremo è stato elaborato
cercando di individuare i macro-step più importanti
(in effetti è possibile dettagliarlo ulteriormente)
e con l'obiettivo ambizioso di un'organizzazione che
abbia completamente assorbito tutti gli aspetti di SOA
e che di conseguenza ne ricavi il maggior valore possibile.
Questa Roadmap deve essere quindi considerata un "condensato"
e non ha pretesa di essere esaustiva: può essere
piuttosto il punto da cui partire per elaborare una
strategia nel momento in cui ci si trovi di fronte ad
un caso concreto.
Figura 1: La roadmap proposta
Raggruppiamo i passi della RoadMap in quattro step:
Intial Services, Architected Services, Process Driven
Services, fino a raggiungere il SOA Nirvana!
Initial
Services
Iniziamo ponendoci nelle condizioni di attuare la fase
1 della roadmap: l’integrazione punto-punto (P2P).
Per focalizzare meglio le idee ed i passi della roadmap,
si prevede l’uso tecnologico dei Web Services.
Un
Web Service è un servizio riutilizzabile che
può essere richiamato attraverso tecnologie internet
e che dialoga in XML. La rappresentazione dei dati nei
Web Services avviene mediante XML e per questo sono
definiti “language-neutral”.
I WS utilizzano per la comunicazione protocolli standard
internet (es: HTTP) e per questo sono definiti “platform-netural”.
I WS sono quindi standard-based, language e platform
neutral: sono i candidati ideali per semplificare le
problematiche d’integrazione e per l'implementazione
dei servizi (vedere [MOKA_WA_1], [MOKA_WS_2]).
Figura 2: Web Services
A questo livello (P2P integration) i problemi tecnologici
d’integrazione si semplificano, si razionalizza
il modus-operandi d’integrazione (Service Wrappers
/ Service Adapters), si rimpiazzano le API proprietarie
con API standard-based (che non è poco!) ma problematiche
di architettura (es: spaghetti integration), di sicurezza,
… non vengono modificate in alcun modo.
Di fatto a questo livello della roadmap si ha la stessa
torta, ma ricoperta con una nuova crema.
Figura 3: P2P integration
A questo punto siamo pronti a introdurre componenti
infrastrutturali e ad affrontare problematiche tecnologiche,
come ad esempio l'introduzione della gestione della
sicurezza per l'accesso ai servizi (dove sia necessario).
Ci muoviamo verso una prima versione prototipale di
SOA (SOA Pilots) che deve essere utilizzata per verificare
l'architettura e dimostrare al management che i principi
enunciati sono effettivamente utilizzabili.
In questa realizzazione prototipale è importante
seguire in maniera ferrea tutti i dettami architetturali
di cui abbiamo già parlato. A questo livello,
comunque, i prototipi hanno principalmente lo scopo
di sperimentazione tecnologica.
Figura 4: Initial Services
Una volta completato questo livello siamo sufficientemente
confidenti con le tecnologie che vogliamo utilizzare
e cominciamo a conoscere l'architettura più a
fondo; occorre considerare però che questa sperimentazione
è generalmente “confinata” nell’ambito
del gruppo R&D dell’IT.
Architected
Services
L'obiettivo è iniziare a assorbire SOA culturalmente
all'interno dell'organizzazione. Si comincia ad introdurre
il Service Model, che permette di definire sia i requisiti
che l'interfaccia delle implementazioni tecniche (Service
Contract).
Si inizia a comprendere l'importanza di disegnare servizi
“coarse-grained” e debolmente accoppiati con
il service consumer, e nuovi sviluppi vengono iniziati
con questi obiettivi.
Il Service Model ha una semantica ben definita (quella
dei servizi) e può essere oggetto di modellazione
MDA (in questo caso si parla di SOA Metamodel). L'acquisizione
di questi concetti è poi di supporto a tutta
l'attività dei livelli successivi della roadmap.
Di fatto nel livello precedente abbiamo introdotto i
servizi dal punto di vista tecnologico: ora introduciamo
il linguaggio comune con cui l'organizzazione può
descrivere il suo sistema informativo.
Si inizia quindi a “istituzionalizzare” i
concetti di SOA a livello organizzativo.
In parallelo, cominciano a emergere problematiche di
infrastruttura e di gestione.
Si iniziano ad individuare delle categorie di servizi
infrastrutturali che vengono progettati e implementati
a supporto dei servizi di business. Esempi tipici sono
la sicurezza/autorizzazione, logging, alerting...
Inoltre l'acquisizione da parte dell'organizzazione
dei concetti di SOA comincia a porre problemi di gestione
(SOA Management) che possono comprendere problematiche
come:
- Ciclo
di vita dei servizi (versionamento, analisi delle
dipendenze, deprecabilità)
- Qualità
dei servizi
- Definizione
della capacità dei servizi (livelli di servizio,
scalabilità, …)
- Monitoring
- Management
(configurazione, attivazione, etc)
- Business
Activity Monitoring (BAM)
Alla
fine di questa parte del percorso avremo definito dei
servizi mission-critical supportati da servizi di infrastruttura
che l'organizzazione è in grado di gestire. Inoltre
sarà presente una notazione comune che sia gli
esperti funzionali che gli architetti possono utilizzare
per la definizione del sistema informativo.
Figura 5: Architected Services
Business
Services
Come
possiamo ora evolverci? Il passo successivo è
l'introduzione di strumenti per la gestione dei processi.
Da questo momento le applicazioni vengono disegnate
(o ristrutturate) come orchestrazione di servizi, che
a loro volta possono essere costruiti componendo altri
servizi. E' qui che si comincia ad avere un forte ritorno
sull'adozione di questo tipo di architettura, e si mette
in pratica la capacità di riutilizzo che fino
a questo punto era in gran parte “potenziale”.
Analisti e Architetti lavorano in sinergia utilizzando
il concetto di servizio e i concetti SOA sono diffusi
a tutti i livelli IT.
Verificando il riutilizzo e la capacità di composizione,
l'organizzazione è anche spinta a condividere
i servizi tra processi e applicazioni differenti e a
condividere i servizi con altre organizzazioni che cooperano
con essa.
A questo punto si può abbandonare il concetto
di servizio “statico” muovendosi da un'integrazione
punto a punto a una integrazione dinamica (cioè:
ricerca di un service provider da parte di un service
consumer).
Questo permette di disaccoppiare Service Consumer e
Service Provider. Il consumer “cerca” il servizio
pubblicato nel Service Registry per poi utilizzarlo.
Figura 6: Business Services
Si
può fare di meglio?
SOA
Nirvana
Uno
dei problemi che un'organizzazione incontrerà
a questo livello è che, avendo risolto il problema
dell'integrazione dal punto di vista tecnologico e architetturale,
si troverà a dovere risolvere il problema dell'integrazione
a livello dei dati.
Questo problema risiede nel fatto che, se da una parte
è vero che SOA porta a esporre il data model
ad un livello di astrazione più alto (non so
se i dati che arrivano sono ricavati da un DBMS, un
sistema legacy, ecc…) è vero anche che la
struttura dell'informazione non è definita e
la devo conoscere a priori se voglio integrarmi con
un servizio che la espone: devo cioè conoscere
a priori la semantica dell'informazione che il mio sistema
deve elaborare.
Questa questione in realtà è sempre presente,
ma di solito viene “mascherata” da problemi
di integrazione più contingenti, che in questo
caso non si presentano perchè vengono risolti
dall'infrastruttura SOA.
Il concetto di Semantic Integration riguarda questo
problema, partendo dalla considerazione che il problema
dell'integrazione dei dati è dovuto al fatto
che non conosco la loro semantica. Posso risolvere il
problema introducendo un sistema di definire la semantica
dei dati che sia “elaborabile”, ad esempio
attraverso il concetto di ontologia.
In pratica un’ontologia (che può essere
definita in Web Ontology Language, uno standard W3C
(vedere [OWL]) permette di definire un modello con relazioni
e regole con cui è possibile “catturare”
le relazioni semantiche tra i dati. La descrizione del
data model tramite ontologie può permettere l'automatizzazione
dell'integrazione tra servizi.
A questo punto abbiamo gli strumenti per definire l'integrazione
tra i dati: possiamo “maneggiare” i dati prodotti
da servizi esterni (se ne conosciamo le ontologie).
In conclusione abbiamo tutti i prerequisiti di astrazione
(tecnologica, architetturale e a livello dei dati) perché
l'integrazione sia meno “dolorosa” possibile.
L'organizzazione che è a questo livello è
in grado di adattarsi velocemente al cambiamento con
costo minimo e integra il proprio sistema informativo
senza problemi all'esterno con altre aziende con livello
di maturità analogo. Il riuso della logica già
scritta è incoraggiato e il management è
in grado di comprendere l'architettura fino ad un dettaglio
che in precedenza non possedeva.
Figura 7: SOA Nirvana
Conclusioni
In
questo articolo abbiamo parlato dell’importanza
di avere una roadmap che definisca i passi aziendali
(organizzativi, tecnici, metodologici e culturali) per
definire un processo evolutivo ed incrementale con l'obiettivo
di una architettura SOA matura.
Abbiamo
inoltre proposto una implementazione di Roadmap che
prevede una serie di passi essenziali da seguire, cercando
di mantenere un giusto equilibrio tra completezza e
pragmatismo; esistono in rete anche altre proposte di
roadmap molto interessanti, come ad esempio quella di
Zapthink (vedere [ZAPTHINK_RM]).
Figura 8: Roadmap
Bibliografia
[MOKA_SOA_I]
M. Piraccini, S. Rossini: SOA: Introduzione - MokaByte
100
Ottobre 2005 http://www.mokabyte.it/2005/10/soa-1.htm
[MOKA_SOA_II] M. Piraccini,S. Rossini: SOA: Metodologia
- MokaByte 101 - Novmbre 2005
http://www.mokabyte.it/2005/11/soa-2.htm
[MOKA_SOA_III] M. Piraccini,S. Rossini: SOA (III): Il
Maturity Model - MokaByte 102 - Dicembre 2005
http://www.mokabyte.it/2005/12/soa-3.htm
[MOKA_WS_1] S. Rossini, R. Spazzoli: Web Services: il
punto sulla standardizzazione (I) - MokaByte 96, Maggio
2005
[MOKA_WS_2] S. Rossini, R. Spazzoli: Web Services: il
punto sulla standardizzazione (II) - MokaByte 96, Giugno
2005
[ZAPTHINK_RM] ZapThink's Service-Oriented Architecture
Roadmap:
http://www.zapthink.com/report.html?id=ZTS-GI103
[BEA_RM] A Roadmap for SOA: A Q&A with BEA CIO Rhonda
Hocker:
http://www.bea.com/framework.jsp?CNT=fea00020.htm&FP=/content/news_events/features_news/features
[MW2_BP] Service Oriented Blueprint: www.mw2consulting.com/
[CBDI_RM]http://roadmap.cbdiforum.com/reports/soa/managersintro.php
[OWL] Web Ontology Language: http://www.w3.org/2004/OWL/#specs
|
