Figura 1: Integration Middleware: architettura Hub-and-Spoke

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 in qualche misura interoperare.
In questo modo, tutte le problematiche/operazioni di integrazione (messaging, intelligent routing, data trasformation, data mapping, …) risultano essere centralizzate, riusabili e facilmente amministrabili.

Figura 2: Integration broker: centralizzazione delle funzionalità d'integrazione

I trade-off di un simile approccio, sono dati dal fatto che l'Hub rappresenta un potenziale "collo di bottiglia" (bottleneck), un potenziale "single point of failure" e presenta difficoltà a scalare.
Inoltre, gran parte delle suite di integrazione ad oggi sul mercato, sono state sviluppate in tempi in cui o non esistevano "standard" o questi non erano sufficientemente maturi e stabili. I fornitori Software, hanno così sviluppato soluzione proprietarie per risolvere le problematiche tipiche d'integrazione.
In questo modo, le suite EAI spesso forniscono tecnologie (API, script, motori di regole di trasformazione, composizione di processi, connettori proprietari, …) proprietarie per l'implementazione della logica di integrazione, non consentendo il riuso e l'interoperabilità tra differenti piattaforme.
Le competenze necessarie per lo sviluppo e la gestione di tali soluzioni EAI, sono quindi garantite quasi unicamente dal fornitore del Prodotto (vendor lock-in) con conseguente svantaggio tecnico ed economico (licenze, manutenzione e consulenze del prodotto).

La situazione è tale per cui, ad oggi, nella maggior parte dei casi, l'adozione di tali suite ha comportato: costi alti (licenze, manutenzione e consulenze), soluzioni proprietarie (vendor lock-in), mancanza di standard e difficoltà di scalabilità e di interoperabilità.

L'avvento degli ESB
In funzione della situazione appena descritta, il focus del seminario si è orientato sul tema Enterprise Service Bus.
Un Enterprise Service Bus (ESB) è un prodotto per l'integrazione basato su standard di mercato e su di un'architettura orientata ai servizi. Un ESB fornisce le funzionalità tipiche dei tradizionali EAI Broker con due fondamentali differenze.
La prima differenza è che, un ESB si basa su standard "ufficiali" o "de-facto", integrando standard EAI "tradizionali" (JDBC,JCA, JMS, JMX,…) con standard XML-based (WSDL, UDDI, SOAP, JAX-RPC, JAXM, JAXR, SSAJ, XQuery, XPath, JBI, BP4WLS, WS-*, …). Quindi un ESB fornisce con tecnologie basate su "standard", funzionalità che gli Integration Middleware offrivano in modo proprietario.
La seconda differenza è che un ESB non si basa su un'architettura "monolitica" di tipo Hub-and-spoke, ma su di una architettura distribuita, a bus condiviso SOA (Service Oriented Architecture) oriented. In altre parole, in un'infrastruttura ESB, tutte le applicazioni sono integrate ed operano come "servizi".

Figura 3: Architettura ESB

Le logica d'integrazione non è più centralizzata in un hub centrale, ma è distribuita lungo gli endpoint connessi al bus. Decentralizzando la logica di integrazione lungo il bus si migliora la scalabilità teorica ed è possibile effettuare il deploy delle funzionalità d'integrazione strettamente necessarie (selective-deployment).

Figura 4: ESB: scenario d'integrazione

Nella visione di Sonic, i vantaggi di un ESB sono molteplici: riduzione del vendor lock-in, riduzione dei costi, maggiore flessibilità, maggiore scalabilità ed interoperabilità del prodotto.
L'utilizzo degli standard permette di ridurre le soluzioni proprietarie chiuse e costose tipiche dei tradizionali prodotti EAI riducendo il vendor lock-in ed i costi legati alle consulenze specialistiche ed alle licenze.
Risulta poi evidente che l'aumento di interoperabilità dato dall'uso di protocolli e tecnologie standard, riduce i rischi aziendali complessivi indotti dall'adozione di un middleware (in teoria lo rende "sostituibile").
Utilizzando i Web Services, è possibile disaccoppiare l'interfaccia del servizio (WSDL) dall'implementazione del servizio stesso. Oltre a tale disaccoppiamento l'ESB permette di separare la logica del servizio, dalla logica di processo. In questo modo, le interdipendenze tra i servizi, non sono più implementate/cablate nei servizi. Ottenuti questi endpoint astratti e omogenei, è possibile "orchestrare" i servizi per ottenere veri "processi di business". Tutte le regole e le logiche di routing e trasformazione sono così gestite mediante configurazioni seguendo il mantra ESB di Sonic: "configure, don't code".

Figura 5: Configure, don't code

Nel contesto del seminario, è stato dato particolare rilievo al tema "integrazione incrementale". Un ESB consente infatti di integrare in momenti differenti le varie parti di un sistema attraverso un approccio Leave-and-layer. L'esempio presentato durante il seminario, mostra fasi successive di connessione all'ESB dei vari pezzi dell'architettura.

Figura 6: Integrazione incrementale

Nella visione di Sonic, tutti i principali produttori di Software hanno realizzato o intendono farlo un proprio prodotto ESB da proporre sul mercato. Dopo gli annunci "pionieristici" di Sonic, a ruota si sono susseguiti BEA, Cape Clear, Fiorano, IBM, Iona , SeeBeyond , SpiritSoft, webMethods , ecc…
Per Chappell quindi, i tradizionali Integration Middleware, sono da ritenersi già oggi "legacy".
Nell'esempio presentato infatti l'Integration Broker del comparto Back Office viene collegato all'ESB ed integrato alla stregua di prodotti Legaci come ERP, CRM e Host.

