Pubblicato nella Rubriki Numero 1 - 21 Feb 2006 da Alessandro Petrozzelli

Con l'acronimo SOA (Service Oriented Architecture) si identifica l'insieme delle caratteristiche architetturali necessarie ad un agente software per considerarne "ben fruibile" la capacità peculiare (service).

La precedente definizione è estremamente generica (al limite dell'inutilità), tuttavia esprime l'esatta volontà di aderire a precisi requisiti di usabilità dell'artefatto software: la centralità della funzione è necessaria per comporre sistemi complessi a partire da ingredienti elementari.

Proprio la caratteristica "sfuggente" di SOA rende più agevole descrivere cosa non sia piuttosto che l'opposto: non che manchi di identità concreta anzi, è esattamente l'essenzialità del concetto che ne è alla base a richiedere di essere minimalisti.

Partiremo dunque da qualche punto fermo (sotto forma di definizione) per poi approfondire, utilizzando gli errori più comuni che si incontrano comunemente come guida, al fine di dettagliare progressivamente quali siano le caratteristiche desiderabili (e non) di un sistema software che si possa definire Service Oriented.

Cos'è una architettura orientata al servizio?

Innanzitutto occorre aver ben definito quali sono gli obiettivi che si propone un progettista che intenda abbracciare la filosofia orientata ai servizi, quale il contesto nel quale è appropriato proporla, quali le forze che si oppongono al raggiungimento del risultato ed infine quali i parametri che misurano i risultati.

L'obiettivo che, in primo luogo, è dato al progettista di un sistema SOA è di armonizzare le funzionalità di un sistema IT con i processi di business aziendali: evitare di porre ostacoli al compimento ed all'evoluzione dei processi stessi ed anzi promuovere la composizione creativa delle funzionalità basilari verso funzionalità più complesse ed evolute.

Cosa intendiamo dunque per servizio? Un servizio è una astrazione che individua ed identifica completamente una esigenza funzionale di alto livello (intendendo per "alto livello" la "vicinanza", anche concettuale, all'utente finale, sia esso umano che macchina). Parallelamente alle caratteristiche funzionali ve ne sono altre, desiderabili dal punto di vista tecnologico, che possiamo definire "operative" e che concorrono a realizzare concretamente un sistema flessibile e pronto ai cambiamenti: se è vero che ogni organizzazione IT può (e deve) fornire un ventaglio di servizi distinto e personalizzato ed è dunque raro che possa trovare soluzioni pronte all'uso, è altrettanto vero che dotandosi delle corrette infrastrutture (piattaforme, prodotti, servizi esterni) il compito di gestione diventa meno arduo.

Ecco perchè si parla di architettura: l'essere orientato al servizio non prescrive requisiti funzionali aggiuntivi rispetto a quelli tradizionalmente catturati con le consuete fasi di analisi e design, tuttavia condurrà la scelta tra le varie soluzioni possibili. E' un lavoro di cernita nello spazio delle soluzioni. Tra le buone soluzioni ve ne sarà una migliore delle altre (preferibile) nei confronti degli obiettivi menzionati in precedenza.

Perchè è difficile realizzare servizi? La parte difficile è "catturare" l'essenza della funzionalità stessa e mantenerne l'identità e la monoliticità, anche dopo che la canonica attività del processo di informatizzazione l'ha analizzata, sviscerata, scomposta, riorganizzata, distribuita, canalizzata ed irrigidita. Ma non solo. Una volta identificato (ed eventualmente realizzato) l'arsenale di propri servizi, ci si potrebbe rendere conto che la componibilità tanto agognata è resa difficoltosa da un subdolo ostacolo: come assicurarsi che il servizio sia compreso ed utilizzato facilmente? Come descrivere quali sono i concetti familiari al servizio stesso e che gli consentono di comunicare oltre i propri confini? Come evolvere il sistema garantendo comunque la compatibilità con quanti si siano affidati ad esso? In ultima analisi SOA descrive una particolare morfologia di sistemi distribuiti e pertanto ha principalmene a che fare con l'architettura orientata ai componenti dalla quale eredità tutte le esperienze quali ad esempio i design pattern. Proprio questi ultimi (ed i loro parenti, antipattern) forniscono indicazioni e soluzioni sicure alle quali ispirarsi.

Quello che segue è un elenco, corredato da una sommaria descrizione di antipattern (2) facilmente rilevabili in ambito SOA.

Antipatterns

• Technology bandwagon: descrive la situazione tipica di organizzazioni che, prese dall'entusiasmo per la tecnologia, si lancia con foga nella nuova avventura senza considerare a fondo quali implicazioni (anche economiche) questa possa avere. Occorre infatti ricordare che i problemi cui SOA cerca di porre rimedio sono innanzitutto nel campo della flessibilità del business: senza una esatta definizione delle aspettative ed un una corretta percezione degli effetti, gli sforzi sono ovviamente destinati ad affievolirsi nel tempo col rischio di annullare la fiducia nella soluzione SOA.
• So, what's new?: parzialmente opposto al precedente, si rileva nell'opposizione a considerare le potenzialità dell'approccio SOA una realtà. Dovuto principalmente al fatto di averne soltanto scalfito il significato, questo fattore può essere rimosso soltanto proponendo analisi approfondite che evidenziano i potenziali benefici.
• The Big Bang: simile al "Technology bandwagon", si differenzia per l'illusione di poter cambiare dall'oggi al domani tutta l'infrastruttura tecnologica e goderne immediatamente i benefici. Al contrario, SOA è un percorso, che fa evolvere in una direzione di maggiore fluidità, tutto il business nel complesso, ma non necessariamente tutto in blocco. Questo percorso deve essere identificato, calibrato e pianificato, con attenzione.
• Web Service = SOA: l'errata convinzione che SOA sia un altro nome per i web services conduce ad una errata realizzazione che sicuramente peccherà di quella consistenza e visione d'insieme che è proprio la vera dote che SOA porta con se. Il risultato assomiglierà tantissimo ad un API remota con l'aggravante di penalizzare le prestazioni, moltiplicare le interfaccie tra i sistemi, favorire le congiunzioni punto-punto.
• The silo approach: diverse applicazioni mostrano repliche di servizi simili o uguali a causa del fatto che l'analisi dei possibili servizi è stata fatta a livello di applicazione e non a livello globale (bottom-up). Il mancato effetto di razionalizzazione è spesso dovuto alla mancanza di SOA-orientation da parte dell'organizzazione stessa che non è stata in grado di modificare i propri assetti.
• Misbehaving registries: una parte (evoluta ma fondamentale) del percorso verso SOA è l'uso di registri per il censimento e l'individuazione dei servizi [UDDI (Universal Description, Discovery and Integration) è un protocollo standard utilizzato per accedere ai repository]. Una disorganizzazione del processo di individuazione, censimento (e dunque descrizione) e ricerca, è una potenziale fonte di "diluizione" della credibilità del servizio stesso: se il servizio che cerco esiste ma non riesco a trovarlo posso creare una duplicazione, se è descritto in maniera non appropriata (il che può anche significare non aver preventivamente individuato un vocabolario comune) posso credere, erroneamente, di averlo trovato... Anche questo antipattern è dovuto ad un difetto organizzativo.
• Chatty services: in un modo piuttosto stretto conseguenza dell'antipattern "Web Service = SOA", ne è in qualche modo il risultato. L'interazione con i servizi afflitti da questa problematica è di tipo conversazionale: molte esecuzioni con piccole quantità di dati. Spesso dovuto alla semplice traslazione di API locali in web services, contrasta la natura stateless di SOA nel quale, solitamente, la richiesta di una esecuzione di servizio ha le sembianze di uno scambio (non necessariamente sincrono) di messaggi. La granularità dei servizi è un tema assai centrale: se eccessiva si è tentati di cadere nella tentazione di, implicitamente, codificare un protocollo comunicazione se non addirittura un workflow che invece, in una architettura propriamente disegnata, sono delegati ad altri attori del sistema (Web Services Choreography Description Language Version 1.0 e Web Services Business Process Execution Language Version 2.0
• Point-to-point services: come il precedente ed il successivo è conseguenza di mancanza di design approfondito che, in questo caso, conduce ad una strategia di integrazione tra servizi di tipo punto-punto. Ovviamente risente di tutti i difetti tipici dei sistemi con alto accoppiamento.
• Component-less services: antipattern subdolo poichè nascosto (si osserva soltanto analizzando il codice e non mostra sintomi...se non quando ormai è tardi) è dovuto alla concentrazione dello sviluppo sulla modalità di integrazione "esterna" (vista servizo) e poca a quella interna (vista componente). SOA concerne l'integrazione tra sistemi, non sostituisce alcun principio precedente di design "intra-modulo" (qualunque cosa significhi, dalla singola libreria all'intera applicazione), dunque la flessibilità che consente non deve essere ostacolata dalla "vischiosità" interna del componente che lo realizza, altrimenti se ne perdono i benefici.

Conclusioni

Come si è visto, saremmo in buona compagnia se cedessimo alla tentazione di liquidare SOA come l'ennesima sigla priva di significato ed applicazioni pratiche, tuttavia cercando di evidenziarne le motivazioni basilari, spero di essere riuscito a solleticare la curiosità di colui che prima di mettersi a tracciare disegni e scrivere codice ama farsi domande, affinchè la prossima volta se ne faccia una di più e così possa realizzare un prodotto ancora migliore.

Ispirazione tratta da 1) Toward a pattern language for Service-Oriented Architecture and Integration Part 1: Build a service ecosystem di Ali Arsanjani, Ph.D. e 2) SOA antipatterns di Jenny Ang, Luba Cherbakov e Dr. Mamdouh Ibrahim pubblicati presso IBM developerWorks

3) Oracle Service-Oriented Technology Center

4) Sun Service Oriented Architecture

5) Microsoft SOA Center