SOA (Service Oriented Architecture): definizione e considerazioni

SOA è l’acronimo di Service Oriented Architecture, architettura orientata ai servizi.

Dal punto di vista IT, è un’architettura (software) distribuita, in cui si distinguono i servizi e l’infrastruttura; ha come obiettivo l’agilità dell’IT e la riduzione dello scostamento tra questo ed il business. Nella sua applicazione più spinta coinvolge l’IT ed il business totalmente, arrivando a interessare l’intera organizzazione aziendale.

I servizi, che costituiscono motivazione all’infrastruttura, sono componenti software, distribuiti su domini di competenza diversi, che invocati eseguono l’operazione che gli si richiede e tornano dei risultati.

L’infrastruttura, ingegnata a strati, è finalizzata all’interoperabilità, all’organizzazione, al censimento, alla gestione, al monitoraggio, alla composizione ed al rendiconto dei servizi.

L’interoperabilità è la capacità, resa “semplice”, di colloquio tra i servizi ed i loro utilizzatori. E’ assicurata da standard (Oasis, W3C ed altri) che costituiscono il fondamento dell’infrastruttura e base da cui partire. E’ rafforzata, solitamente, ma non obbligatoriamente, da software di mediazione. Questi strumenti aggiungono un livello ulteriore di disaccoppiamento, garantiscono gli standard ove non presenti (non previsti, non implementabili al momento, …) e svolgono delle operazioni di interesse comune (trasformazione, instradamento, arricchimento, …), sgravando i servizi dal prevederle (svilupparle, mantenerle, …) e costituendo un unico punto ove gestirle.

L’organizzazione ed il censimento dei servizi è conseguita mediante cataloghi che permettono la ricerca mediante parole chiave ed espongono i contratti, le politiche, i punti di accesso dei servizi che censiscono, organizzandoli, ad esempio, per livelli di interesse (aziendale, dipartimentale, locale, …). La finalità dei cataloghi è quella di esporre il parco servizi di cui un’azienda dispone, permettendone la ricerca e riportando cosa è già stato fatto, come accedervi, cosa fornirgli in ingresso, cosa ritornano, ecc.

Il monitoraggio consiste nella misura dei servizi: l’uso, la vitalità, i problemi, la provenienza delle chiamate, il loro contenuto, il rispetto delle politiche di autenticazione o di autorizzazione, delle performance previste nel contesto degli SLA (Service Level Agreement), ecc. La gestione comprende l’accesso a versioni precedenti, il ciclo di vita dei servizi, ecc. Sia il monitoraggio che la gestione avvengono mediante software che si comporta da broker (intermediario) o che dispone di agenti sulle macchine ove i servizi sono ubicati.

La composizione consiste nel creare un processo combinando, tra loro, chiamate a servizi, operazioni sui risultati, arricchimenti con dati esterni ed operazioni manuali svolte dagli utenti (approvazione, invio mail, …). Ciò che si ottiene è qualcosa che ha valore per il business, che vede i passi che lo compongono come componenti elementari necessari a raggiungere ciò che si è prefissato. Questo strato è l’anello di congiunzione tra i servizi (ciò che l’IT mette a disposizione) ed i processi (ciò che interessa e vede il business). Dal punto di vista dell’IT il processo è esposto come servizio e quindi è a sua volta impiegabile, come passo elementare, in composizioni di più alto livello.

Il rendiconto, infine, simile al monitoraggio, fornisce informazioni utili e comprensibili al business management: vendite andate a buon fine o mancate, livelli di scorta, ecc. E’ conseguito con strumenti che raccolgono dati di interesse, li aggregano, li mostrano su grafici, tabelle, ecc.

—-><—-

Aggiungo alcune considerazioni sui servizi.

Dal punto di vista dell’IT sono tutti servizi, processi o meno. Dal punto di vista del business, invece, non tutti i servizi sono processi. Questo significa che, tra i servizi, è possibile individuare una “gerarchia”: servizi coincidenti con i processi, servizi coincidenti con i passi elementari dei processi e servizi utili a costituire tali passi. Questo significa che alcuni servizi non saranno a disposizione del business, altri ancora lo saranno e potranno essere impiegati come passi elementari per costruire processi (e quindi costituiranno altri passi elementari impiegabili in processi più “complessi”). I livelli superiori di visibilità, chiaramente, o nascondono del tutto il servizio o ne nascondono la complessità (concetto legato all’incapsulamento).

Queste affermazioni implicano che la composizione svolta, con modalità simili, a strati diversi dell’architettura, abbia finalità diverse; solo quella svolta al livello che ho chiamato “composizione” ha finalità e valore per il business; quelle svolte a strati inferiori hanno solo valore propedeutico per la creazione dei passi elementari (poi usabili dal business).

—-><—-

Altre più generali.

L’architettura è ingegnata a strati, senza obbligo alcuno, può essere implementata parzialmente o totalmente, non esiste uno stack da implementare nella sua totalità.

SOA non è (solo) un insieme di web services. I servizi devono essere dettati dal business, devono avere il valore che ho discusso, l’interfaccia standard è qualcosa che arricchisce ma da sola non basta. Spesso ci si riferisce ad un insieme di web services con il termine JBOWS (Just a Bunch Of Web Services). SOA, tra l’altro, è un’architettura agnostica alla tecnologia: i web services sono solo un modo per risolverla preferito ad altre soluzioni per l’indipendenza dal framework e per la massiccia produzione di standard, di implementazioni e di strumenti dedicati (software o hardware).

Non è un nuovo concetto: le routine (sotto-programmi, funzioni, …) sono sempre esistite, così come esistono da un po’ i componenti distribuiti (Corba, Ejb, …), SOA aggiunge l’interoperabilità (garanzia di accesso ai componenti da parte di chiunque e da ovunque, in accordo con le politiche) e la netta protensione al business (i servizi sono ingegnati per reagire il più velocemente possibile alle nuove strategie aziendali, riducendo l’attesa di attuazione).

Dato il problema può essere una delle possibili soluzioni, magari anche la più adatta, ma è solo una soluzione specifica ad un problema ben definito.

—-><—-

Altre definizioni:

• OASIS SOA reference Model TC
• SearchWebservice.com: A defining moment for SOA

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione