Cominciamo con questo articolo una nuova serie con lo scopo di illustrare le soluzioni di integrazione applicativa. È un argomento che in passato è stato diffusamente trattato su queste pagine. Lo riprendiamo fornendo alcune indicazioni teoriche che saranno completate nell’ultima parte della serie presentando un esempio implementato su un ESB open source. Il tema di questa prima parte è l’evoluzione di queste architetture.

La necessità di integrare 

Il tema della prima parte di questa serie è l’evoluzione delle cosiddette architetture di integrazione. Passeremo in rassegna le soluzioni adottate, partendo da quelle meno flessibili (dove l’integrazione è stata risolta adeguando con specifiche implementazioni le applicazioni coinvolte) fino ad arrivare a  quelle più flessibili che, basate sull’introduzione dell’Enterprise Service Bus (ESB),  non determinano impatti nè sulle soluzioni applicative realizzate nè sulla topologia di integrazione realizzata.

Il concetto di ESB, Enterprise Service Bus, può essere paragonato al BUS, il sistema di comunicazione che trasferisce i dati tra i componenti di un calcolatore (la CPU, la memoria e i dispositivi di input-output). L’analogia deriva dal fatto che, come per il BUS di un elaboratore, il concetto di base dell’ESB è quello per cui le soluzioni applicative possono  essere collegate e scollegate, accese e spente sulla rete, in modo semplice e senza determinare impatti su eventuali altre soluzioni applicative o componenti  e senza il bisogno di riavviare i sistemi o fermare l’esecuzione delle applicazioni. In questo senso l’ESB nasce dalla necessità di individuare un concetto standard, strutturato, ma nello stesso tempo generico, che descrive l’implementazione di componenti software, caratterizzati da un forte livello di disaccoppiamento e immaginati come servizi potenzialmente distribuibili su sistemi diversi ed eseguibili in rete in modo indipendente.

Standard… indefinito

Nei fatti, non si è mai giunti a una definizione univoca di questo standard.  In un recente passato caratterizzato da una significativa domanda di sistemi di middleware per la SOA (Service Oriented Architecture), sul mercato sono apparsi prodotti che hanno cercato di realizzare un ESB attraverso il riadattamento  in sistemi di code di soluzioni preesistenti orientate agli eventi e ai messaggi. Un ulteriore aspetto di confusione è stato introdotto da alcuni vendor che, attraverso  la ri-etichettatura sotto forma di sistemi di integrazione ESB, hanno offerto  soluzioni software di comunicazione senza che queste implementino in senso stretto il paradigma dell’ESB.  È vero infatti che l’ESB non realizza di per sè le architetture orientate ai servizi, ma fornisce gli strumenti necessari alla realizzazione di una SOA, come il disaccoppiamento o la messaggistica asincrona.

L’idea dell’integrazione applicativa basata su un  ESB è che ogni  consumatore di servizi indirizzi tutte le sue richieste attraverso questo middleware, piuttosto che risolvere direttamente  l’end-point di effettiva erogazione. Questa caratteristica di “indirezione” consente all’ESB di intervenire nello scambio di messaggi sovrascrivendo  le regole di comunicazione, il contenuto ed eseguendo  attività di monitoraggio  e registrazione del traffico. In questo senso un ESB abilita l’integrazione applicativa in modo consistente e senza che sia necessario riscrivere o modificare le soluzioni applicative già realizzate, sviluppate spesso da organizzazioni diverse in tempi diversi, e che eventualmente siano in comunicazione su protocolli eterogenei. Un ESB è in grado di esporre queste applicazioni come servizi, facendosi carico dell’indirizzamento dei messaggi e della eventuale trasformazione dei protocolli. In questo senso, ogni ESB deve disporre di servizi di indirizzamento dei messaggi e di trasformazione di dati in termini di compressione, crittografia, suddivisione in segmenti più piccoli, filtro e re-indirizzamento in relazione al  contenuto.

Architetture di integrazione

In relazione alla soluzione espressa, le  architetture di integrazione possono essere classificate in:

• integrazioni basate su soluzioni “Punto-Punto”;
• integrazioni basate su soluzioni “Hub & Spoke” o “Message Broker”;
• integrazioni basate su “Enterprise Message Bus”;
• integrazioni basate su “Enterprise Service Bus”.  

Integrazioni bastate su soluzioni “Punto-Punto”

Le soluzioni di integrazione applicativa Punto-Punto sono state le prime a essere applicate. Si tratta di una integrazione a coppie di applicazioni, dove i corrispondenti end-point possono essere integrati con l’implementazione di protocolli, adattatori o trasformatori di formato a uno o a entrambi i terminali. Si tratta quindi di una modalità di integrazione molto semplice, fin tanto che il numero di terminali da integrare sia ridotto. La figura 1 rappresenta un esempio di integrazione “punto-punto”.

Figura 1 – Integrazione di tipo “Punto-Punto”.

Soluzioni “Hub-and-Spoke” o “Message Broker”

Le  architetture Hub &  Spoke o Message Broker, anche se simili a quelle Punto-Punto sono però caratterizzate da un intermediario, un hub centralizzato, al quale tutte le applicazioni sono connesse attraverso dei connettori applicativi che realizzano l’integrazione senza, o al più con minimi, adeguamenti delle applicazioni esistenti.

All’interno dello hub viene realizzata la trasformazione e l’indirizzamento dei messaggi, in un contesto migliorativo rispetto alle soluzioni “punto-punto”, in quanto l’integrazione viene realizzata riducendo il numero di connessioni richieste. Questo in ragione del fatto che le applicazioni non sono tra loro direttamente connesse; ciascuna quindi può essere eliminata dalla topologia attraverso la corrispondente dissociazione sull’hub, caratteristica di isolamento che riduce le eventuali rotture nel set-up di integrazione.

