SOA (Service-Oriented Architecture)

menu icon

SOA (Service-Oriented Architecture)

Scopri di più sulla SOA (service-oriented architecture), una tappa importante nell'evoluzione dello sviluppo e dell'integrazione delle applicazioni.

Cosa è la SOA (service-oriented architecture)?

La SOA, o architettura orientata ai servizi, definisce un modo per rendere i componenti software riutilizzabili tramite interfacce di servizio. Queste interfacce utilizzano standard di comunicazione comuni in modo da poter essere rapidamente integrate in nuove applicazioni senza dover eseguire ogni volta una profonda integrazione.

Ogni servizio in una SOA incorpora il codice e le integrazioni dei dati necessari per eseguire una funzione aziendale completa e discreta (ad esempio, il controllo del credito del cliente, il calcolo di un pagamento di un prestito mensile o l'elaborazione di un'applicazione ipotecaria). Le interfacce di servizio forniscono un accoppiamento libero, il che significa che possono essere richiamate con poca o nessuna conoscenza della sottostante modalità di implementazione dell'integrazione. I servizi sono esposti utilizzando protocolli di rete standard - come SOAP (simple object access protocol)/HTTP o JSON/HTTP - per inviare richieste di lettura o modifica dei dati. I servizi sono pubblicati per consentire agli sviluppatori di trovarli rapidamente e riutilizzarli per assemblare nuove applicazioni.

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

In questo modo, SOA rappresenta una tappa importante nell'evoluzione dello sviluppo e dell'integrazione delle applicazioni negli ultimi decenni. Prima che la SOA emergesse alla fine degli anni 90, il collegamento di un'applicazione a dati o funzionalità ospitate in un altro sistema richiedeva una complessa integrazione point-to-point - integrazione che gli sviluppatori dovevano ricreare, in parte o completamente, per ogni nuovo progetto di sviluppo. L'esposizione di tali funzioni tramite SOA elimina la necessità di ricreare ogni volta la profonda integrazione.

Si noti che sebbene SOA e la più recente architettura dei microservizi condividano molti termini, sono collegate solo vagamente e, di fatto, operano in ambiti diversi, come illustrato in seguito nel presente articolo.

Cosa è un ESB?

Un ESB, o enterprise service bus, è uno schema in base al quale un componente centralizzato esegue l'integrazione ai sistemi di backend e rende tali integrazioni disponibili come interfacce di servizio. Esegue la trasformazione dei modelli di dati, gestisce la connettività, l'instradamento e potenzialmente la composizione di più richieste e le rende disponibili come una singola interfaccia di servizio per il riutilizzo da parte di nuove applicazioni. Il modello ESB viene generalmente implementato utilizzando un runtime di integrazione appositamente progettato ed un insieme di strumenti adatto alle funzionalità sopra indicate, garantendo la migliore produttività possibile.

In teoria, è possibile implementare una SOA senza un ESB, ma i proprietari di applicazioni dovrebbero individuare un modo univoco per esporre le interfacce di servizio e questa operazione richiede molto lavoro (anche se le interfacce sono eventualmente riutilizzabili) e crea significative sfide di manutenzione in futuro. In realtà, gli ESB sono stati considerati un elemento di fatto di qualsiasi implementazione SOA al punto che i due termini vengono talvolta utilizzati come sinonimi, creando confusione.

Scopri di più sugli ESB consultando "Introduzione all'ESB (Enterprise Service Bus)".

Vantaggi della SOA

Rispetto alle architetture che l'hanno preceduta, la SOA offre notevoli vantaggi alle aziende:

  • Maggiore agilità aziendale; time to market più rapido: la possibilità di assemblare le applicazioni da interfacce di servizio riutilizzabili, piuttosto che riscrivere e reintegrare con ogni nuovo progetto di sviluppo, consente agli sviluppatori di creare applicazioni molto più rapidamente in risposta a nuove opportunità di business.
  • Possibilità di utilizzare funzionalità legacy nei nuovi mercati: una SOA ben realizzata consente agli sviluppatori di estrarre facilmente una funzionalità 'bloccata' in un ambiente o una piattaforma di calcolo e di estenderla a nuovi ambienti e mercati. Ad esempio, molte aziende hanno utilizzato la SOA per esporre le funzionalità dai sistemi finanziari basati su mainframe al web, consentendo ai propri clienti di utilizzare processi e informazioni precedentemente accessibili solo attraverso l'interazione diretta con i dipendenti o i business partner della società.
  • Collaborazione migliorata tra business e IT: in una SOA, i servizi possono essere definiti in termini commerciali (ad esempio, "generare preventivo assicurativo" o "calcolare il ROI dell'attrezzatura di capitale"). Questo consente agli analisti aziendali di lavorare in modo più efficace con gli sviluppatori su importanti insight - come 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.

