Che cos'è l'architettura orientata ai servizi (SOA)?

La SOA rimuove le attività dello sviluppatore dell'applicazione che in precedenza sviluppava o duplicava le funzioni esistenti o doveva sapere come connettersi o fornire interoperabilità con le funzioni esistenti.

Ogni servizio in una SOA incorpora il codice e i dati necessari per eseguire una funzione aziendale completa e discreta (ad esempio la verifica del credito di un cliente, il calcolo del pagamento mensile di un prestito o l'elaborazione di una richiesta di mutuo). Le interfacce di servizio forniscono un legame debole, ovvero possono essere chiamate con poca o nessuna conoscenza del modo in cui il servizio è implementato nel livello sottostante, riducendo le dipendenze tra le applicazioni.

Questa interfaccia è un contratto di servizio tra il fornitore e il consumatore di servizi. Le applicazioni che si trovano al di là dell'interfaccia di servizio possono essere scritte in Java, Microsoft .Net, Cobol o in qualsiasi altro linguaggio di programmazione e possono essere fornite come pacchetti di applicazioni aziendali da una società (ad es. SAP), come applicazioni SaaS (ad es. Salesforce CRM) oppure come applicazioni open source.

Le interfacce di servizio sono spesso definite utilizzando il linguaggio WSDL (Web Service Definition Language), una struttura di tag standard basata su xml (Extensible Markup Language).

I servizi vengono esposti utilizzando protocolli di rete standard, ad esempio SOAP/HTTP o Restful HTTP (JSON/HTTP), per inviare richieste di lettura o per modificare i dati. La governance dei servizi controlla il ciclo di vita dello sviluppo e, nella fase appropriata, i servizi vengono pubblicati in un registro  affinché gli sviluppatori li possano trovare e riutilizzare rapidamente per assemblare nuove applicazioni o processi aziendali.

Questi servizi possono essere creati da zero, ma spesso vengono creati esponendo funzioni di sistemi di record legacy come interfacce di servizio.

In questo modo, la SOA rappresenta una fase importante nell'evoluzione dello sviluppo e dell'integrazione delle applicazioni negli ultimi decenni. Prima che la SOA emergesse alla fine degli anni '90, connettere un'applicazione a dati o funzioni ospitati in un altro sistema richiedeva un'integrazione point-to-point complessa, che gli sviluppatori dovevano ricreare, in parte o completamente, per ogni nuovo progetto di sviluppo. L'esposizione di tali funzioni tramite servizi SOA ha permesso allo sviluppatore di riutilizzare semplicemente la funzionalità esistente e connettersi tramite l'architettura SOA ESB (vedi sotto).

Sebbene SOA e la più recente architettura di microservizi condividano molte parole in comune (ovvero "servizio" e "architettura"), sono solo vagamente correlate e, di fatto, operano in ambiti diversi, come discusso più avanti in questo articolo.

Un Enterprise Service Bus (ESB) è un modello di architettura che prevede l'utilizzo di un componente software centralizzato per gestire le integrazioni tra le applicazioni. Esegue trasformazioni dei modelli di dati, gestisce la connettività e la messaggistica, esegue l'instradamento, converte i protocolli di comunicazione e potenzialmente gestisce la composizione di più richieste.

L'ESB può rendere disponibili queste integrazioni e trasformazioni come interfaccia di servizio per il riutilizzo da parte di nuove applicazioni. Il modello ESB viene in genere implementato attraverso un tempo di esecuzione di integrazione e un set di strumenti progettati ad hoc per assicurare la migliore produttività possibile.

È possibile implementare una SOA senza architettura ESB, ma questo equivarrebbe a disporre di un insieme disarticolato di servizi. Ogni proprietario dell'applicazione sarebbe costretto a connettersi direttamente al servizio di cui ha bisogno ed eseguire le necessarie trasformazioni dei dati per adeguarsi a ciascuna delle interfacce di servizio.

Questa soluzione è alquanto laboriosa (anche se le interfacce sono riutilizzabili) e comporta ulteriori complicazioni nella successiva manutenzione, poiché ogni connessione è di tipo punto a punto. Infatti, gli ESB sono stati alla fine considerati un elemento talmente fondamentale di qualsiasi implementazione SOA che i due termini sono talvolta utilizzati come sinonimi, creando confusione.

Rispetto alle architetture che l'hanno preceduta, la SOA ha offerto vantaggi significativi all'impresa:

• Maggiore agilità aziendale; time to market più rapido: la riutilizzabilità è fondamentale. L'efficienza dell'assemblaggio di applicazioni a partire da servizi riutilizzabili, ossia blocchi di costruzione, anziché riscrivere e reintegrare ogni nuovo progetto di sviluppo, consente agli sviluppatori di creare applicazioni molto più rapidamente in risposta a nuove opportunità di business.
  L'approccio architettonico orientato ai servizi supporta scenari per l'integrazione delle applicazioni, l'integrazione dei dati e l'automazione in stile di orchestrazione dei servizi dei processi o dei workflow aziendali. Ciò accelera la progettazione e lo sviluppo del software consentendo agli sviluppatori di dedicare notevolmente meno tempo all'integrazione e più tempo a concentrarsi sulla realizzazione e sul miglioramento delle proprie applicazioni.
• Possibilità di utilizzare funzionalità legacy in nuovi mercati: una SOA ben congegnata consente agli sviluppatori di prendere facilmente le funzioni "bloccate" in una piattaforma o ambiente informatico ed estenderle a nuovi ambienti e mercati. Ad esempio, molte aziende hanno utilizzato la SOA per portare delle funzionalità dai sistemi finanziari basati su mainframe a nuove applicazioni web, consentendo ai loro clienti di servirsi di processi e informazioni precedentemente accessibili solo attraverso l'interazione diretta con i dipendenti o i business partner dell'azienda.
• Miglioramento della collaborazione tra azienda e IT: in una SOA, i servizi possono essere definiti in termini aziendali in termini di business (per esempio, "generare un preventivo assicurativo" o "calcolare il ROI di un bene strumentale"). Questo consente agli analisti aziendali di lavorare in modo più efficace con gli sviluppatori su importanti insight, quali l'ambito di un processo aziendale definito da un servizio o le implicazioni aziendali della modifica di un processo, che possano portare ad un risultato migliore.

Fino al 2010 le implementazioni SOA sono state utilizzate a pieno regime presso aziende leader praticamente in ogni settore. Ad esempio:

Delaware Electric è passata alla SOA per integrare sistemi che in precedenza non comunicavano tra loro, con conseguente miglioramento dell'efficienza, il che ha aiutato l'organizzazione a rimanere solvente durante un periodo di congelamento quinquennale delle tariffe elettriche imposto dallo stato.

Cisco ha adottato la SOA per assicurarsi che il proprio processo di ordinazione dei prodotti fosse coerente per tutti i prodotti e in tutti i canali, e ha quindi reso disponibili i processi di ordinazione come servizi che le divisioni, le acquisizioni e i business partner di Cisco potevano incorporare nei propri siti web.

L'Independence Blue Cross (IBC) di Filadelfia ha implementato una SOA per garantire che le diverse parti che trattavano i dati dei pazienti, cioè agenti di assistenza ai clienti IBC, uffici dei medici, utenti del sito web IBC, lavorassero sulla stessa origine dati (una "singola fonte affidabile").

Gli esperti hanno riempito alcune migliaia di pagine cartacee e digitali comparando SOA e microservizi e definendo le sottigliezze della loro reciproca relazione. Ai fini del presente articolo, le differenze principali tra i due sono l'accoppiamento dei componenti e l'ambito dell'utilizzo:

La SOA è uno stile architettonico di integrazione e un concetto esteso a livello aziendale. Consente alle applicazioni esistenti di essere disponibili su interfacce tra esse poco collegate, ciascuna corrispondente a una funzione aziendale, il che consente alle applicazioni in una parte di un'azienda estesa di riutilizzare la funzionalità in altre applicazioni.

L'architettura di microservizi è uno stile architettonico e un concetto di applicazione. Consente di suddividere i componenti interni di una singola applicazione in elementi più piccoli che possono essere modificati, scalati e amministrati in modo indipendente. Non definisce il modo in cui le applicazioni comunicano tra loro, per questo torniamo all'ambito aziendale delle interfacce di servizio fornite dalla SOA.

I microservizi hanno cominciato a farsi conoscere e apprezzare con l'avvento della virtualizzazione, del cloud computing, delle pratiche di sviluppo Agile e della metodologia DevOps. La maggior parte dei vantaggi dei microservizi in questi contesti deriva dal disaccoppiamento dei componenti, che semplifica e migliora quanto segue:

• Agilità e produttività degli sviluppatori: i microservizi consentono agli sviluppatori di incorporare nuove tecnologie in una parte dell'applicazione senza influenzare il resto dell'applicazione. Qualsiasi componente può essere modificato, testato e distribuito indipendentemente dagli altri, velocizzando i cicli di iterazione.
• Scalabilità: i microservizi possono sfruttare al massimo la scalabilità del cloud, le dimensioni di qualsiasi componente possono essere adeguate in modo indipendente per ottenere una risposta più rapida alle richieste del workload e per un utilizzo più efficiente delle risorse di elaborazione.
• Resilienza: anche in questo caso, grazie al disaccoppiamento, il malfunzionamento di un microservizio non ha impatto sugli altri. Ed ogni microservizio può essere utilizzato in base ai propri requisiti di disponibilità senza vincolare gli altri componenti o l'intera applicazione in base ai requisiti di disponibilità più comuni.

Per un'analisi più approfondita delle differenze tra SOA e microservizi, consulta "SOA e microservizi: qual è la differenza?"

Così come l'architettura di microservizi ha il potenziale per apportare miglioramenti in agilità, scalabilità e resilienza al design delle applicazioni, queste stesse tecniche possono essere applicate anche all'integrazione.

Questo è importante perché, nel tempo, lo schema ESB fortemente centralizzato e il relativo team centralizzato di specialisti dell'integrazione possono diventare un collo di bottiglia. Prendendo in prestito dai principi dei microservizi, possiamo potenzialmente suddividere l'ESB in integrazioni più dettagliate e decentrate. Questa è una delle premesse fondamentali alla base dell'integrazione agile.