Caratteristiche, funzionamento e vantaggi dell’Architettura SOA in informatica

Caratteristiche, funzionamento e vantaggi dell’Architettura SOA in informatica

Architettura SOA

Con l’evoluzione dei sistemi distribuiti si è sviluppato il concetto di SOA (Service Oriented Architecture), ovvero un’architettura orientate ai servizi. In un’architettura SOA le applicazioni monolitiche sono scomposte in tanti servizi distinti che possono comunicare fra loro in rete.

In una SOA i “component software” sono di norma i “web services”: per realizzare una SOA possono essere usate anche altre tecnologie, ma sono questi ultimi i più usati e diffuse.
Un web services non è molto diverso da un componente software “tradizionale “, ciò che lo differenzia è un ristretto, ma significativo, insieme di caratteristiche:

  • è univocamente individuato da un identificativo (URL);
  • la sua interfaccia è descritta in un file XML;
  • può essere reperito da altri sistemi software.

In generale, una SOA è sostanzialmente un sistema in cui sono definiti tre ruoli e tre operazioni:

Ruoli:

  • Service Provider, chi fornisce il servizio e ne pubblica la descrizione per reperirlo;
  • Service Consumer, chi usufruisce del servizio, in sostanza l’applicazione che ne richiede una o più funzionalità;
  • Service Broker, chi gestisce le descrizioni dei servizi pubblicati, rendendole disponibili.

Operazioni:

  • Publish, azione tramite cui un servizio pubblica la propria descrizione (una sorta di “carta d’identità” del servizio);
  • Find, azione tramite cui chi cerca un servizio “consulta” l’insieme delle descrizioni disponibili;
  • Bind, azione tramite cui chi ha trovato il servizio richiesto si “lega” a chi lo fornisce, usufruendone e in tal modo invocandone le funzionalità.

Quindi SOA è uno stile architetturale basato sul concetto di servizio, che rappresenta l’elemento strutturale su cui le applicazioni vengono sviluppate. Un servizio può essere definite come un meccanismo per accedere ad una funzionalità o ad un insieme di funzionalità software attraverso un’interfaccia che ne stabilisce vincoli e politiche di utilizzo.
La necessità di interfacciare e far interoperare web services con sistemi legacy diversi ha portato alla creazione di una infrastruttura software chiamata ESB (Enterprise Service Bus), in grado di fornire efficienti ed efficaci adattatori tra i diversi sistemi. In un infrastruttura ESB, tutte le applicazioni sono integrate ed operano come “servizi” e la logica di integrazione è distribuita lungo gli endpoint connessi al bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità teorica ed è possibile effettuare gradualmente il rilascio delle funzionalità d’integrazione strettamente necessarie.

Caratteristiche, funzionamento e vantaggi dell'Architettura SOA in informatica

Vantaggi

Un primo vantaggio delle architetture SOA riguarda la comunicazione tra i servizi che avviene tramite messaggi e/o eventi, questo fa si che ci sia un basso accoppiamento, cioè una minima dipendenza e legame tra le varie parti del sistema, mentre nelle monolitiche, tale legame, è per costituzione molto forte. Questa logica fa in modo che i singoli moduli di un sistema, di fatto, ignorino le logiche ed il funzionamento degli altri moduli, cosa che però non ne penalizza il funzionamento finale, che è garantito dal continuo scambio di messaggi e comunicazioni fra i singoli moduli che dialogano e cooperano tra loro. Questo vantaggio si riflette anche in migliorie a livello organizzativo, infatti non essendoci una grande dipendenza la tra le varie parti del sistema, se si presentano errori su un determinate servizio, si potrà intervenire su di esso senza intaccare l’intero sistema. In una SOA, un’applicazione viene costruita assemblando funzionalità autonome e liberamente accoppiate. Pertanto, i servizi possono essere riutilizzati in più applicazioni indipendentemente dalle loro interazioni con altri servizi. Un altro vantaggio riguarda la maggiore affidabilità, perchè servizi indipendenti sono più facili da testare ed eseguire il debug rispetto a enormi blocchi di codice. Nelle SOA abbiamo una scalabilità e disponibilità migliorate, poichè le istanze multiple di un singolo servizio possono essere eseguite su server diversi contemporaneamente. Infine possiamo dire, riguardo ai servizi, che essi implementano protocolli standard per poter comunicare, avendo così una maggiore e facile integrazione.

Svantaggi

In questo paragrafo ci occuperemo di sottolineare gli svantaggi che porta con se un’architetura SOA, cercheremo di analizzarli anche da una prospettiva di confronto con i microservizi; poichè quando parleremo dell’architettura a microservizi cercheremo soluzioni che vadano ad eliminare o comunque limitare il più possibile l’impatto di tali svantaggi nell’implementazione dell’applicazione e nella sua efficienza in produzione.

I primi svantaggi li troviamo nel fatto che vi è una maggiore complessità del sistema ed un maggior costo iniziale in fase di progettazione. Questi effetti, possono comunque essere ridotti nel medio e lungo termine, grazie ad una maggiore produttività e sviluppo rispetto al caso monolitico. In un sistema SOA, fondamentalmente troviamo un’applicazione distribuita, di conseguenza cambiamenti ed aggiornamenti anche piccoli, portano a dover modificare e coordinare contemporaneamente più parti dell’applicazione e più gruppi di lavoro. Questo può significare che gli addetti al settore in cui avviene la modifica siano costretti ad attendere che altri team abbiano cambiato la loro parte di servizio e questo di conseguenza si traduce in tempi più lunghi di sviluppo e messa in produzione.

L’orchestrazione e l’integrazione dei servizi è contenuta nello stesso “blocco” e questo può andare bene solo nel momento in cui non si prevedano molte modifiche all’ interfaccia utente e ai vari servizi, che sono le parti che comunicano con questo “blocco”. L’applicazione SOA è divisa in servizi, ma è messa in produzione in modo monolitico, questo la differenzia con i microservizi che invece possono essere gestiti individualmente.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: https://vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *