SOA:
Architettura a servizi
Una
architettura SOA è una architettura software
che definisce una modalità di descrivere i componenti
(servizi) con caratteristiche ben specifiche orientate
al riutilizzo e all'integrazione. SOA è uno stile
architetturale basato sul concetto di servizio, che
rappresenta quindi l'elemento strutturale su cui le
applicazioni vengono sviluppate. Occorre quindi definire
cosa si intende per servizio.
Cos'è un servizio ? Un
servizio è, in prima analisi, una funzionalità
di business realizzata tramite un componente che rispetta
un'interfaccia.
SOA
è costituito da principi, linee guida, best practices
architetturali indipendenti da qualsiasi tecnologia
e definisce una serie di proprietà che i servizi
devono soddisfare per essere realmente riusabili e facilmente
integrabili in ambiente eterogeneo:
- I
Servizi devono essere ricercabili e recuperabili dinamicamente
- Servizi
devono essere autocontenuti e modulari
- I
Servizi devono definire delle interfacce esplicite
e indipendenti dall'implementazione
- I
Servizi devono essere debolmente accoppiati (loosely
coupled). In questo caso il disaccoppiamento si intende
sia tecnologico che funzionale
- I
Servizi devono avere un'interfaccia distribuita e
devono essere accessibili in maniera trasparente rispetto
all'allocazione
- I
Servizi devono avere preferibilmente un'interfaccia
a "grana grossa" (coarse-grained)
- I
Servizi devono essere componibili, ovvero orchestrabili
in processi di business ampi che rompano le tradizionali
pile applicative verticali (silos)
Un
servizio deve quindi definire un'interfaccia pubblicabile
sulla rete, ricercabile e invocabile in maniera indipendente
dal linguaggio e dalla piattaforma. Per ottenere questi
requisiti, le applicazioni SOA definiscono dei ruoli
(in realtà non tutti obbligatori):
- Service
Consumer: l'entità che richiede il servizio;
può essere un modulo di un'applicazione o un
altro servizio.
- Service
Provider: l'entità che fornisce il servizio
e che ne espone l'interfaccia.
- Service
Contract: definisce il formato per la richiesta di
un servizio e della relativa risposta.
- Service
Registry: Direttorio in rete dei servizi consultabili.
Poichè
i servizi devono essere ricercabili e recuperabili dinamicamente,
il Service Contract deve essere pubblicato su un Service
Registry dal Service Provider. Il Service Consumer deve
richiedere al Service Registry il Contract relativo
al servizio richiesto, che utilizzerà per eseguire
il servizio tramite un protocollo di trasporto. Rispettando
questi concetti, è possibile pensare alla definizione
di un'applicazione come aggregazione di servizi.
Figura 1: i ruoli SOA
Spostandosi
su un punto di vista più ampio è chiaro
che l'adozione di un'architettura SOA investe tutti
gli aspetti associati alla definizione di un Information
System (metodologici, di processo, organizzativi ed
anche tecnologici). L'obiettivo centrale è comunque
quello di guidare la definizione di un'Architettura
Enterprise ispirata e modellata in funzione dei driver
di Business. Possiamo
quindi aggiungere che i servizi devono essere business-driven,
quindi dovranno essere definiti definiti assieme agli
esperti funzionali e di dominio. I requisiti già
espressi di essere autocontenuti, stateless e coarse-grained
orientano comunque il disegno in questa direzione e
definire il servizio come componente che abbia realmente
un significato per gli esperti funzionali (cioè
non sia un componente architetturale fine a se stesso)
è importantissimo ai fini del riuso del servizio
stesso. Il concetto di servizi e di composizione degli
stessi è un concetto che può essere quindi
compreso in maniera "semplice" anche da chi
tradizionalmente è al di fuori delle problematiche
architetturali. I
servizi devono essere essenzialmente modellati in funzione
del valore aggiunto che essi portano al core Business
dell'azienda: non tutto deve essere necessariamente
modellato in stile SOA.
D'altra parte le problematiche trasversali (es. Sicurezza,
Manageability) dovrebbero essere viste dall'infrastruttura
applicativa come servizi. E'
bene notare come, a differenza di CORBA e J2EE, SOA
non specifichi un'architettura in senso stretto, ma
si ponga obiettivi molto più ampi:
- definire
pratiche e Roadmap di adozione che guidino l'evoluzione
tecnologica ed organizzativa dei Sistemi Enterprise
- specificare
un insieme di regole per il disegno dei servizi con
la definizione delle relative interfacce e delle modalità
di interazione tra essi (sia per i nuovi servizi,
sia per l'evoluzione delle piattaforme applicative
esistenti)
- definire
pratiche per guidare gli impatti organizzativi e culturali
indotti
- migliorare
il livello di condivisione/comunicazione/coordinamento
tra i ruoli che tradizionalmente si occupano di Business
e gli Architect (es. attraverso la centralità
del concetto di "Processo" di Business)
- contribuire
al soddisfacimento delle strategie IT di Business
SOA
di fatto non propone concetti architetturali nuovi,
quanto una visione integrata ed ampliata di principi
architetturali già adottati nel passato (es:
CORBA e J2EE) e di problematiche affrontate in altri
ambiti (es. EAI e BPM). SOA indirizza quindi in maniera
corretta (anche se non rivoluzionaria) il design in
termini di riutilizzo e di integrazione, di fatto producendo
servizi con un maggiore valore aggiunto. Riassumendo,
quali sono quindi i vantaggio reale di architetture
SOA?
-
Indirizza in maniera corretta il design di servizi
in termini di riutilizzo e di integrazione
- Non
è legato a nessuna tecnologia in particolare
E'
importante infatti notare che a livello implementativo
la tecnologia utilizzata per lo sviluppo dei servizi
SOA non è determinante finché vengono
rispettate queste caratteristiche. Questo
sicuramente è un passo avanti rispetto, ad esempio,
a J2EE... non si è nemmeno obbligato ad utilizzare
java.
I
layer di SOA
Come
si presenta un sistema SOA? A layer, come indicato nella
figura successiva
Figura 2: i layer SOA
- Bottom
layer: contiene i sistemi operazionali (applicazioni
e sistemi esistenti: ERP, CRM, Applicazioni legacy.
- Component
layer: basato su tecnologie a container e componenti
- Service
Layer: fornisce io servizi basandosi sui componenti
e attori degli strati sottostanti. Agli strati superiori
vengono forniti i servizi.
- Business
Process Choreography: E' lo strato che compone
i servizi per implementare gli use case ed i processi
di business.
- Presentation:
E' lo strato che permette l'esposizione dei processi
ottenuti dallo strato precedente tramite componenti
di presentazione.
- Integration
Architecture: è l'Infrastruttura che permette
l'accesso e la composizione dei servizi fornendo meccanismi
di integrazione. Gli
ESB (Enterprise Service Bus) sono definiti a questo
livello, che deve quindi gestire per ogni servizio
i ruoli definiti (service consumer, provider, contract,
registry).
- QoS,
Security, Management, Monitoring: tools di controllo
e gestione dell'infrastruttura.
Costruire
un'applicazione SOA significa quindi identificare, disegnare,
orchestrare servizi all'interno dei layers definiti
in maniera il più possibile indipendente dalla
tecnologia utilizzata.
Metodologie
Che
impatto ha SOA sul processo di sviluppo delle applicazioni
complesse nella sua completezza? Per rispondere a questa
domanda occorre affrontare anche il problema delle metodologie
di analisi e design. Introduciamo alcune pratiche emergenti.
Metodologie
di analisi e design: SOAD
SOA
si pone come obiettivo lo sviluppo di applicazioni sulla
base di servizi, disegnati seguendo regole che ne garantiscono
riuso e ne facilitano l'integrazione. Per fare questo
stanno emergendo nuove metodologie di analisi e design
che, partendo dai concetti "classici" di OOAD
e dai concetti di architetture a servizi definiscono
pratiche orientate all'analisi e al design a cui si
riferisce spesso con il termine "Service Oriented
Analysis and Design" (SOAD).
Metodologie
di integrazione: SOI e SOMA
Uno
degli aspetti veramenti interessanti di SOA è
l'integrazione di applicazioni legacy (o comunque già
sviluppate) in sistemi a servizi. Questo permette infatti
di non dovere riscrivere codice che funzionante e che
si vuole conservare. Inoltre, ponendosi come obiettivo
la "rottura" dei Silos applicativi verticali,
implicitamente SOA si occupa di integrazione. Si parla
in questo caso di SOI (Service Oriented Integration),
ovvero l'applicazione dei principi Service Oriented
alle problematiche d'integrazione Inoltre
è essenziale definire una metodologia di trasformazione
di funzionalità "vecchie" in servizi
nel senso definito da SOA. SOMA è un interessante
approccio a questo tipo di problema, e può essere
utile per indirizzare una Roadmap per la trasformazione/integrazione
di applicazioni preesistenti in architetture SOA.
Roadmap
e maturity model
Abbiamo
parlato di SOA sia dal punto di vista architetturale
che delle metodologie di analisi e di design...ma questo
non basta! Infatti è fondamentale occuparsi del
problema anche dal punto di vista "culturale".
Occorre arrivare a definire una serie di passi per arrivare
a sviluppare e integrare applicazioni secondo i layer
che sono stati definiti, cioè una roadmap che
ci "traghetti" verso il nostro obiettivo.
Diventa quindi 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 determinato il grado di maturità rispetto
al modello, verrà naturale capire quali passi
effettuare per raggiungere il livello superiore.
Diventa quindi importante definire un modello di maturità
delle architetture rispetto a SOA e, parallelamente,
capire quali passi effettuare per evolversi all'interno
di questo modello.
SOA
& il Service Bus
Come
si è visto, i servizi devono essere in grado
di comunicare tra di loro attraverso un canale di comunicazione:
il SOA Service bus.
Da un punto di vista architetturale il SOA bus è
un layer che deve mettere a disposizione uno strato
di comunicazione tra i servizi.
Scopo dell'Enterprise Service Bus (ESB) è fornire
un'infrastruttura che centralizzi funzionalità
quali supporto alla comunicazione sincrona ed asincrona
basata su messaggi, intelligent routing, supporto alla
trasformazione dei dati, supporto alla connettività
verso EIS eterogenei, ...
Di fatto, oggi, sono percorribili due strade: sviluppandolo
sfruttando le tecnologie esistenti o rivolgersi al mercato
acquistando un prodotto ESB.
Conclusioni
Partiti!
In questo articolo abbiamo introdotto i concetti salienti
di SOA dando una panoramica globale ed introducendo
brevemente gli argomenti su cui entreremo poi più
in dettaglio.
Nel prossimo numero approfondiremo le implicazioni metodologiche
legate all'adozione di una architettura SOA.
Bibliografia
[MOKA_SOA_INTRO]
M. Piraccini: Service Oriented Architecture-Introduzione
- MokaByte 88 - 7mbre 2004
[MOKA_SOA_VIEW] R.Spazzoli: Uno sguardo su SOA - MokaByte
95 - Aprile 2005
|