Il legame tra SOA, ESB e Data Integration

SOA, ESB e Data Integration: in questo articolo approfondiamo questi tre modelli, spesso confusi e sovrapposti, per comprenderne meglio similitudini e differenze.

Innanzitutto, qualche definizione: cosa sono SOA e ESB?

La Service-Oriented Architecture (SOA), ovvero architettura orientata ai servizi, è una metodologia che consente di rendere i componenti software riutilizzabili e interoperabili grazie a interfacce di servizio che utilizzano un linguaggio di comunicazione comune. Ogni servizio contiene il codice e le integrazioni dei dati necessari per eseguire una funzione aziendale completa e distinta – ad esempio recuperare informazioni o eseguire un’operazione. I servizi sono messi a disposizione degli sviluppatori che possono trovarli e riutilizzarli per assemblare nuove applicazioni o processi aziendali.

La SOA è entrata in uso verso la fine degli anni ’90. Prima di allora, la connessione tra applicazioni veniva effettuata ricorrendo a integrazioni capillari point-to-point, con un approccio “monolitico” che costringeva gli sviluppatori a ricreare queste connessioni da zero per ogni nuovo progetto. Con questo modello il codice dell’intera app veniva creato in un’unica distribuzione, con la conseguenza che per qualsiasi tipo di modifica (o in caso di malfunzionamenti) l’intera app doveva essere messa temporaneamente offline fino alla distribuzione della versione aggiornata.

In questo senso la SOA rappresenta un’evoluzione importante, poiché rimuove la necessità di eseguire l’integrazione da zero: gli sviluppatori possono invece riutilizzare le funzioni esistenti invece di ricrearle, utilizzando un Enterprise Service Bus (ESB).

Un ESB è un modello architetturale in cui un componente software centralizzato esegue l’integrazione tra le applicazioni, gestendo trasformazioni di modelli di dati, connettività, routing, conversione dei protocolli di comunicazione e rendendo le integrazioni disponibili come interfacce di servizio per il riutilizzo da parte di nuove applicazioni.

Qual è il legame tra SOA ed ESB?

Implementare una SOA senza un ESB è possibile, ma richiederebbe molto lavoro creando significative difficoltà di manutenzione futura poiché di fatto si dovrebbero connettere le applicazioni in modalità point-to-point (pur utilizzando interfacce riutilizzabili).

L’ESB è considerato un elemento di fatto di qualsiasi implementazione di architettura service-oriented, in cui i servizi comunicano utilizzando un sistema a “basso accoppiamento”.

E la Data Integration?

Il principio cardine della Data Integration, in quella che è la nostra concezione, è il completo disaccoppiamento tra applicazioni che producono i dati e applicazioni che le consumano (ne parliamo meglio nella nostra Guida alla Data Integration).

Il principio di integrare i sistemi attraverso le interfacce, come avviene nel caso della SOA, è sicuramente un importante punto di partenza per perseguire l’obiettivo di un disaccoppiamento tra le applicazioni – ma nella realtà dei fatti questo accade raramente. Spesso, infatti, i servizi esposti dalle applicazioni vengono progettati per soddisfare l’esigenza di scambio dati con un’altra applicazione, implementando di fatto delle integrazioni Application-to-Application, annullando il riuso delle interfacce e creando delle forti dipendenze tra loro.

Anche utilizzare un ESB, strumento che dovrebbe aiutare a fare ordine, non è garanzia di riuso. Spesso gli ESB diventano un catalogo molto esteso di servizi, alcuni anche molto simili tra di loro e specifici per le integrazioni punto a punto tra determinate applicazioni; oppure dei semplici espositori di servizi, che non offrono ulteriori significativi vantaggi.

La metodologia della Data Integration invece, abbinata a una tecnologia che agisca come mediatore, permette di passare da sistemi a basso accoppiamento a un reale disaccoppiamento, raggiungendo l’obiettivo del riuso. Un approccio data-integration oriented nello scambio dati comporta che l’applicazione che espone i dati non conosca i consumatori dei dati, e quindi un completo disaccoppiamento tra di essi. Inoltre, l’espositore dei dati deve necessariamente porsi la domanda di quali dati siano di interesse per gli altri, quali dati forniscano un valore se combinati ad altri dati.

D’altro canto, l’utilizzatore del dato userà il servizio di dati esposto dal mediatore, senza avere integrazione diretta con il produttore del dato. Se cambia il produttore, il mediatore fornirà i dati all’utilizzatore secondo la stessa modalità prevista con il precedente produttore: l’utilizzatore non percepisce variazioni. Se invece cambia l’utilizzatore, il mediatore adeguerà il servizio secondo le esigenze del nuovo consumatore: al produttore non sono richiesti interventi.

In conclusione, questo approccio legato a una tecnologia adeguata permette di non legare le applicazioni tra loro in modo stretto (e con elevati costi di separazione), ma di condividere uno scambio dati che oggi può essere prodotto da un’applicazione, nel futuro da un’altra senza che questo cambio obblighi alla riscrittura di servizi specifici per le varie applicazioni collegate.