Cos'è una service oriented architecture (SOA)?

La Service-Oriented Architecture (SOA) è un tipo di progettazione software finalizzato al riutilizzo dei componenti software attraverso interfacce di servizio che usano un linguaggio di comunicazione comune in una rete. 

Un servizio è un'unità completa di funzionalità software, o un insieme di funzionalità, pensata per completare un'attività specifica come il recupero di determinate informazioni o l'esecuzione di un'operazione. Contiene il codice e le integrazioni di dati necessari per svolgere una funzione aziendale completa e distinta e può essere accessibile da remoto e interagibile o aggiornabile in modo indipendente.

In sostanza, integrando componenti software distribuiti e gestiti separatamente, il tipo architetturale SOA consente a questi ultimi di interagire tra loro per formare applicazioni software in sistemi diversi.

Prima che la SOA entrasse in uso alla fine degli anni '90, la connessione di un'applicazione a servizi ospitati in un altro sistema era un processo complesso caratterizzato da una capillare integrazione point to point (connettività, routing, traduzione di modelli di dati e così via), che poi doveva essere ricreata dagli sviluppatori per ciascun nuovo progetto. Questo modello era noto come "monolitico" perché il codice dell'intera app veniva creato in un'unica distribuzione. Se un singolo aspetto non funzionava correttamente, l'intera app doveva essere messa temporaneamente offline per risolvere il problema, quindi distribuita di nuovo come versione inedita. 

Grazie all'esposizione dei servizi con protocolli di rete standard (ad esempio, SOAP, JSON, ActiveMQ o Apache Thrift) per inviare richieste o accedere ai dati, la SOA rimuove la necessità di eseguire l'integrazione da zero. Gli sviluppatori possono invece utilizzare modelli denominati enterprise service bus (ESB), che eseguono l'integrazione tra un componente centralizzato e i sistemi di backend per poi renderli disponibili come interfacce di servizio. Ciò consente inoltre agli sviluppatori di riutilizzare le funzioni esistenti invece di ricrearle.

In uno stile di architettura service-oriented, i servizi comunicano utilizzando un sistema a "basso accoppiamento". Ciò consente di interconnettere i componenti (denominati anche "elementi") di un sistema o una rete affinché possano trasmettere informazioni o coordinare un processo aziendale riducendo le dipendenze tra di essi. Di fatto, questo processo crea una nuova app.  

• Time to market più rapido e maggiore flessibilità: il riutilizzo dei servizi rende molto più semplice e rapido l'assemblaggio di applicazioni, riducendo il carico di lavoro degli sviluppatori che non devono cominciare da zero come nel caso delle applicazioni monolitiche. 
• Uso dell'infrastruttura esistente in nuovi mercati: la SOA rende più semplici le attività di estensibilità e scalabilità delle funzionalità di una piattaforma o un ambiente a nuove piattaforme. 
• Costi ridotti grazie a una maggiore agilità e a uno sviluppo più efficiente
• Manutenzione semplice: essendo tutti i servizi autonomi e indipendenti, è possibile modificarli e aggiornarli in base alle esigenze senza influire sugli altri servizi. 
• Scalabilità: poiché la SOA consente il funzionamento su più servizi, piattaforme e linguaggi di programmazione, la scalabilità è notevolmente maggiore. Inoltre, la SOA utilizza un protocollo di comunicazione standardizzato, consentendo alle aziende di ridurre l'interazione tra clienti e servizi. L'abbassamento di tale livello di interazione consente di ridimensionare le app con meno pressione e meno inconvenienti. 
• Maggiore affidabilità: poiché eseguire il debug di servizi più piccoli rispetto a codici di grandi dimensioni è più semplice, le app create tramite il modello SOA sono più affidabili.
• Facile accessibilità: le strutture SOA sono disponibili per chiunque.

Gli elementi essenziali di una Service-Oriented Architecture sono costituiti da 3 ruoli. 

1. Provider di servizi

   Un provider di servizi crea servizi web e li fornisce a un registro dei servizi. Il provider del servizio è responsabile dei termini di utilizzo del servizio.

2. Broker di servizi o registro di servizi

   Un broker di servizi o registro di servizi è responsabile di fornire informazioni sul servizio a un richiedente. Un broker può essere pubblico o privato. 

3. Richiedente di servizi o consumatore di servizi

   Un richiedente di servizi trova un servizio in un broker di servizi o in un registro di servizi e contatta il provider di servizi per riceverlo.

Il concetto di servizi introdotto dalla Service-Oriented Architecture è oggi uno dei componenti centrali del moderno cloud computing e della virtualizzazione in sistemi quali il middleware e i microservizi. 

A causa delle loro somiglianze, le architetture SOA e dei microservizi sono spesso confuse. La differenza principale è che la SOA è un approccio architetturale di livello enterprise, mentre i microservizi sono una strategia di deployment adottata dagli sviluppatori di app. 

Inoltre, il modello SOA e i microservizi comunicano con i rispettivi componenti in modo diverso: la SOA utilizza un ESB, mentre i microservizi possono comunicare tra loro in modo autonomo, tramite API indipendenti dal linguaggio e ciò consente ai team di sviluppo di scegliere i propri strumenti. I microservizi offrono quindi una maggiore flessibilità.

Inoltre, il modello SOA viene confuso talvolta con il modello Software-as-a-service. Software-as-a-Service (SaaS) è un servizio di cloud computing che offre agli utenti un'applicazione cloud insieme alle piattaforme e all'infrastruttura IT che la supportano. I servizi web del modello SOA possono essere forniti dai provider di servizi come applicazioni SaaS. In genere, un provider di servizi cloud (ne sono esempi AWS, Azure o IBM Cloud) gestisce l'ambiente cloud che ospita l'applicazione SaaS. 

Gli utenti interagiscono con il software tramite un browser web installato nei propri computer o dispositivi portatili oppure utilizzano API come REST o SOAP per connettere il software ad altre funzioni.

Grazie all'evoluzione tecnologica dei container, i microservizi sono oggi alla base delle applicazioni cloud native: microservizi a basso accoppiamento che vengono distribuiti in container Linux e connessi tramite API o una rete mesh per il routing dei messaggi. 

Ogni elemento implementa una capacità di business ed è sviluppato in modo indipendente da piccoli team DevOps che utilizzano flussi di lavoro come l'integrazione e il deployment continui (CI/CD). Questo approccio consente di ottenere uno sviluppo software più rapido, un deployment automatico e aggiornamenti regolari senza le limitazioni dei cicli di sviluppo monolitici.  

Grazie alle sue soluzioni open source, tra cui Red Hat^® Enterprise Linux^® e Red OpenShift, Red Hat aiuta le aziende nel loro percorso di migrazione dell'infrastruttura e dell'ambiente di sviluppo applicativo al cloud computing per ottenere maggiore flessibilità e rapidità e nel contempo continuare a sfruttare i benefici dell'infrastruttura preesistente.