La virtualizzazione dei servizi è il prossimo passo nel miglioramento delle Soa e nell’integrazione delle applicazioni attraverso le reti
Secondo Gartner, entro il 2009 oltre il 25% delle applicazioni utilizzerà
componenti correlati alle architetture di servizio e oltre il 50% dei servizi
Web sviluppati opererà all’interno di una rete virtuale. L’implementazione
di una Soa include la gestione delle interazioni tra i diversi servizi che saranno
utilizzati. Un servizio è un componente software con un’interfaccia
stabile e pubblicata all’interno di un elenco (registro) che può
essere invocata da uno o più clienti (ovvero componenti software). La
richiesta e l’esecuzione dei servizi potranno anche essere condotte da
soggetti appartenenti ad aziende diverse. Tutte queste attività sono
supportate da alcuni prodotti e framework di gestione, anche se la creazione
di servizi più complessi richiede, in genere, un sovraccarico di lavoro
per gli sviluppatori, che dovranno stabilire per tempo le modalità con
le quali i servizi interagiscono tra loro e quali saranno i processi impattati.
L’utilizzo di un Enterprise service bus (Esb), in questi contesti, dovrebbe
ridurre la complessità dei processi anche se, molto spesso, non riesce
a garantire la gestione dell’affidabilità a livello di singolo
servizio (il cosiddetto service endpoint). Con la progressiva evoluzione delle
architetture software, però, la necessità di un livello di astrazione
intermedio, che separi l’invocazione dei servizi dalla richiesta degli
stessi, si palesa. Ecco perché le aziende iniziano a valutare l’idea
di virtualizzare l’accesso ai servizi, per svincolarsi dalla dipendenza
rispetto a specifiche topologie architetturali.
Il principio che sta alla base delle Soa, infatti, è quello di impiegare
architetture basate su standard, loosely coupled (ovvero nelle quali le interrelazioni
tra i diversi elementi chiave sono non univoche, quindi replicabili o modificabili).
Questo significa, in sostanza, riuscire a separare, relativamente a ciascuna
applicazione, i processi di business dalle regole di presentazione e accesso
ai dati, in modo che tutti questi elementi possano essere facilmente prelevati
e riutilizzabili, adattandoli a contesti differenti.
I limiti delle architetture attuali
Le Soa, infatti, permettono di combinare le funzionalità già sperimentate
sul software aziendale all’interno di nuove applicazioni “composite”,
il tutto con un minimo sforzo di sviluppo. Le Service area network, rese possibili
dall’integrazione (all’interno dell’azienda) degli Esb potranno
essere utilizzate per ridurre la complessità nell’interazione tra
i diversi servizi Web. Le applicazioni che compongono un’architettura
Soa, infatti, sono componenti software modulari, con interfacce chiaramente
definite, così che ciascun componente possa essere creato, testato e
modificato senza dover riscrivere codice di sviluppo aggiuntivo. Nello sviluppo
di queste applicazioni “composite”, la maggior parte del lavoro
richiesto ai creatori è speso nel garantire che ciascun “mattone”
software realizzato sia interoperabile con gli altri, soprattutto in merito
a quelle che sono due esigenze chiave delle Soa di oggi. Anzitutto, l’indipendenza
dalla specifica allocazione di ciascun servizio, che fa sì che esso possa
essere invocato ovunque si trovi. In seconda battuta, la mobilità del
servizio, ovvero la possibilità di riuscire a “movimentarlo”
senza interrompere le connessioni sussistenti tra il consumatore e il fornitore.
Queste considerazioni risultano particolarmente valide soprattutto nel caso
delle aziende moderne, per le quali occorre avere sotto mano una vista logica
di come i servizi siano in grado di attivare o supportare (impattare) i processi
di business, così come di definire quelli che sono le regole principali
in merito alla sicurezza degli accessi alle applicazioni, alla loro orchestrazione
e garanzia di qualità. Oggi, le architetture Soa impongono ancora parecchi
limiti in merito alla flessibilità di riutilizzo dei servizi Web, soprattutto
in virtù del fatto, in linea di principio, che ogni servizio potrà
essere utilizzato, in un particolare momento, da un solo requestor (si veda
box). Questo problema, però, dovrebbe essere superato, in futuro, con
la generalizzata adozione, presso le aziende che sperimentano le Soa, di una
Service area network, ovvero di una rete virtuale di servizi all’interno
della quale trattare, in un ambiente unico, le richieste o invocazioni, che
saranno processate e reindirizzate al fornitore più appropriato in quel
preciso istante, proprio come avviene all’interno di una Storage area
network.
Istanze parallele
La virtualizzazione dei servizi è un processo che prevede la creazione
di uno strato che separa le richieste di specifiche funzioni di servizio dalla
loro invocazione. Questo consente agli sviluppatori di scrivere richieste di
servizi per un insieme di funzioni di business, senza doversi riferire a un
punto preciso dell’architettura, quindi a un particolare segmento di applicazione.
In un ambiente virtualizzato, infatti, i servizi sono accessibili e utilizzabili
in qualsiasi momento, in qualsiasi contesto. All’interno di una San, i
servizi dovranno inevitabilmente essere “mobilizzati”, ovvero adattabili
al deployment in diversi contesti, senza interrompere l’esecuzione dei
processi. Inoltre, dovranno essere legati alla rete ma non richiamabili direttamente,
in quanto ciascuna invocazione sarà processata dallo strato di intelligenza
della San come una richiesta rivolta al pool di servizi, non al singolo servizio.
Dovranno, inoltre, essere indipendenti dalla specifica allocazione fisica e
dalla piattaforma che li ha generati, oltre che capaci di essere eseguiti, in
istanze parallele, da una pluralità di utenti.
