Il seminario

Scopo del seminario è presentare le Service-Oriented Architecture (SOA),
stimolando l'interesse dei partecipanti e la discussione su tutti gli
aspetti di questo tipo di approccio, in modo che tutti i partecipanti
(pubblico e relatori) possano andarsene dal seminario sapendo qualcosa
in più.

Il seminario consisterà in una presentazione di circa 40 minuti e di
un dibattito. Nella presentazione saranno illustrati i concetti generali
alla base delle SOA, i contesti di utilizzo di queste architetture e i
principali problemi introdotti dalla loro adozione. Verrà poi mostrato
un semplice problema di esempio e un numero di approcci diversi per
risolverlo, mostrando di ciascuno i vantaggi e gli svantaggi.

Terminata la presentazione si darà il via alla discussione; in essa,
il ruolo dei relatori si limiterà allo stimolo e alla moderazione della
discussione stessa.

Àmbiti di applicazione

L'applicazione delle SOA è in crescita in àmbito sia commerciale
che scientifico.

In un ambito commerciale pensiamo ad esempio alla gestione di un ordine
di acquisto che viene effettuato via web: viene richiesto l'acquisto e
la spedizione di un certo bene, e la richiesta deve essere gestita su
un certo numero di sistemi diversi, sia interni all'azienda che esterni
(la base dati dei clienti, la base dati di inventario dei beni richiesti,
la gestione del pagamento per carta di credito, la spedizione effettiva
del bene richiesto, la fatturazione, la spedizione della fattura...).

In ambito scientifico pensiamo ad esempio ad esperimenti di bioinformatica
che, utilizzando dati e procedure sia interni che pubblicamente
disponibili, mirano a scoprire le correlazioni genetiche in una
particolare patologia: il centro di ricerca A fornisce un servizio
di consultazione di una propria base di dati genomici; l'ente B mette
a disposizione dei servizi che consentono di effettuare una "feature
selection" e "filtering" di questi dati per estrarre solo quelli relativi
a particolari geni di interesse; l'ente C mette a disposizione dei servizi
per l'applicazione di algoritmi generici di Data Mining (p.e.: Reti
Bayesiane, Support Vector Machine (KVM), K-nearest neighbor...). A questo
punto, un quarto laboratorio di ricerca, attraverso una composizione di
questi servizi remoti, può costruire il proprio particolare esperimento
creando un processo che: prelevi una base di dati attraverso il servizio
A, effettui su di questa una "feature selection" attraverso il servizio
B, e infine costruisca ed applichi ai dati filtrati una classificazione
mediante un algoritmo fornito dai servizi C.

Le SOA

Esistono diverse definizioni di SOA, ciascuna delle quali si concentra
su particolari aspetti del concetto generale. Nella definizione più
ampia e generale possibile, SOA (Service-oriented Architecture) è un
paradigma per la realizzazione e la manutenzione di processi implementati
su sistemi distribuiti su vasta scala. Per estensione vengono chiamate
SOA anche le architetture implementate sulla base di questo paradigma.

Le SOA trovano applicazione ovunque si abbia un insieme di sistemi
eterogenei, le cui funzionalità devono essere armonizzate e coordinate
insieme per creare dei servizi.

Spesso ciascuna di queste funzionalità è erogata da un sistema "legacy",
ovvero un sistema dedicato, completamente scollegato dagli altri, che
espone un proprio protocollo o API proprietario. Spesso sistemi diversi
fanno capo per la loro gestione a gruppi diversi all'interno della
stessa azienda; in alcuni casi si può trattare di servizi che sono
completamente esterni e quindi fuori dal controllo dell'azienda stessa.

A tutto questo si aggiunga che di fronte alla necessità di costruire
nuovi servizi sopra gli stessi componenti o con l'adozione di componenti
ulteriori, o di far evolvere i servizi esistenti per implementare
nuove funzionalità, bisogna poter rispondere con la massima rapidità
possibile.

Diversi ordini di problemi si oppongono. L'eterogeneità e la
decentralizzazione sono caratteristiche inevitabili di un sistema
distribuito complesso; affidarsi ad un unico vendor non aiuta (un vendor
sa fare bene un prodotto e meno bene un altro, e non ci si può affidare
100% ad uno solo senza rimanerne prima o poi scottati); a volte si rende
necessario cambiare vendor o prodotti, e questo deve essere possibile,
per quanto difficile, senza dover stravolgere completamente i processi
aziendali.

Gli approcci normalmente utilizzati per gestire queste situazioni (p.e.:
centralizzazione, omogeneità dei sistemi, omogeneità dei vendor e dei
prodotti...) segnano il passo di fronte alla complessità dei problemi
e all'impossibilità di far evolvere l'architettura in modo omogeneo
secondo uno schema coerente.

Introducendo i concetti base di servizio, interoperabilità e loose
coupling, il paradigma SOA fornisce gli strumenti teorici per gestire
questa complessità, garantendo flessibilità e creando le condizioni
necessarie per l'evoluzione.

È un approccio pervasivo, che entra a tutti i livelli: le parti in
causa nella realizzazione di un servizio sono quella cosiddetta "IT",
che gestisce materialmente hardware e sistemi, quella "Operativa" e di
"Sviluppo" che crea e gestisce il software che implementa i servizi,
e quella "Business" che descrive i flussi che devono essere implementati
sul sistema. Tutte queste componenti devono essere organizzate non solo
secondo le loro competenze, ma devono saper andare anche un pò oltre,
perché solo avendo una comprensione almeno minima delle problematiche
affrontate dagli altri settori si può arrivare a disegnare bene la
propria parte. Insieme a questi team specializzati è necessaria anche la
presenza di un team che, conoscendo i processi e l'architettura ad alto
livello, sappia individuare e anche anticipare i problemi, rivolgendosi
ai team specifici per la loro soluzione. È evidente che in tutte quelle
realtà dove le "business unit" sono state concepite come camere stagne,
le SOA entrano all'interno della stessa organizzazione del lavoro (e
non solo della realizzazione dei servizi), e richiedono un cambiamento
radicale.