Enterprise Service Bus (ESB) come supporto ad architetture Service-Oriented (SOA)

Enterprise Service Bus (ESB) come supporto ad architetture Service-Oriented (SOA)

Con le architetture orientate ai servizi, il patrimonio informativo aziendale non è più un insieme di applicazioni tra loro isolate e che comunicano attraverso tecnologie d’integrazione di applicazioni, è, invece, organizzato in una collezione di “servizi” intesi come funzionalità di business realizzate tramite “componenti” che rispettano un’interfaccia standard.
La Service-Oriented Architecture promette notevoli miglioramenti nell’allineamento dell’Information Technology (IT) con le esigenze aziendali ma necessita di un’infrastruttura in grado di connettere le risorse IT indipendentemente da dove siano implementate, in particolare, necessita di un’infrastruttura che offra flessibilità e affidabilità, in grado di riassemblare facilmente i servizi senza interruzioni.

Quest’infrastruttura è l’Enterprise Service Bus (ESB). Un ESB è un’infrastruttura software che opera tra le applicazioni ed il sistema operativo (middleware) e che fornisce servizi di supporto ad architetture Service-Oriented (SOA). Il compito principale di un ESB è fornire un layer di comunicazione tra i servizi, coerentemente con i principi architetturali SOA, e permettere l’invocazione dei servizi su sistemi eterogenei, risolvendo problematiche legate all’integrazione come per esempio il supporto a chiamate sincrone e asincrone basate su messaggi, il routing intelligente dei messaggi, trasformazione e validazione dei dati, integrazione con diversi protocolli, gestione dell’affidabilità e sicurezza. È facile, quindi, osservare che queste funzionalità si sovrappongono parzialmente a quelle fornite usualmente dai tradizionali middleware di integrazione da cui, in parte, derivano.

Enterprise Service Bus (ESB) come supporto ad architetture Service-Oriented (SOA)

Per comprendere pienamente i vantaggi forniti dagli ESB, occorre partire dalle differenze che questi presentano rispetto ai tradizionali sistemi di integrazione basati sull’utilizzo di un middleware, di cui rappresentano un’evoluzione in senso SOA.
In tali architetture denominate Hub-and-Spoke (cosiddetto “a stella”), le operazione di routing dei messaggi e trasformazione dei dati sono centralizzate nell’Hub e svolte dall’Integration Broker, il componente centrale del sistema di integrazione.
Da un punto di vista architetturale, l’Integration Broker rappresenta l’interfaccia unica attraverso cui transita ogni richiesta di comunicazione tra sistemi applicativi disomogenei che devono interoperare.
In questo modo, tutte le problematiche e le operazioni di integrazione risultano essere centralizzate, riusabili e facilmente amministrabili.

Gli svantaggi di un simile approccio nascono dal fatto che l’hub rappresenta un potenziale collo di bottiglia, un potenziale single point of failure e presenta difficoltà di scalabilità. Inoltre, gran parte delle suite di integrazione presenti sino ad oggi sul mercato sono state sviluppate in tempi in cui o non esistevano “standard” per la definizione dei processi operativi o dello scambio dati, oppure questi non erano sufficientemente maturi e stabili.
I fornitori software hanno così sviluppato soluzione proprietarie per risolvere le problematiche tipiche dell’integrazione.
Il risultato di tale investimento da parte dei fornitori dell’Enterprise Application Integration (EAI) erano software altamente funzionali ma terribilmente costosi e non flessibili. Anche oggi, questo tipo di software richiede un’elevatissima tassa di licenza e un investimento in servizi di consulenza cinque volte superiore rispetto alla tassa di licenza software, per assicurarne il funzionamento. In molti casi, le competenze necessarie per lo sviluppo e la gestione di tali soluzioni EAI sono quindi garantite quasi unicamente dal fornitore del prodotto: vi è quindi un chiaro svantaggio tecnico ed economico dovuto non solo al costo delle licenze, ma soprattutto alle necessità per la manutenzione e la consulenza sul prodotto. In passato, l’adozione di tali suite ha comportato problemi in termini di costi, manutenzione e interoperabilità.

Con l’avvento degli Standard Internet vengono descritti come i sistemi informatici debbano connettersi gli uni agli altri, la semantica delle conversazioni tra questi e come i dati debbano essere rappresentati in tali conversazioni ed è proprio tutto questo che ha cambiato il mondo della EAI.
Il software EAI comincia ad essere progettato e sviluppato in modo da utilizzare questi standard ad un costo minore rispetto alle soluzioni
proprietarie. Lavorare con questa nuova generazione di software significa semplicemente ricercare gli standard opportuni e decidere la migliore modalità di implementazione in ambito aziendale.

Pubblicato da Vito Lavecchia

Lavecchia Vito Ingegnere Informatico (Politecnico di Bari) Email: [email protected] Sito Web: www.vitolavecchia.altervista.org

Lascia un commento

Il tuo indirizzo email non sarà pubblicato. I campi obbligatori sono contrassegnati *