Service Oriented Architecture

Parte IV: la Roadmapdi e

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.

Negli scorsi articoli abbiamo parlato di SOA sia dal punto di vista architetturale (vedere [1]) che delle metodologie di analisi e di design (vedere [2]) .

Un‘azienda che decide di evolvere il proprio sistema informativo verso una architettura SOA deve fare diverse scelte e fronteggiare numerose sfide.

In [3] 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.

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], [5]).

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.

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.

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.

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.

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 [10]) 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.

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 [6]).

1M. Piraccini, S. Rossini"SOA: Introduzione" - MokaByte 100 - Ottobre 2005http://www.mokabyte.it/2005/10/soa-1.htm 2M. Piraccini, S. Rossini "SOA: Metodologia" - MokaByte 101 - Novembre 2005http://www.mokabyte.it/2005/11/soa-2.htm3M. Piraccini, S. Rossini"SOA (III): Il Maturity Model" - MokaByte 102 - Dicembre 2005http://www.mokabyte.it/2005/12/soa-3.htm4M. Piraccini, S. Rossini "Web Services: il punto sulla standardizzazione (I)" - MokaByte 96, Maggio 20055M. Piraccini, S. Rossini"Web Services: il punto sulla standardizzazione (II)" MokaByte 96, Giugno 2005 6ZapThink‘s Service-Oriented Architecture Roadmaphttp://www.zapthink.com/report.html?id=ZTS-GI1037A Roadmap for SOA: A Q&A with BEA CIO Rhonda Hockerhttp://www.bea.com/framework.jsp?CNT=fea00020.htm&FP=/content/news_events/features_news/features8Service Oriented Blueprint www.mw2consulting.com/9http://roadmap.cbdiforum.com/reports/soa/managersintro.php10Web Ontology Languagehttp://www.w3.org/2004/OWL/#specs

Condividi

Pubblicato nel numero
103 gennaio 2006
Stefano Rossini è nato a Giussano (MI) il 29/10/1970 e ha conseguito il diploma universitario in Ingegneria Informatica presso il Politecnico di Torino. Ha maturato più di venti anni di esperienza in diversi progetti Enterprise mission-critical ricoprendo i ruoli di IT Program Manager, Project Manager & Software Architect presso importanti…
Marco Piraccini è nato a Cesena il 09/10/1975. E‘ laureato in Ingegneria Informatica presso la facoltà di Bologna con una tesi sull‘assessment della maturità del processo di testing e in Fisica Computazionale presso la facoltà di Udine con una tesi sull‘uso di GRID per le simulazioni Monte Carlo (nell‘ambito di…
Articoli nella stessa serie
Ti potrebbe interessare anche