Un importante limite di questa modalità di integrazione rispetto alle soluzioni “punto-punto” è  nella stessa natura centralizzata dello hub che, in quanto singolo punto di errore, rappresenta un elemento di rischio difficilmente accettabile in un contesto  aziendale critico e complesso. Un fault dello hub determinerebbe un fault dell’intera topologia. Questa criticità potrebbe essere mitigata implementando architetture clusterizzate dove lo hub sia ridondato in un gruppo logico di istanze multiple in esecuzione simultanea. Il clustering rappresenta però una soluzione di fault tolerance solo laddove si è in grado di centralizzare il controllo di tutte le istanze dello hub. Riportiamo in figura 2 un esempio di integrazione Hub &  Spoke.

Figura 2 – Integrazione di tipo “Hub-and-Spoke”.

Integrazione basata su “Enterprise Message Bus”

Mentre l’architettura Hub &  Spoke utilizza dei connettori applicativi per l’integrazione reciproca delle applicazioni attraverso uno hub centrale, l’Enterprise Message Bus rappresenta un modello in cui le applicazioni si integrano a vicenda in maniera disaccoppiata, in modo che possano essere facilmente aggiunte o rimosse senza influenzarsi reciprocamente. Un enterprise message bus fornisce infatti una infrastruttura di comunicazione comune, che funge da adattatore neutro rispetto alla piattaforma e indipendente dalla lingua delle applicazioni.

Questa infrastruttura di comunicazione potrebbe essere anche integrata da un router di messaggi e/o da canali Publish/Subscribe in modo tale da abilitare l’interazione  reciproca delle applicazioni attraverso il bus dei messaggi con l’aiuto di code request–response. Se un’applicazione consumer vuole invocare un servizio specifico di un diverso provider applicativo, allora pone un messaggio di richiesta opportunamente formattato sulla coda di richieste per tale servizio. Si  mette quindi in ascolto del  messaggio di risposta sulla coda di risposta del servizio. Il fornitore applicativo ascolta la richiesta sulla coda delle richieste del servizio, esegue il servizio, e quindi invia la risposta alla coda di risposta del servizio.

Come rappresentato di seguito, esiste la possibilità che le applicazioni usino degli adattatori attraverso i quali gestire scenari particolari, come per esempio l’invocazione di transazioni CICS. Un adattatore del genere fornisce servizi di connettività tra le applicazioni e il message bus attraverso l’uso di API applicative e API proprietarie del message bus .

Figura 3 – Integrazione basata su “Enterprise Message Bus”.

Integrazione basata su “Enterprise Service Bus”

Un Enterprise Service Bus è caratterizzato da una  topologia di integrazione distribuita e realizza, attraverso una pila di livelli tecnologici, un bus di integrazione applicativa basata su tecnologie WSDL, sull’utilizzo quindi di  formati XML per la traduzione e la trasformazione dei messaggi. In un contesto simile, le applicazioni si integreranno tra loro non direttamente ma attraverso questo middleware, che ha a disposizione i servizi necessari a realizzare funzionalità di integrazione. Questi servizi si trovano nel cuore dell’architettura dell’ESB e al di sopra di essi le applicazioni appoggiano i propri messaggi per essere opportunamente indirizzati e trasformati. In analogia con l’architettura “Hub &  Spoke”, le applicazioni si connettono all’ESB attraverso dei connettori astratti e intelligenti.

I connettori sono astratti nel senso che definiscono i protocolli di connettività, di trasporto e le interfacce dei servizi, ma non i dettagli di effettiva implementazione.  Possono essere considerati intelligenti per il fatto che sono dotati di logica integrata all’ESB per realizzare il collegamento selettivo dei servizi a run-time. Quest’ultimo aspetto rappresenta un elemento di efficienza in quanto abilita i consumatori di servizi al late-binding e alla scelta differita del servizio da invocare.

Figura 4 – Integrazione attraverso “Enterprise Service Bus” (ESB).

I prerequisiti di un ESB

Riportiamo di seguito le caratteristiche e funzionalità che deve realizzare una piattaforma di integrazione affinchè possa realizzare un ESB :

1. indirizzamento e instradamento
2. elaborazioni in modalità sincrona e asincrona
3. possibilità di definire il protocollo di trasporto
4. trasformazione del contenuto dei messaggi
5. orchestrazione di processi applicativi
6. elaborazioni basate sugli eventi
7. adattatori per l’integrazione di piattaforme multiple
8. integrazione con strumenti di progettazione, sviluppo e distribuzione
9. servizi che garantiscono transazionalità,  sicurezza e persistenza
10. servizi di verifica, registrazione e misurazione
11. servizi di gestione e di monitoraggio

Conclusioni

In questa prima parte abbiamo illustrato brevemente le caratteristiche delle architetture di integrazione applicativa. Abbiamo messo in luce come l’ESB rappresenti la soluzione che supera i limiti delle altre architetture. Nella prossima parte entreremo nei dettagli dell’ESB e di una sua implementazione open source: quella del progetto SwitchYard di JBoss.

Riferimenti

[1] Binildas C. A., “Enterprise Service Bus integration solutions for Java developers”, Packt Publishing, 2008

http://www.amazon.com/Service-Oriented-Java-Business-Integration/dp/1847194400

Luigi Bennardis

Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’Università di Roma. Si occupa di informatica da un po’ di tempo ed è attualmente impegnato su tematiche DevOps. Nel tempo libero ancora gioca a basket, nuota ed è appassionato di elettronica vintage.