Un  ESB, o  enterprise service bus, è un modello architettonico in cui un componente software centralizzato esegue l'integrazione tra le applicazioni.  Esso esegue trasformazioni  di modelli di dati, gestisce  la connettività, esegue l'instradamento  dei messaggi, converte i protocolli di comunicazione e gestisce potenzialmente la composizione di richieste multiple. L' ESB  può rendere queste integrazioni e trasformazioni  disponibili come interfaccia di servizio per il riutilizzo da parte di nuove applicazioni. 

Il modello  ESB  viene generalmente implementato utilizzando un toolset e un  runtime  di integrazione (prodotto  esb ) progettati appositamente per garantire la migliore produttività possibile.

Un  ESB  è un componente essenziale della  SOA  (service-oriented architecture), un' architettura software emersa alla fine degli anni '90. La SOA  definisce un modo per rendere i componenti software riutilizzabili tramite le interfacce di servizio. Questi servizi generalmente utilizzano interfacce standard ( servizi Web) in modo tale da poter essere rapidamente incorporati in nuove applicazioni senza dover duplicare la  funzione  svolta dal servizio in nuove applicazioni.

Ogni servizio in una  SOA  incorpora il codice e i  dati  necessari per eseguire una funzione aziendale completa e discreta (ad esempio, il controllo del credito del cliente, il calcolo del pagamento di un prestito mensile o l'elaborazione di un'applicazione ipotecaria). Le interfacce di servizio forniscono un legame debole, il che significa che possono essere chiamate con poca o nessuna conoscenza del modo in cui il servizio  è implementato, riducendo le dipendenze tra le applicazioni. Le applicazioni che sono dietro l'interfaccia di servizio possono essere scritte in  Java,  Microsoft .Net, Cobol o qualsiasi altro linguaggio di programmazione, fornite come applicazioni software in package da un fornitore (ad esempio,  SAP), applicazioni  SaaS  (come, ad esempio, Salesforce  CRM), oppure ottenute come applicazioni  open source .  

Le interfacce di servizio sono spesso definite usando WSDL ( Web Service  Definition Language), una struttura tag standard basata su  xml  (extensible markup language).  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. La governance dei servizi controlla il ciclo di vita per lo sviluppo e nella fase appropriata i servizi sono pubblicati in un registro  che permette agli sviluppatori di trovarli rapidamente e di riutilizzarli per assemblare nuove applicazioni o  processi aziendali.

I servizi possono essere creati da zero, ma spesso vengono creati esponendo funzioni da  sistemi di record legacy  esistenti. Le aziende possono scegliere di fornire un'interfaccia di servizio basata su standard davanti ai  sistemi legacy, utilizzare  ESB  per collegarsi direttamente al  sistema legacy  attraverso un  adattatore  o un  connettore oppure l'applicazione può fornire la propria  API. In ogni caso,  l' ESB  protegge la nuova applicazione dall'interfaccia legacy. Un  ESB  esegue la trasformazione e l' instradamento  necessari per la connessione al servizio del  sistema legacy .

E' possibile implementare una  SOA  senza un'architettura  ESB , ma questo sarebbe equivalente ad avere solo un mucchio di servizi. Ogni proprietario di un'applicazione dovrebbe connettersi direttamente a qualsiasi servizio di cui ha bisogno ed eseguire le  trasformazioni di dati  necessarie per soddisfare ciascuna delle interfacce di servizio. Si tratta di una grande quantità di lavoro (anche se le interfacce sono riutilizzabili) e crea una significativa sfida di manutenzione in futuro, dato che ogni connessione è di tipo point to point.

In teoria, un  ESB  centralizzato offre il potenziale per standardizzare, e semplificare drasticamente, le comunicazioni,  la messaggistica e l'integrazione tra servizi in tutta l'azienda. I costi di hardware e software possono essere condivisi, eseguendo il provisioning dei server come necessario per l'utilizzo combinato, offrendo una soluzione centralizzata scalabile.  Un singolo team di specialisti può essere incaricato (e, se necessario, formato) di sviluppare e mantenere le integrazioni.

