I servizi secondo SOA

SOA (Service Oriented Architecture) è un’architettura software distribuita in cui si distinguono servizi ed infrastruttura.

I servizi, motivazione all’infrastruttura, sono componenti software distribuiti che “interpellati” svolgono quello per cui sono stati preposti.

SOA aspira alla perfetta sincronia tra l’IT ed il business:

• alla veloce esecuzione di modifiche e di nuove richieste

• alla minimizzazione di costi, risorse e sforzi

• alla pronta risoluzione di guasti, disservizi e problemi

• alla massimizzazione dei proventi ed alla capacità di reagire, in fretta, a nuove occasioni

Questo è solitamente tradotto in gergo IT come agilità.

Riferendomi ai soli servizi, indipendentemente dal metodo seguito per individuarli, voglio investigare su come è (ad oggi) possibile massimizzarne l’agilità.

1. I servizi espongono e rendono fruibili le funzionalità mediante un’interfaccia; questa, al fine di minimizzare costi e sforzi, deve celarne l’implementazione (proprietà nota come debole accoppiamento).

2. L’interfaccia che il servizio espone è sicuramente accedibile mediante almeno un “trasporto”; maggiore è l’offerta e superiore è l’agilità conseguibile. La stessa agilità, o quasi, sarebbe probabilmente conseguibile se l’unico trasporto offerto fosse standard, largamente accettato ed implementato.

3. L’interfaccia pubblicizza una o più funzionalità, ciascuna delle quali, eventualmente, accetta qualcosa in ingresso e torna risultati in uscita: maggiore è la comprensione che se ne ha e superiore è l’agilità (identificabile con la possibilità di riuso).

4. La struttura dei dati che ogni servizio accetta e torna è solitamente stabilita; la decisione di gestire nuovi dati o di non farlo crea delle difficoltà: maggiore è la dote (intrinseca o indotta) di “adattabilità” del formato usato come “veicolo” e superiore è l’agilità conseguibile. Va deciso, però, se e come avvalersene (dato che potrebbe creare discrepanze e proliferazione tra le interfacce).

5. Le funzionalità “nude e crude” non sono a volte sufficienti ed è necessario prevederne altre “accessorie”. Implementando quest’ultime all’esterno di ciò che è veramente d’interesse per il business, superiore sarebbe l’agilità.

6. Se gli scambi, infine, non fossero basati su uno stato, l’agilità conseguibile sarebbe maggiore.

—-><—-

Altro materiale sull'argomento:

• SOA Principles: The Service-Orientation Design Paradigm

—-><—-

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