Che cos'è un ESB (Enterprise Service Bus)?

Un ESB effettua trasformazioni di modelli di dati, gestisce la connettività, esegue il routing dei messaggi, converte i protocolli di comunicazione e gestisce potenzialmente 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 runtime di integrazione e un set di strumenti progettati ad hoc (ovvero il prodotto esb) per assicurare la migliore produttività possibile.

L'ESB è un componente essenziale della SOA (Service-Oriented Architecture), un'architettura software affermatasi alla fine degli anni '90. La SOA definisce un modo per rendere riutilizzabili i componenti software mediante interfacce di servizio. In genere vengono utilizzate interfacce standard (ad esempio servizi web) per potere incorporare velocemente i servizi in nuove applicazioni senza doverne duplicare le funzionalità .

Ogni servizio di una  SOA incorpora il codice e i dati necessari per eseguire una funzione aziendale completa e discreta (ad es. controllare il credito di un cliente, calcolare la rata mensile di un prestito o elaborare 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. 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 (Simple Object Access Protocol)/HTTP o 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.

Pur potendo essere creati da zero, i servizi spesso vengono generati esponendo funzioni di sistemi legacy di registrazione. I business possono decidere di anteporre ai sistemi legacy un'interfaccia di servizio basata su standard, utilizzare l'ESB per connettersi direttamente al sistema legacy con un adattatore o un connettore oppure lasciare che l'applicazione fornisca la propria api. In ogni caso, l'ESB scherma la nuova applicazione dall'interfaccia legacy. Esegue la trasformazione e l'instradamento necessari per connettersi al servizio del sistema legacy.

È 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.

In teoria, un ESB centralizzato offre la possibilità di standardizzare, e semplificare notevolmente, la comunicazione, la messaggistica e l'integrazione tra i diversi servizi di un'azienda. I costi hardware e software possono essere condivisi, fornendo i server in base alle necessità per l'utilizzo combinato e offrendo così una soluzione centralizzata scalabile. Un singolo gruppo di specialisti può essere incaricato dello sviluppo e della manutenzione delle integrazioni (e, se necessario, opportunamente addestrato a tal fine).

Le applicazioni software si connettono all'ESB ("parlano" con esso) e lasciano a quest'ultimo il compito di trasformare i protocolli, indirizzare i messaggi e trasformarli nei formati dati richiesti, offrendo l'interoperabilità necessaria per l'esecuzione delle transazioni. L'approccio architettonico dell'ESB supporta scenari per l'integrazione delle applicazioni, l'integrazione dei dati e l'automazione dei processi di business basata sull'orchestrazione dei servizi. In questo modo gli sviluppatori possono dedicare molto meno tempo all'integrazione e molto più alla fornitura e al miglioramento delle proprie applicazioni. Inoltre, la capacità di riutilizzare queste integrazioni da un progetto all'altro offre il potenziale per ulteriori incrementi di produttività e risparmi a valle.

Ma nonostante l'ESB sia stato implementato con successo in numerose organizzazioni, in molte altre ha finito per essere percepito come il fatidico collo di bottiglia. Apportare modifiche o potenziamenti a un'integrazione può destabilizzare altri che hanno utilizzato quella stessa integrazione. Gli aggiornamenti al middleware ESB ha spesso influito su integrazioni esistenti, rendendo necessari test consistenti per l'esecuzione di qualsiasi aggiornamento. Essendo l'ESB gestito centralmente, i gruppi dedicati alle applicazioni si sono presto trovati a far la fila per le proprie integrazioni. Con il crescere del numero di integrazioni, l'implementazione dell'High Availability e del disaster recovery per i server ESB è diventata più costosa. Inoltre, il progetto ESB, essendo trasversale alle aziende, si è dimostrato difficile da finanziare, rendendo queste sfide tecniche ancora più difficili da risolvere.

In ultima analisi, le complessità legate alla manutenzione, all'aggiornamento e alla scalabilità di un ESB centralizzato si sono rivelate così impegnative e costose da ritardare quegli aumenti di produttività che proprio l'ESB, e la SOA, avrebbero dovuto realizzare, frustrando le aspettative dei gruppi, nei vari settori di attività, che avevano sperato in un ritmo più sostenuto di innovazione.

Per un approfondimento sull’ascesa e la caduta dell’ESB, leggi “The fate of the ESB”.

L'architettura basata su microservizi consente di suddividere i componenti interni di una singola applicazione in elementi più piccoli che possono essere modificati, scalati e amministrati in modo indipendente. 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. In questi contesti, i microservizi offrono i seguenti vantaggi:

• Maggiore agilità e produttività nella fase di sviluppo, poiché consentono agli sviluppatori di incorporare nuove tecnologie in una parte dell'applicazione senza toccare o "aggiornare" il resto.
• Scalabilità più semplice e conveniente grazie alla possibilità di modulare qualsiasi componente a prescindere dalle altre, per rispondere in modo più rapido possibile alle esigenze del carico di lavoro e utilizzare con maggiore efficienza le risorse di elaborazione.
• Maggiore resilienza, poiché il malfunzionamento di una parte non influisce sulle altre e ogni microservizio può soddisfare i propri requisiti di disponibilità senza vincolare gli altri componenti a requisiti di "massima disponibilità comune".

La stessa granularità che i microservizi offrono alla progettazione delle applicazioni può essere offerta anche all'integrazione, con vantaggi analoghi. Questa è l'idea alla base dell'integrazione agile, che suddivide l'ESB in componenti di integrazione granulari e decentralizzati, senza interdipendenze, che i singoli gruppi dedicati alle applicazioni possono possedere e gestire autonomamente.