Le applicazioni software  semplicemente si collegano ('parlano') all' ESB  e lasciano all' ESB  il compito di trasformare i protocolli, instradare i messaggi e trasformarli nei  formati di dati  richiesti fornendo l'interoperabilità per eseguire le transazioni. L'approccio architettonico  ESB  supporta scenari per l' integrazione delle applicazioni,  l'integrazione dei dati e l'automazione  dello stile di  orchestrazione del servizio  dei  processi  aziendali.  Questo consente agli sviluppatori di dedicare decisamente meno tempo all'integrazione e molto più tempo  alla distribuzione configurazione e al  miglioramento delle proprie 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. Apportare modifiche o miglioramenti a una integrazione potrebbe destabilizzare gli altri  che usavano quella stessa integrazione. Gli aggiornamenti al  middleware  ESB  spesso avevano impatto sulle integrazioni esistenti,  quindi era necessaria una significativa attività di test per eseguire qualsiasi aggiornamento. Poiché  l'ESB  era gestito centralmente, i team delle applicazioni si ritrovarono ben presto ad attendere in linea per le loro integrazioni. Con l'aumento del volume delle integrazioni, l'implementazione di alta disponibilità e disaster recovery per i server  ESB  diventava più costosa. Inoltre, come progetto interaziendale, 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 un approfondimento sull'ascesa e sulla caduta dell' ESB, leggi "The fate of the ESB."

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 hanno guadagnato terreno con l'aumento di  virtualizzazione,  cloud computing, pratiche di sviluppo Agile e  DevOps. In questi contesti, i  microservizi  offrono quanto segue:

• Produttività e agilità degli sviluppatori migliorata  consentendo agli sviluppatori di incorporare nuove tecnologie in una parte di un'applicazione senza toccare o 'recuperare' le altre parti dell'applicazione. 
• Scalabilità più semplice  ed economica , consentendo di ridimensionare qualsiasi componente in modo indipendente dagli altri, per una risposta più rapida 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 ha impatto sugli altri e ogni  microservizio  può 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 implementata nell'integrazione, d 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 un approfondimento su tutto ciò che riguarda i  microservizi, consultare "Microservizi: una guida completa," "SOA  e Microservizi: qual è la differenza?" e guarda il video di Dan Bettinger, "Cosa sono  i Microservizi?":

Man mano che la tua azienda sposta la sua infrastruttura IT verso un approccio di  hybrid cloud , è molto probabile che trasformerai una serie di carichi di lavoro, compresi quelli basati su modelli ESB e SOA, in modelli di implementazione più leggeri e flessibili.

Queste trasformazioni sono  solo una parte  della modernizzazione dell'applicazione,  in quanto la richiesta di migliori esperienze dei clienti e di un maggior numero di applicazioni hanno un impatto sul business e sulle operazioni IT. Quando si tratta di soddisfare tali esigenze, il passo verso una maggiore automazione può rendere tutto più semplice. Nel caso ideale, un passo verso una maggiore automazione deve iniziare con piccoli progetti di successo e misurabili, che puoi quindi ridimensionare e ottimizzare per altri processi e in altre parti della tua organizzazione.

Collaborando con IBM, avrai accesso alle funzionalità di automazione basate sull'AI, inclusi dei flussi di lavoro predefiniti per contribuire ad accelerare l'innovazione rendendo ogni processo più intelligente.

Entra nella fase successiva:

• Guarda come puoi sfruttare, estendere e modernizzare i tuoi investimenti nel middleware con IBM Cloud  Pack for Integration, una soluzione di integrazione ibrida che -fornisce un ciclo di vita automatizzato e a ciclo chiuso attraverso più stili di integrazione aziendale.
• Scopri come collegare tutte le tue applicazioni e i tuoi dati attraverso più cloud  privati  e pubblici per creare esperienze personalizzate per i clienti visualizzando le soluzioni di integrazione di IBM Cloud.
• Ottieni la Guida sul campo per la modernizzazione delle applicazioni IBM per scoprire come accelerare la modernizzazione, migliorare la produttività dello sviluppatore e perfezionare efficienza operativa e standardizzazione.
• Esegui la nostra valutazione sulla maturità dell'integrazione per esaminare il tuo livello di maturità dell'integrazione  in tutti gli ambienti critici e scoprire quali azioni intraprendere per passare al  livello successivo.
• Scarica la nostra guida all'integrazione agile, che descrive i vantaggi di un approccio decentralizzato, basato sui container e allineato ai microservizi per l'integrazione di soluzioni. 
• Leggi i cinque imperativi per un'automazione di successo (link esterno a IBM)  in questo report di HFS Research.

Inizia con un account IBM Cloud account oggi stesso.