ESB (Enterprise Service Bus)

menu icon

ESB (Enterprise Service Bus)

In questa guida troverai informazioni sull'ESB (un componente essenziale della SOA), i vantaggi che fornisce e come si collega all'architettura di microservizi.

Cos'è un ESB (Enterprise Service Bus)?

Un ESB, o Enterprise Service Bus, è un modello in cui un componente software centralizzato esegue le integrazioni ai sistemi di backend (e le conversioni dei modelli di dati, la connettività profonda, l'instradamento e le richieste) e rende queste integrazioni e conversioni disponibili come interfacce di servizio per il riutilizzo da parte di nuove applicazioni. Il modello ESB viene generalmente implementato utilizzando un toolset e un runtime di integrazione progettati appositamente per garantire la migliore produttività possibile.

ESB e SOA

Un ESB è un componente essenziale della SOA (service-oriented architecture), un'architettura emersa alla fine degli anni '90 del secolo scorso. La SOA definisce un modo per rendere i componenti software riutilizzabili tramite le 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 le integrazioni di codice e dati necessarie per eseguire una funzione di business discreta e completa (ad es. il controllo del credito di un cliente, il calcolo della rata mensile di un finanziamento o l'elaborazione di una richiesta di mutuo). 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 systems of record legacy come interfacce di servizio. È qui che nasce la necessità di un ESB. I sistemi legacy e i systems of record generalmente utilizzano vecchi protocolli e formati di dati proprietari che devono essere convertiti e integrati per funzionare con i protocolli di rete SOA. Un ESB esegue queste conversioni e integrazioni istantaneamente. Si potrebbe implementare una SOA senza un ESB, ma i proprietari di applicazioni dovrebbero ognuno trovare un loro modo unico per esporre le interfacce di servizio, e questo si traduce in molto lavoro (anche se le interfacce sono alla fine riutilizzabili) e crea una significativa sfida di manutenzione in futuro.

Per saperne di più sulla SOA e sul ruolo di un ESB al suo interno, consulta "Introduction to SOA (Service-Oriented Architecture)".

Vantaggi

In teoria, un ESB centralizzato offre il potenziale per standardizzare, e semplificare drasticamente, le comunicazioni e l'integrazione dei servizi in tutta l'azienda. I costi di hardware e software possono essere condivisi, il provisioning dei server deve essere effettuato solo una volta e un singolo team di specialisti può essere incaricato (e, se necessario, formato) per sviluppare e mantenere le integrazioni.

Gli sviluppatori possono utilizzare un singolo protocollo per 'comunicare' con l'ESB ed immettere i comandi che indirizzano le interazioni tra i servizi e lasciare che l'ESB converta i comandi, instradi i messaggi e trasformi i dati come necessario affinché i comandi vengano eseguiti. Questo consentirebbe agli sviluppatori di dedicare decisamente meno tempo all'integrazione e molto più tempo alla configurazione e al miglioramento delle loro applicazioni. La capacità poi di riutilizzare queste integrazioni da un progetto al successivo ha offerto il potenziale per aumenti della produttività e risparmi a valle ancora maggiori.

Tuttavia, mentre gli ESB venivano implementati con successo in molte organizzazioni, in altre organizzazioni l'ESB iniziava ad essere visto come il collo di bottiglia nell'implementazione della SOA. Apportare modifiche o miglioramenti ad una integrazione spesso destabilizzava le altre. Gli aggiornamenti al middleware ESB spesso si ripercuotevano sulle integrazioni esistenti. Poiché l'ESB era gestito centralmente, i team delle applicazioni si ritrovarono ben presto ad attendere pazientemente per le loro integrazioni. Mentre il volume delle integrazioni cresceva, l'implementazione di alta disponibilità e disaster recovery per i server ESB diventava più costoso. Come progetto interaziendale, poi, l'ESB si è rivelato difficile da finanziare, rendendo queste sfide tecniche ancora più difficili da risolvere.

Alla fine, le sfide rappresentate dal mantenere, aggiornare e ridimensionare un ESB centralizzato si sono rivelate così soverchianti e costose che l'ESB spesso ritardava quegli stessi aumenti della produttività che, insieme alla SOA, doveva generare, frustrando i team delle LOB (line of business) che avevano previsto un ritmo di innovazione maggiore.

Per approfondire l'ascesa e la caduta dell'ESB, leggi "The fate of the ESB".

Confronto tra ESB e microservizi

L'architettura di microservizi consente di suddividere i componenti interni di una singola applicazione in piccole parti che possono essere modificate, ridimensionate e amministrate in modo indipendente. I microservizi sono emersi e si sono diffusi sempre di più con l'ascesa di virtualizzazione, cloud computing, pratiche di sviluppo Agile e DevOps. In questi contesti, i microservizi offrono quanto segue:

  • Agilità e produttività degli sviluppatori migliorate, consentendo agli sviluppatori di integrare nuove tecnologie in una singola parte di un'applicazione senza toccare o 'recuperare' il resto dell'applicazione.
  • Scalabilità più semplice e più efficiente in termini di costi, consentendo di ridimensionare qualsiasi componente in modo indipendente l'uno dall'altro, per la più veloce risposta possibile alle esigenze dei carichi di lavoro e l'uso più efficiente delle risorse di calcolo.
  • Maggiore resilienza, poiché il malfunzionamento di un singolo componente non si ripercuota sugli altri componenti e ogni microservizio posssa eseguire le sue richieste di disponibilità senza vincolare gli altri componenti a un requisito di "più grande disponibilità comune".

La stessa granularità che i microservizi portano alla progettazione delle applicazioni può essere portata all'integrazione, con vantaggi simili. Questa è l'idea alla base dell'integrazione agile, che suddivide l'ESB in componenti di integrazione decentralizzati, e particolareggiati, senza interdipendenze, che i singoli team delle applicazioni possono possedere o gestire autonomamente.

Per approfondire i temi relativi ai microservizi, consulta “Microservices: A Complete Guide,” "SOA vs. Microservices: What's the difference?" e guarda il video di Dan Bettinger, “What are Microservices?”:

ESB e IBM Cloud

Man mano che la tua azienda sposta la sua infrastruttura IT verso un approccio di cloud ibrido, è molto probabile che trasformerai una serie di carichi di lavoro, compresi quelli basati su modelli ESB e SOA, verso modelli di implementazione più leggeri e flessibili. Queste trasformazioni sono solo una parte della modernizzazione delle applicazioni nel percorso verso il cloud di qualsiasi organizzazione.  

Passa alla fase successiva:

  • Scopri come puoi sfruttare, estendere e modernizzare i tuoi investimenti nel middleware con IBM Cloud Pak for Integration.
  • Scopri come puoi connettere tutte le tue applicazioni e tutti i tuoi dati su più cloud pubblici e privati per esperienze cliente personalizzate visitando IBM Cloud Integration.

Inizia con un account IBM Cloud oggi stesso.