Intervista con Dave Chappell
Grazie alla cortese disponibilità degli organizzatore della Progress Software, ho avuto il piacere di scambiare due chiacchiere con Dave Chappell a fine seminario.

Stefano: SOA riguarda principi architetturali indipendenti da specifiche tecnologie e/o prodotti. Nel seminario hai spiegato come l'adozione di un ESB agevoli la realizzazione di un'architettura orientata ai servizi. Per la tua esperienza, l'adozione di un modello SOA e/o l'uso di prodotti ESB implica un'evoluzione dei processi e dell'organizzazione di un'azienda?

Dave: Assolutamente si, l'uso di architetture/prodotti orientati ai servizi, ha implicazioni culturali, organizzative e metodologiche all'interno dell'azienda.
Solo con un cambiamento culturale sarà possibile attuare il cambiamento tecnologico.
C'è ancora molto da imparare a livello organizzativo e metodologico per aiutare le organizzazioni ad applicare l'evoluzione culturale indotta dal cambiamento tecnologico.

Stefano: Durante il seminario, hai spiegato chiaramente i potenziali vantaggi che l'adozione di un ESB può offrire per integrare applicazioni eterogenee esterne. Per quanto riguarda invece le API del Framework ESB?
Ho letto, nel tuo articolo apparso su Web Services Journal (vedere [WSJ]), che una risposta "standard" potrebbe essere data da JBI, Java Business Interface (vedere [JBI]).
Questo vorrebbe dire che i servizi potrebbero essere sviluppati non con API proprietarie del vendor, ma con API standard che garantirebbero la portabilità dei servizi tra differenti prodotti ESB?

Dave: Ottima domanda. JBI cerca di definire un'infrastruttura condivisa e portabile per integrare i componenti.
JBI sta cercando di definire uno standard che consenta il deploy di componenti sviluppati da diversi vendor all'interno degli ESB. Questo vorrebbe dire potere scegliere il miglior componente per la specifica situazione (best of breed) d'integrazione purchè l'infrastruttura ESB sia JBI-compliant. Inoltre questo avverrebbe senza interventi sul codice, ma attraverso un meccanismo a plugin, eventualmente limitando gli interventi alla fase di configurazione.

Stefano: Come interpreti il fatto che IBM abbia deciso di "ritirarsi" dall'Expert Group e di non partecipare alla realizzazione delle specifiche JBI?

Dave: IBM non è interessata a partecipare alla creazione di uno scenario in cui sia possibile selezionare i migliori componenti caso per caso. Il loro focus è incentrato sulla famiglia di prodotti Websphere e quindi vendere servizi di consulenza e sviluppo IBM. Comunque, allo sviluppo di JBI si sono aggiunti altri membri importanti (ad es: Deutschland Post) che stanno collaborando in modo molto attivo.

Stefano: Se JBI dovesse essere promossa da JSR a specifica ufficiale, nei piani di Sonic c'è l'intenzione di adottarla?

Dave: Assolutamente si.

Stefano: Per la mia esperienza ho visto progetti che adottando un Integration Broker come prodotto di integrazione si sono trovati a dovere sostenere costi elevati per licenze e manutenzione nell'impossibilità di valutare alternative dato il vendor lock-in indotto dall'uso di API proprietarie. Come vedi in questi contesti la possibilità di un utilizzo di un ESB?

Dave: Non bisogna pensare che sia nostra intenzione sbarazzarsi di tutte le applicazioni e di tutti gli sviluppo fatti con Integration Broker, buttando via gli investimenti fatti.
In molti casi gli sviluppi fatti con IB hanno avuto successo e funzionano egregiamente.
Poichè ESB ti permette di collegarti alle "vecchie" applicazioni che utilizzano tecnologie Legacy, è possibile costruire una nuova architettura e farla convivere con il passato, eventualmente migrando per gradi verso un'unica soluzione. Credo che questa sia una grande opportunità per il Business.
In assenza di JBI ci potrebbe essere un proliferare di codice custom e, a nostro avviso, questo non è opportuno. Il nostro mantra è basato sulla configurazione piuttosto che sulla scrittura di codice.
In effetti qualcuno descrive JBI come un coltello svizzere per la definizione di interfacce standard.
Concludendo, anche se JBI si affermerà tra un anno o due, è comunque buona cosa iniziare a conoscerlo già da oggi.

Bibliografia
[SONIC] www.sonicsoftware.com
[ESB_DC] David A. Chappell: Enterprise Service Bus - O'Reilly 2004
[SONIC-ICON] Sonic Icon and Sonic Diagram Library -
http://www.oreilly.com/catalog/esb/esb_icons.csp
[WSJ] David A. Chappell: Reconstructing J2EE-Java. Business Integration Meets the Enterprise Serivce Bus - Web Services Journal (www.sys-con.com/webservices)
[JBI] JSR 208: JavaTM Business Integration (JBI) - http://www.jcp.org/en/jsr/detail?id=208
[PROGRES] Per qualunque contatto commerciale per Sonic ESB fare riferimento a Progress Software Italy (http://www.progress.com)