Che cos’è, a cosa serve e perché utilizzare un Enterprise Service Bus (ESB)

“Un ESB aiuta le aziende a sfruttare il valore dell’architettura SOA incrementando la connettività, aggiungendo la flessibilità che facilita il cambiamento e fornendo maggiore controllo sull’utilizzo delle importanti risorse che unisce.”

La nascita delle nuove tecnologie che tentano di migliorare i risultati del processo di integrazione, come la Service Oriented Architecture (SOA), l’Enterprise Application Integration (EAI) e i servizi web, hanno guadagnato l’attenzione dei leader dell’ Information Tecnology, dei venditori e degli analisti. L’Enterprise Service Bus (ESB) racchiude le caratteristiche migliori di tutte queste tecnologie.
Un ESB è generalmente progettato per permettere che applicazioni di diverso tipo si scambino messaggi con lo scopo di estendere le funzionalità di ciascuna applicazione con quelle fornite dalle altre applicazioni e di rendere virtuali le risorse aziendali, permettendo alla logica di business dell’azienda di essere sviluppata e gestita indipendentemente dall’infrastruttura della rete, e dalla fornitura di questi servizi.

Un ESB è un prodotto per l’integrazione basato su standard di mercato, che raccoglie le novità introdotte dallo stile architetturale orientato ai servizi e che fornisce le funzionalità tipiche dei tradizionali Integration Broker di cui ne rappresenta l’evoluzione, con due fondamentali differenze.
La prima è tecnologica: gli ESB espongono tramite standard quelle funzionalità che i tradizionali Integration Broker fornivano tramite tecnologie proprietarie. Esempi di standard ampiamente utilizzati sono: Java DataBase Connectivity (JDBC), Java Message Service (JMS), Web Services Description Language (WSDL) e altri.

La seconda differenza è architetturale: un ESB non si basa su un’architettura ‘monolitica’ di tipo Hub-and-Spoke, ma su di una architettura distribuita a bus condiviso SOA oriented. In altre parole, in un’infrastruttura ESB, tutte le applicazioni sono integrate e operano come servizi.
La logica d’integrazione non è più centralizzata in un hub, ma è distribuita lungo gli endpoint connessi al bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità ed è possibile effettuare il deploy delle funzionalità d’integrazione strettamente necessarie (selective-deployment).
L’utilizzo degli standard permette di ridurre le soluzioni proprietarie chiuse e costose tipiche dei tradizionali prodotti EAI riducendo l’acquisto di soluzioni proprietarie e i costi legati alle consulenze specialistiche e alle licenze.

Risulta evidente che l’aumento di interoperabilità dato dall’uso di protocolli e tecnologie standard, riduce i rischi aziendali dovuti dall’adozione di un middleware, rendendolo in teoria sostituibile. Ad esempio, se ESB utilizza i Web Services, è possibile disaccoppiare l’interfaccia del servizio (Web Services Description Language (WSDL)) dall’implementazione del servizio stesso.
L’ESB permette, in linea con le best practices SOA, un’integrazione ‘incrementale’: è possibile infatti integrare in momenti differenti le varie parti di un sistema attraverso un approccio cosiddetto Leave-and-layer: si lascia inalterato l’insieme dei servizi Legacy e di applicazioni esistenti riconciliando le loro differenze (logica e dati) in un nuovo layer (in questo caso, appunto, l’ESB). Gli ESB quindi, rispetto ai prodotti tradizionali di integrazione, dovrebbero ridurre i costi di licenze e manutenzione e permettere una maggiore garanzia di portabilità del codice e di interoperabilità. Ad oggi, praticamente quasi tutti i principali produttori di Software hanno realizzato o intendono realizzare un proprio prodotto ESB da proporre sul mercato.
Da un lato società che proponevano broker di integrazione tradizionali (per esesempio IBM e SeeBeyond) hanno affiancato alla loro suite d’integrazione anche dei prodotti ESB, dall’altro le società di dimensioni più limitate che proponevano sistemi di comunicazioni a messaggi hanno migliorato il loro prodotto aggiungendo nuove caratteristiche. Altri venditori hanno riadattato le loro integration suite effettuando di fatto una riproposizione del loro prodotto al fine di ridurre i costi (licenze e manutenzione), altri ancora hanno fornito una versione “light” del prodotto Integration Broker in veste di ESB.