|
Modalità
di integrazione
Gartner [GARTNER] divide i modi in cui si possono
integrare le applicazioni in tre casistiche fondamentali:
- Data
consistency
- Multistep
Process
- Composite
Application
descriviamole
brevemente.
Data
consistency
L'obiettivo di questa tecnica è quella
di tenere allineati i database di una o più
applicazioni sui fatti rilevanti per l'azienda.
La caratteristica principale di questa tecnica
è che le applicazioni sono logicamente
e fisicamente indipendenti perché le sincronizzazioni
fra due applicazioni avvengono in processi separati
e in maniera indipendente da quello che sta facendo
l'applicazione.
Questo pattern di integrazione (vedi figura 1)
di fatto viene implementato da processi batch.
In genere si parla poco dei batch, ma nei sistemi
informativi enterprise essi sono tuttora un importante
mezzo di integrazione e rappresentano ancora una
parte rilevante delle elaborazioni.
Figura 1 - Data consistency
Multistep
Process
Secondo questo pattern (vedi figura 2) una applicazione
scatena un evento che è propagato attraverso
le applicazioni interessate con uno o più
step. La comunicazione è asincrona e monodirezionale.
In questo caso le applicazioni sono fisicamente
indipendenti, ma non lo sono logicamente in quanto
l'elaborazione dell'evento necessita della logica
di ogni applicazione che vi partecipa. Questo
pattern si ha ogni volta che si costruiscono architetture
asincrone a messaggi.
Figura 2 - Multistep Process
Composite
Application
In questo caso una applicazione comunica in maniera
bidirezionale e tipicamente sincrona con una o
più applicazioni. In questo pattern (vedi
figura 3) il grado di accoppiamento delle applicazioni
è molto elevato, al punto che si può
sostenere che nell'insieme le applicazioni così
integrate vanno a comporre una nuova applicazione.
Questa è la modalità di integrazione
che oggi si incontra più spesso e che ha
permesso a tante aziende di creare applicazioni
di integrazione del loro legacy al fine di esporre
le funzionalità aziendali mediante un nuovo
front-end (tipicamente un'applicazione web).
Figura 3 - Composite Application
SOA
Qualunque sia il pattern di integrazione che dobbiamo
usare rimane il fatto che integrare è una
attività difficile e costosa. Questo induce
a pensare che la difficoltà non dipenda
da come si affronta il problema, ma che la difficoltà
sia intrinseca all'attività di integrazione.
Negli esempi visti sopra abbiamo sempre delle
applicazioni complete su cui vogliamo innestare
una nuova funzionalità che implica una
forma di integrazione. Questo porta ad affrontare
i problemi di integrazione in fase di manutenzione/evoluzione
delle applicazioni. Inoltre normalmente in questi
casi si tende a soluzioni particolari e poco riutilizzabili
nell'eventualità di nuove necessità
di integrazione.
Un miglioramento alla difficoltà del problema
dell'integrazione si avrebbe se le applicazioni
fossero concepite per essere integrate. Quindi
se le problematiche della fase di integrazione
fossero affrontate nella fase di inception dell'applicazione.
Questo non elimina completamente la difficoltà
di integrazione però consente di risolvere
una serie di problemi nella fase di sviluppo dell'applicazione
(quando cioè toccare il codice costa meno).
Se l'applicazione invece esiste già si
può costruire sopra di essa un layer che
la mostri al mondo esterno "come se"
fosse stata concepita per essere integrata.
Questa è una delle idee che stanno alla
base dello stile architetturale SOA (e per me
la più importante). Vedremo che il modo
migliore (per quanto ne sappiamo oggi) per avere
applicazioni integrabili è quello di pensarle
a servizi e cercheremo di capire meglio cosa sono
i servizi.
Ma SOA non è solo questo, SOA è
anche una collezione di idee e best practices
sul tema dell'integrazione maturate in seguito
all'introduzione del modello di computazione distribuita.
Ad esempio una delle best practice più
importante è che disaccoppiare (ove possibile)
porta molti benefici.
La
figura 4 segue mostra un blueprint di un'architettura
SOA. Come si può vedere esistono vari layer.
Partendo dal basso abbiamo il layer delle applicazioni
a servizi e il layer dell'ESB. Questi layer sono
fondamentali per l'architettura SOA e saranno
esaminati più in dettaglio in seguito.
Gli altri layer invece elevano via via il livello
di astrazione permettendo di avvicinare gli aspetti
tecnici di in sistema informativo a chi dirige
il business di una azienda. Infatti il layer del
workflow consente di disegnare e configurare workflow
di processi aziendali (piuttosto che cablare queste
informazioni nelle applicazioni come spesso accade).
Una volta che si hanno a disposizione dei processi
aziendali è possibile gestirli (layer BPM:
Business Process Management) cioè attivarli
e disattivarli, ma anche gestire situazioni di
errore mediante applicazioni di backoffice.
Figura 4 - Blueprint architettura SOA
Infine
il layer BAM (Business Activity Monitoring) consente
di analizzare le dinamiche dei processi di business
al fine di prendere decisione aziendali. Gli strumenti
di questi tre layer possono teoricamente essere
usati da persone non tecniche (con la dovuta assistenza)
e consentono di avvicinare le persone che prendono
di decisioni di business al settore IT facendoglielo
meglio comprendere. In effetti questi tre layer
non sono nuovi e sono presenti anche nei blueprint
di altri modelli architetturali. Poche aziende
li hanno effettivamente realizzati. SOA grazie
alla sua flessibilità dovrebbe consentire
finalmente di costruire questi layer a costi accettabili,
ma staremo a vedere, per il momento ritengo conveniente
concentrasi sui due layer più bassi.
Implementare
una architettura SOA a tappeto su un sistema informativo
già in essere può significare una
rivoluzione tale da rendere difficile la cosa
e magari trovare anche opposizioni legittime da
parte delle persone più scettiche. Come
sempre nell'informatica più che rivoluzioni
bisogna fare evoluzioni. Questo consente di minimizzare
i rischi del cambiamento, salvaguardare gli investimenti
passati e di convincere a poco a poco gli scettici.
SOA non è differente da questo punto di
vista e perché abbia successo va fatta
partire con progetti pilota.
Quindi per la buona riuscita dell'evoluzione verso
SOA da parte del management è necessario
supportare e sostenere un continuo processo di
rinnovo del parco applicativo mediante acquisizioni
di applicazioni a servizi o conversioni delle
applicazioni esistenti.
I
servizi
Un servizio è una funzionalità di
business autoconsistente. Autoconsistente significa
che per usufruire della funzionalità messa
a disposizione dal servizio è sufficiente
chiamarlo senza dovere effettuare altre operazioni.
Come già evidenziato in [PIRACCINI] queste
proprietà si ottengono creando servizi
stateless e di granularità piuttosto grossa.
Mentre dovrebbe essere chiaro a tutti cosa significa
servizio stateless, il discorso sulla granularità
fine/grossa è molto più soggettivo
perché il tema è a cavallo fra il
piano architetturale e quello funzionale.
Ad esempio una applicazione di CRM potrebbe esporre
tre servizi come mostrato in figura 6.
Figura 5 - CRM a servizi
In
questo caso i servizi sono pochi e per dare la
copertura funzionale necessaria all'applicazione
CRM dovranno mettere a disposizione più
di una funzionalità. Ad esempio possiamo
immaginare che il servizio di gestione anagrafica
cliente consentirà di effettuare inserimenti,
modifiche, cancellazioni e ricerche di clienti.
Le applicazioni in SOA diventano quindi un substrato
che riunisce assieme un insieme di servizi che
hanno affinità funzionale.
I
servizi e l'analisi
E'
abbastanza evidente quindi che i servizi devono
essere disegnati assieme agli esperti funzionali
e di dominio. Anche per queste persone il passaggio
ad una architettura SOA ha degli impatti. Infatti
spesso gli analisti funzionali partono ad eseguire
la loro analisi dall'interfaccia grafica (spesso
chiamata mappa) che l'utente si troverà
di fronte. In questa maniera il layer di business
(e quindi in questo caso i servizi) viene modellato
in modo da rispondere perfettamente alle necessità
dell'applicazione di front-end, incernierandosi
con le mappe e le navigazioni sulle mappe previste
dagli analisti. Il grado di riusabilità
di servizi ottenuti in questo modo è piuttosto
basso, anzi in generale si può affermare
che solo l'applicazione di front-end sarà
in grado di utilizzare i servizi (e per essa andranno
benissimo).
Il passo richiesto agli analisti funzionali è
dunque quello di svincolarsi da questo modo procedere
e pensare a servizi riusabili cercando di prevedere
le necessità di integrazione future. Resta
sottinteso ovviamente che se queste necessità
non ci sono, non conviene adottare un'architettura
SOA e probabilmente risulta meno costoso limitarsi
ad una architettura distribuita o addirittura
ad un client/server.
L'analista deve partire non più dalle mappe,
ma cominciare a ragionare sull'interfaccia dei
servizi, è importante dunque che esita
una interfaccia esplicita e dichiarata in un documento.
Una società con cui sono in contatto e
che vuole sviluppare applicazioni a servizi ha
creato due gruppi uno per il layer dei servizi
ed uno per il front-end e ha adottato la regola
che questi gruppi possono comunicare solo mediante
documenti. Questa situazione che per certi versi
può sembrare estrema e che sicuramente
aumenta i costi di sviluppo dell'applicazioni
modella però una situazione realistica:
infatti in futuro sempre più spesso ci
sarà la necessità di integrare applicazioni
di due società diverse che vogliono fare
business assieme. In questo caso abbiamo due sistemi
informativi differenti e anche due gruppi di lavoro
remoti per cui è inevitabile che si instauri
un processo di analisi e sviluppo basato sullo
scambio di documenti.
Una interfaccia chiara e documentata che rappresenti
il contratto del servizio è quindi il deliverable
fondamentale della fase di analisi di un servizio.
I
servizi e il change management
Se stiamo disegnando architetture SOA è
perché vogliamo che i servizi che rendiamo
disponibili siano utilizzati da più utenti
possibili, magari anche esterni al nostro sistema
informativo.
Questo pone dei vincoli (anche contrattuali) su
come e quando il comportamento o l'interfaccia
del servizio può essere cambiato, cioè
pone dei vincoli sul change management. Il motivo
per cui questo accade è che se si hanno
molti utenti di un servizio e si deve rilasciare
una nuova versione dello stesso non è possibile
obbligare tutti gli utenti a fare gli adeguamenti
necessari né è possibile interrompere
la fornitura di servizio a chi non si adegua.
Piuttosto che affrontare il problema di caso in
caso è meglio darsi delle regole generali
che valgano per tutti i servizi realizzando un
processo di change management su cui tutte le
parti concordino. In generale il processo di change
management dovrà consentire:
- La
possibilità del consumer del servizio
di scegliere a quale versione del servizio agganciarsi.
- La
possibilità al provider del servizio
di deprecare e successivamente dismettere vecchie
versioni di un servizio.
Per
raggiungere questi obiettivi è sufficiente
che il sistema supporti più versioni in
linea del medesimo servizio come mostrato in figura
6.
Figura 6 - Versionamento dei servizi
Ci
sono doversi modi per avere due versioni del servizio
in linea, ma fondamentalmente si ricade sempre
in due categorie:
- Pubblicazione
del medesimo servizio con nomi diversi.
- Unico
servizio con un parametro di ingresso che indica
la versione del servizio che si vuole richiamare.
I
servizi possono richiamare altri servizi ad esempio
nel caso si implementino sistemi di workflow.
Al fine di avere un buon sistema di change management
è necessario tracciare le dipendenze fra
servizi in modo da essere in grado di prevedere
gli impatti dovuti al cambiamento di un servizio.
Management
e monitoring del servizio
I servizi nelle architetture SOA dovranno fornire
un servizio (scusate il bisticcio di parole) conforme
a certi standard di qualità (SLA Service
Level Agreement) su cui le parti hanno convenuto.
Possono aversi casi in cui gli SLA sono differenti
per tipo di servizio, oppure per chiamante oppure
cambiano a seconda dell'orario del giorno. In
ogni caso deve essere possibile monitorare il
comportamento dei servizi ed eventualmente avere
strumenti per intervenire e quindi gestire il
servizio.
L'attenzione si sposta dunque sul servizio e non
è più sull'applicazione che fornisce
il servizio, ad esempio una applicazione potrebbe
avere servizi con SLA differenti. Inoltre dovrebbe
essere possibile controllare tutti i servizi (anche
di differenti applicazioni) da un'unica console.
Questo naturalmente è fattibile più
agevolmente se i servizi sono disegnati in partenza
per essere monitorati e gestiti.
Inoltre il servizio (e non l'applicazione nel
suo complesso) deve avere un log e deve essere
"auditabile" (cioè fornire un
insieme di dati sufficienti alle strutture di
audit ad eseguire i propri controlli). Infatti
potrei avere bisogno che due servizi della medesima
applicazione uno di tipo inquiry ed uno di tipo
dispositivo scrivano un log di audit su due supporti
separati.
Infine un servizio potrebbe essere a pagamento,
in tal caso deve essere "accountabile"
cioè deve essere possibile tenere traccia
del chiamante e del numero delle chiamate per
potere calcolare i costi.
Il
disaccoppiamento
Una pratica su cui insiste SOA è il disaccoppiamento.
Il disaccoppiamento fra il fornitore e il consumatore
del servizio è una caratteristica molto
importante in una architettura di integrazione.
Infatti più è alto più l'architettura
è agile e gestibile, e di conseguenza a
basso costo. In teoria se non vi fosse nessun
accoppiamento fra consumatore e fornitore il costo
di gestione del sistema sarebbe dato dalla somma
del costo di gestione delle due applicazioni.
Nella realtà i costi invece sono sempre
maggiori perché appunto si aggiunge il
costo di integrazione.
Di seguito si prendono in esame tre tipi di accoppiamento
che SOA tenta di alleviare. E' probabile che se
ne possano trovare altri tipi che qui non sono
analizzati.
Accoppiamento
applicativo
Questo tipo di accoppiamento si ha ogni volta
che due applicazioni condividono qualche artefatto.
Ad esempio se due applicazioni condividono un
IDL dal quale generano gli stub e gli skeleton
necessari all'erogazione del servizio esse sono
accoppiate applicativamente e ogni volta che l'IDL
cambia bisogna effettuare il deploy sia del fornitore
che del consumatore del servizio.
Un altro esempio di accoppiamento applicativo
si ha quando fornitore e consumatore si scambiano
qualche oggetto durante la fase di comunicazione.
E' evidente che gli oggetti scambiati che saranno
i parametri e il risultato dell'elaborazione devono
essere noti ad entrambe le controparti e di conseguenza
se gli oggetti cambiano è necessario effettuare
il deploy delle due applicazioni.
Questa tipo di accoppiamento è piuttosto
diffuso oggi e anzi si può dire che è
incoraggiato dagli strumenti di sviluppo odierni
quali CORBA e J2EE che spingono ad usare IDL e
pattern quali value object come modello di sviluppo
dei servizi. La mia opinione è che gli
strumenti sopra citati consentano agevolmente
di rendere remote funzionalità presenti
in componenti/oggetti software. Queste componenti
sono però tutt'altro che servizi nel senso
di SOA.
Comunque anche nel caso delle componenti il problema
di gestire gli aggiornamenti rimane. Mi è
capitato in un paio di esperienze di vedere il
problema aggirato applicando il pattern command
[J2EEPATTERN]. Mediante questo pattern si può
fare sì che l'interfaccia della componente
remota sia unica e fissa e che un value object
che rappresenta la richiesta attuale (comando)
sia scambiato avanti e indietro fra le due parti.
In questo modo è possibile far svolgere
più compiti allo stesso componente remoto,
basta definire nuovi comandi. Inoltre introducendo
nuovi comando o evolvendo quelli esistenti non
si modifica l'interfaccia remota del componente
quindi non è mai necessario ricompilare
stub e skeleton; può dunque sembrare che
questa sia la soluzione del problema dell'accoppiamento
applicativo.
In realtà non è vero, infatti col
pattern command da un lato l'interfaccia remota
del servizio è troppo generica per rappresentare
un contratto fra le due parti, dall'altro però
il contratto è implicitamente e subdolamente
definito dall'oggetto comando che quindi deve
essere noto ad entrambe le controparti. Questo
approccio scricchiola non appena i consumatori
del servizio sono più d'uno e magari sono
esterni al sistema informativo del fornitore del
servizio. In questo scenario (che è lo
scenario in cui nasce SOA) c'è bisogno
di una maggiore formalizzazione del contratto
e inoltre come abbiamo già detto di una
oculata gestione degli aggiornamenti.
Per limitare l'accoppiamento applicativo SOA propone
che le applicazioni mantengano invariata la propria
rappresentazione dei dati senza quindi avere oggetti
in comune. Per fare ciò una possibilità
è, come mostrato in figura 7, che le applicazioni
serializzino i dati in un messaggio in un formato
che sia trasformabile facilmente da un ente intermedio.
Figura 7 - Accoppiamento applicativo
Nell'esempio
mostrato in figura l'applicazione mutui effettua
una richiesta che contiene l'oggetto cliente all'applicazione
CRM. La richiesta però viene serializzata
in un messaggio in un formato che sia facilmente
trasformabile. La trasformazione avrà il
compito di rendere la richiesta interpretabile
dall'applicazione CRM. In questo modo l'applicazione
mutui e CRM non condividono nulla di applicativo.
XML e XSLT sono naturalmente oggi i candidati
ideali per effettuare queste operazioni, ma l'idea
del disaccoppiamento applicativo rimane al di
là della scelta di queste tecnologie. Soluzioni
più evolute possono prevedere la presenza
di un dizionario dati che dinamicamente configuri
la trasformazione da effettuare.
Accoppiamento
tecnologico
L'accoppiamento tecnologico si ha quando due applicazioni
devono condividere qualche aspetto tecnologico
per funzionare correttamente. Per esempio se due
applicazioni devono essere sviluppate con J2EE
o devono avere il runtime CORBA dello stesso vendor
allora sono accoppiate tecnologicamente.
Nello sviluppo di un sistema informativo SOA non
devono esservi vincoli che generino accoppiamenti
tecnologici. Quindi in teoria SOA ammette la coesistenza
di qualunque tecnologia.
In generale è bene limitare all'interno
di un sistema informativo le tecnologie usate
(per i vari aspetti ad esempio: DBMS, S.O., protocolli
di comunicazione) assestandosi su due o tre tipi.
Un numero maggiore provoca costi di amministrazione
e formazione troppo elevati.
Ma anche l'omogeneità tecnologica totale
può avere degli svantaggi: per prima cosa
ottenerla su un sistema già avviato può
essere molto costoso; inoltre la possibilità
di ospitare più di una tecnologia in un
sistema informativo, in caso di acquisto di nuove
applicazioni consente di esaminare più
candidati e quindi potere scegliere sempre il
prodotto migliore. Infine avere più di
una tecnologia consente di mettere in competizione
i fornitori di questa tecnologia e quindi in generale
di abbassare i prezzi delle licenze (bisogna essere
bravi per riuscirci, ma si può fare).
Accoppiamento
temporale
Due applicazioni sono accoppiate temporalmente
se è necessario che siano entrambe online
affinché una delle due possa funzionare
correttamente. Può sembrare impossibile
che se due applicazioni sono integrate una delle
due possa funzionare correttamente se l'altra
non è online. Invece è possibile
realizzare quatta situazione adottando protocolli
di comunicazione asincrona e monodirezionale.
Se teniamo a mente i pattern di integrazione già
citati solo nel caso delle composite application
non riusciamo a disaccoppiare temporalmente le
applicazioni, negli altri casi è possibile.
Si noti che se il pattern di comunicazione è
sincrono (cioè di tipo richiesta risposta)
non importa quale protocollo di comunicazione
usiamo, il risultato sarà sempre che le
applicazioni sono accoppiate temporalmente. Anche
se, come mostrato in figura 8, usiamo protocolli
asincroni per esempio una coda di messaggi per
la richiesta e una coda di messaggi (con correlazione)
per la risposta, le applicazioni rimangono sempre
temporalmente accoppiate.
Figura
8 - Accoppiamento temporale
Layer
dell'architettura SOA
Come nelle architetture distribuite è possibile
distinguere facilmente alcuni layer (tipicamente
dati, business, presentation) la stessa cosa si
può fare per le architetture SOA.
Figura 9 - Layer architettura SOA
I
layer che si possono individuare sono mostrati
in figura 9 e sono i seguenti:
- Layer
delle applicazioni SOA
- Layer
tecnologico e di normalizzazione
- Layer
di composizione dei processi
- User
end point layer
I
nomi dei layer SOA sono liberamente tratti da
[ENTERPRISESOA] e non sono standard (per la verità
non è ancora stato sviluppato un lessico
ufficiale per indicare i layer SOA).
Layer
delle applicazioni SOA
In questo layer ci sono le applicazioni che espongono
i servizi con le caratteristiche di cui si è
parlato precedentemente.
Come già detto le applicazioni possono
esporre servizi sia perché sono state concepite
a servizi sia perché sono state wrappate
con qualcosa che le mostra "come se"
fossero state concepite a servizi.
Come si può vedere dalla figura le applicazioni
a servizi non hanno legami esterni se non mediante
servizi. Questo dovrebbe semplificare le operazioni
di sostituzione dell'applicazione dovute a nuovo
sviluppo o a un nuovo acquisto. Infatti in questa
architettura sostituire un'applicazione significa
trovare una applicazione che possa esporre gli
stessi servizi della precedente (e migrare i dati).
Da un punto di vista transazionale tutte le unità
di lavoro devono chiudersi a questo livello; questo
consente di evitare o quantomeno limitare al massimo
l'uso di transazioni distribuite.
Layer
tecnologico e di normalizzazione dati
Come si vede dalla figura le applicazioni espongono
servizi di forme diverse. Questo sta ad indicare
sia le diversità nella modellazione dati
sia le diversità tecnologiche e di protocollo
di comunicazione. Si consente di avere queste
diversità perché come spigato nell'architettura
SOA non si vogliono accoppiamenti applicativi
e tecnologici.
Il layer tecnologico e di normalizzazione dati
si occupa di esporre ai layer successivi una sola
tecnologia e di effettuare le dovuta normalizzazioni
sui dati.
Il protocollo scelto per i layer successivi deve
avere il più alto grado di accettazione
e di interoperabilità possibile; il pensiero
va dunque (ad oggi) ai Web Services, infatti rispetto
a CORBA ed altri sistemi di elaborazione distribuita
i Web Services sembrano avere l'appoggio dei maggiori
vendor e quindi come protocollo sembra il migliore
candidato su cui investire.
Questo layer era stato previsto nel mondo java
dalla specifica JBI (Java Business Integration)
[JSR-208] già nel marzo 2003. Al tempo
SOA non era ancora di moda per cui nella specifica
non si fa uso esplicito di tutto il lessico SOA.
Purtroppo come spesso accade nel JCP (Java Community
Process) le cose procedono a rilento e ad oggi
la specifica è in public review, ma non
è stata pubblicata. I vendor di conseguenza
non la implementano e stanno prendendo strade
proprietarie come gli ESB (Enterprise Service
BUS) di cui parleremo fra poco.
Questo layer di solito si implementa con strumenti
di comunicazione asincrona tipicamente code di
messaggi (anche quando il pattern di comunicazione
è quello delle composite application).
Il motivo è come già detto che in
SOA predilige la comunicazione asincrona perché
aumenta il disaccoppiamento ed in generale consente
di creare architetture più scalabili.
Layer
di composizione di processi
Una volta ottenuta l'omogeneità tecnologica
e di rappresentazione dei dati è possibile
comporre i servizi in processi di business.
Questa composizione si può realizzare con
servizi ad hoc oppure mediante un motore di workflow.
Va notato comunque che questo è un layer
opzionale di SOA e va implementato solo se strettamente
necessario.
Come linguaggio standard per la definizione di
workflow sembra si stia imponendo è BPEL
[BPEL]. Questo linguaggio consente di definire
processi di business secondo molti dei pattern
con cui un workflow può presentarsi. Per
una trattazione completa dei pattern si veda [WORKFLOWPATTERN].
Il vantaggio di avere definito un workflow mediante
un linguaggio standard è che in teoria
il cambiamento del motore di workflow non dovrebbe
avere ripercussioni sul workflow già sviluppato.
A livello di prodotti non c'è ancora uniformità
di accettazione di uno standard per cui alcuni
prodotti accettano BPEL, altri accettano standard
che hanno meno popolarità di BPEL, altri
ancora hanno un linguaggio proprietario. A mio
avviso non essendo ancora chiaro quale standard
per la definizione del workflow si imporrà,
oggi, dovendo scegliere un motore di workflow
conviene scegliere in base alle caratteristiche
del prodotto e non in base al linguaggio supportato.
Quando emergerà uno standard universalmente
accettato se il prodotto è un buon prodotto
saranno apportati dei miglioramenti per supportare
lo standard e saranno messi a disposizione tools
di migrazione per i workflow già definiti,
altrimenti tanto varrà affrontare i costi
di migrazione di prodotto.
Da un punto di vista transazionale, poiché
come abbiamo visto le unità di lavoro si
chiudono sul layer delle applicazioni a servizi,
la composizione dei servizi non sarà transazionale
e quindi si dovranno prevedere servizi di compensazione.
BPEL per la verità consente sia questo
tipo di aggregazione sia aggregazioni transazionali.
User
end-point layer
In questo layer si situano tutti gli utilizzatori
dei servizi.
I particolare quindi le applicazioni di front-end
e le applicazioni esterne al sistema informativo
che hanno bisogno di accedere ai servizi.
Può valere la pena sottolineare che le
applicazioni di front-end non perdono la loro
importanza nelle architetture SOA. Infatti queste
sono le applicazioni che vede l'utente ed in fondo
è proprio l'utente a determinare il successo
o meno di un progetto software. Quindi nulla vieta
che le applicazioni di front-end siano complesse
magari a più livelli e con dati appoggiati
su database. Ciò che consiglia l'architettura
SOA è che la logica di business sia realizzata
mediante chiamate ai servizi. Tutto il resto della
logica, quindi logica di sessione, di navigazione,
di sicurezza, di caching, di logging ecc…,
può e deve essere realizzata nell'applicazione
di front-end, in modo che questa sia la più
efficiente possibile.
Come
già detto l'implementazione di una architettura
SOA deve essere un processo evolutivo. Quindi
ad esempio sarà possibile in alcune fasi
dell'evoluzione che le applicazioni a servizi
abbiano anche un front-end tradizionale (cioè
non a servizi) per esempio per le funzioni di
amministrazione, configurazione o backoffice.
ESB
Il layer 2 dell'architettura SOA che abbiamo chiamato
tecnologico e di normalizzazione dati ha forti
caratteristiche infrastrutturali (che come abbiamo
visto la specifica JBI cercava di catturare).
Stando così le cose è naturale pensare
di realizzare questo layer con un framework sviluppato
internamente o con un prodotto acquisito sul mercato.
Dunque piuttosto che tanti gateway come in figura
8, possiamo pensare questo layer come mostrato
nella figura 10.
Figura 10 -ESB
Il
nome che si tende a dare a questo layer software
è ESB (Enterprise Service BUS).
Il ruolo infrastrutturale dell'ESB comprende i
seguenti compiti base:
- Supporto
alla comunicazione asincrona basata su messaggi.
Questa caratteristica consente di abbassare
l'accoppiamento temporale ed è da applicare
ogni volta che sia possibile.
- Supporto
alla trasformazione dei dati. Questa caratteristica
consente di abbassare l'accoppiamento applicativo.
- Supporto
a diversi protocolli di comunicazione e compatibilità
con vari connettori software. Questa caratteristica
consente di abbassare l'accoppiamento tecnologico.
- Routing
intelligente dei dati. Questa caratteristica
consente di esporre tutti i servizi sul layer
tecnologico, sarà poi l'ESB a ruotare
il messaggio sulla corretto servizio nel layer
delle applicazioni a servizi.
Alcune
caratteristiche avanzate che un ESB può
ospitare sono:
- Gestione
della sicurezza dei servizi
- Monitoring
e management dei servizi
- Supporto
alla composizione dei processi (in questo caso
l'ESB sconfinerebbe nel layer 3 di SOA)
Come
abbiamo visto ci sono diverse pattern di integrazione
fra applicazioni ognuno dei quali richiede caratteristiche
e SLA differenti al canale di comunicazione. Mi
aspetto dunque che un unico tipo ESB non possa
rispondere a tutti i casi di integrazione presenti
in una azienda. E' possibile prevedere che esisteranno
tre tipi di ESB:
- ESB
batch (per il pattern data consistency)
- ESB
asincrono (per il pattern multistep process)
- ESB
sincrono (per il pattern composite application)
Questi
tre ESB saranno diversi, ad esempio l'ESB batch
favorirà messaggi di grandi dimensioni,
mentre il bus sincrono avrà priorità
maggiore su quello asincrono, ma avranno anche
caratteristiche che si potranno portare a fattore
comune come ad esempio la gestione della sicurezza
e la trasformazione dei dati.
Il
mercato degli ESB pur essendo piccolo in termini
finanziari è molto dinamico per la presenza
di svariati player. Da un lato società
che proponevano broker di integrazione tradizionali
(come webMethods [WEBMETHODS] o IBM [IBM]) hanno
fatto rebranding dei loro prodotti convertendoli
alle nuove tecnologie (java e Web Services). Dall'altro
spesso società di dimensioni più
limitate (come Sonic [SONIC] o Fiorano [FIORANO]
) che proponevano sistemi di comunicazioni a messaggi
hanno migliorato il loro prodotto aggiungendo
le features necessarie ad un ESB. In totale ci
sono diverse decine di vendor nessuno dei quali
possiede la leadership del mercato. E' prevedibile
che nel giro di un paio d'anni il mercato si consolidi
facendo emergere chiaramente quattro o cinque
vendor. E' importante notare che nell'arena ci
anche vendor che tipicamente vendono software
applicativo e non di integrazione (come SAP).
Il motivo di questo fatto è che il controllo
del software di integrazione è strategico
in quanto consente di influenzare molto le scelte
evolutive del sistema informativo.
Il
panorama degli ESB open source (almeno per quanto
ne so io) è piuttosto deludente. Infatti
sono a conoscenza di solo due progetti: Joram
[JORAM] e Mule [MULE].
Il primo è un sistema di messaging piuttosto
evoluto, ma secondo me non può ancora dirsi
un ESB. Il secondo è un ESB forse ancora
un po' carente di funzionalità, ad esempio
non ha un sistema di trasformazione dei messaggi.
Comunque mi aspetto che presto nasceranno diversi
ESB open source anche perché a ben vedere
le tecnologie di base di un ESB sono già
disponibili (anche open source) e consolidate;
bisogna quindi assemblarle coerentemente in un
prodotto (anche se non è facile come può
sembrare).
Come
abbiamo detto i vendor cercheranno di piazzare
il proprio ESB all'interno del sistema informativo
aziendale è quindi possibile immaginare
che presto in un sistema informativo ci sarà
più di una marca di ESB come mostrato in
figura 11.
Figura 11: Arcipelaghi di ESB
Gartner
[GARTNER] chiama questa situazione Arcipelagi
di ESB intendendo per arcipelago un gruppo di
applicazioni a servizi correlate e coordinate
da un ESB.
Gli arcipelagi però non sono isolati e
come si vede in figura dovranno comunicare. In
qualche modo dunque gli ESB si dovranno parlare
o in altre parole ESB di vendor e tecnologie differenti
dovranno essere interoperabili. Qualcuno mi ha
fatto notare che la figura degli arcipelagi di
ESB assomiglia a figure già viste sull'interoperabilità
degli ORB di CORBA. In quella situazione l'interoperabilità
era piuttosto bassa, nel caso degli ESB i Web
Services dovrebbero dare qualche garanzia in più.
Ad oggi in realtà gli ESB non sono molto
interoperabili, questo è dovuto al fatto
che le specifiche dei Web Services sono in continua
evoluzione. L'evoluzione è così
rapida e tumultuosa che gli ESB talvolta non garantiscono
neppure la compatibilità con la versione
precedente del medesimo prodotto.
Quando l'evoluzione degli standard dei Web Services
si stabilizzerà ci si potrà attendere
qualche cosa di più sul piano dell'interoperabilità
degli ESB.
Conclusioni
Un'azienda che decida di evolvere il proprio sistema
informativo verso una architettura SOA deve fare
diverse scelte e fronteggiare diverse sfide.
La più importante è certamente quella
di evolvere le applicazioni esistenti verso una
logica a servizi.
In secondo luogo dovrà dotarsi della infrastruttura
organizzativa e tecnologica per gestire i servizi.
Inoltre dovrà effettuare delle software
selection per scegliere un adeguato software di
integrazione sapendo già in partenza in
questo momento questa categoria di prodotti non
è ancora matura e stabile.
A mio avviso le architettura SOA danno benefici
nelle condizioni ove vi sia una reale necessità
di condividere servizi. In tal caso conviene implementare
una architettura SOA magari partendo da qualche
piccolo, ma significativo use case.
In ogni caso non credo che SOA sia il "Silver
bullet" [MMM] (cioè la tecnologia
in grado di risolvere completamente) del problema
dell'integrazione delle applicazioni, sono certo
però che l'approccio di SOA possa portare
notevoli semplificazioni. Per capire quanto notevoli
bisognerà attendere ancora un po'.
Bibliografia
[GARTNER] http://www.gartner.com
[J2EEPATTERN] http://www.theserverside.com/books/wiley/EJBDesignPatterns/downloads/ejbdesignpatterns.pdf
[JSR-208] http://www.jcp.org/en/jsr/detail?id=208
[BPEL] ftp://www6.software.ibm.com/software/developer/library/ws-bpel.pdf
ftp://www6.software.ibm.com/software/developer/library/ws-bpelj.pdf
[WORKFLOWPATTERN] http://tmitwww.tm.tue.nl/research/patterns/
[MULE] http://docs.codehaus.org/display/MULE/Home
[JORAM] http://joram.objectweb.org/
[WEBMETHODS] http://www.webmethods.com/meta/default/folder/0000006281
[IBM] http://www-306.ibm.com/software/info1/websphere/index.jsp?tab=landings/esb
[SONIC] http://www.sonicsoftware.com/products/sonic_esb/index.ssp
[FIORANO] http://www.fiorano.com/products/fesb/fioranoesb.htm
[MMM] "The Mythical Man-Month: Essays on
Software Engineering, 20th Anniversary Edition"
di Frederick P. Brooks
[ENTERPRISESOA] "Enterprise SOA Service Oriented
Architecture Best Practices" di Dirk Krazfig,
Karl Banke e Dirk Slama. Edito da Prentice Hall.
[PIRACCINI] http://www.mokabyte.it/2004/09/soa.htm
|