Esempi di SOA

Nel 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 conseguenti efficienze di sviluppo che hanno aiutato l'organizzazione a rimanere solvibile durante un blocco di cinque anni sulle tariffe elettriche imposto dallo stato.
  • Cisco ha adottato la SOA per assicurarsi che la sua esperienza di ordinazione dei prodotti fosse coerente in tutti i prodotti e canali esponendo i processi di ordinazione come servizi che le divisioni, le acquisizioni e i business partner di Cisco potrebbero incorporare nei propri siti web.
  • IBC (Independence Blue Cross) di Philadelphia ha implementato una SOA per garantire che i diversi componenti che trattano i dati dei pazienti - operatori del servizio di assistenza ai clienti IBC, studi medici, utenti del sito web IBC - utilizzino la stessa origine dati.

SOA e microservizi

Gli esperti hanno scritto pagine e pagine in cui confrontavano SOA e microservizi e definivano le sfumature del loro reciproco rapporto. Ai fini del presente articolo, le differenze principali tra i due sono l'accoppiamento dei componenti e l'ambito dell'utilizzo:

  • La SOA è un concetto a livello aziendale. Consente di esporre le applicazioni esistenti su interfacce accoppiate in modo casuale, ognuna corrispondente ad una funzione aziendale, che consente alle applicazioni in una parte di un'azienda estesa di riutilizzare la funzionalità in altre applicazioni.
  • L'architettura dei microservizi è un concetto con ambito applicativo. Permette di suddividere gli elementi interni di un'unica applicazione in piccoli pezzi che possono essere modificati, scalati e gestiti 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.

L'architettura dei microservizi è emersa e ha guadagnato importanza con l'aumento della virtualizzazione, del cloud computing, delle pratiche di Agile e DevOps. La maggior parte dei vantaggi dei microservizi in questi contesti deriva dal disaccoppiamento completo dei componenti, che semplifica e migliora quanto segue:

  • Produttività e agilità dello sviluppatore: i microservizi consentono agli sviluppatori di incorporare nuove tecnologie in una parte dell'applicazione senza influire sul 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 - qualsiasi componente può essere scalato indipendentemente dagli altri per la risposta più rapida possibile alle richieste del carico di lavoro e l'utilizzo più efficiente delle risorse di elaborazione.
  • Resilienza: ancora, grazie al disaccoppiamento, il malfunzionamento di un microservizio non ha impatto sugli altri. E ogni microservizio può essere utilizzato in base ai propri requisiti di disponibilità senza impegnare gli altri componenti o l'intera applicazione in base ai più grandi requisiti di disponibilità comune.

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

Così come l'architettura dei 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 principali dietro l'integrazione agile.

SOA e IBM Cloud

Man mano che la tua azienda sposta la sua infrastruttura IT verso un approccio di cloud ibrido, è altamente probabile che diversi carichi di lavoro, inclusi quelli basati su SOA, verranno trasformati in modelli di distribuzione cloud più leggeri e flessibili. IBM è uno dei pionieri della SOA e le offerte e i servizi IBM Cloud possono utilizzare ed estendere i tuoi investimenti SOA esistenti sul cloud.

Passa alla fase successiva:

La SOA consente di rendere i servizi utilizzabili in diversi canali, indipendentemente dal punto in cui risiede l'applicazione principale del database, aiutando l'organizzazione a capitalizzare gli investimenti mentre modernizza le applicazioni nel percorso verso il cloud.

Inizia con un account IBM Cloud oggi stesso.