ESB (Enterprise Service Bus)

Sto approfondendo il tema degli ESB (Enterprise Service Bus): probabilmente il più noto tra i software legati a SOA (Service Oriented Architecture), spesso identificato come l’INFRASTRUTTURA su cui fondarla.

Scorrendo libri ed articoli che trattano l’argomento (in fondo ne trovate un’essenziale selezione) si trovano giudizi contrastanti: chi lo ritiene indispensabile, chi lo considera inutile se non dannoso, chi ne argomenta un compromesso; addirittura non risultano totalmente concordanti nemmeno le definizioni che ciascun produttore ne fornisce (come Nicholas Allen’s Indigo Blog ha potuto constatare).

Personalmente posso definire l’ESB come un’evoluzione, in ottica SOA, dei prodotti per EAI (Enterprise Application Integration): una piattaforma di integrazione che eredita pattern e best practice da questi software che l’hanno preceduta e vi aggiunge gli standard WS-* (semplificando, senza entrare in particolari quali: composizione, affidabilità, distribuzione delle intermediazioni e delle configurazioni, …).

In particolare, un ESB solitamente offre:

• Standard WS-* (WS-Addressing, WS-Security, WS-ReliableMessage, …)

• Adattatori verso un certo numero di “protocolli legacy” (Flat file, FTP, Tibco RV, ecc. ecc.)

• Oggetti preconfezionati per applicare, tra gli altri, il pattern VETRO (Validate, Enrich, Transform, Route and Operate)

• SDK (Software Development Kit) per sviluppare ciò che non è direttamente fornito dal produttore

• Assetti ottimizzati per la produzione (affidabilità, distribuzione delle intermediazioni e delle configurazioni, …)

Un ESB, quindi, ha l’obiettivo di rendere accedibile mediante standard WS-* ciò che non lo è, contemporaneamente mediando sui formati, permettendo così di inserire nell’architettura SOA servizi “estrapolati” da applicazioni originariamente accedibili solo mediante “protocolli legacy”.

Visto che Gartner considera l’integrazione di sistemi come una irrinunciabile necessità per SOA e prevede che il 70% dei prossimi servizi saranno ottenuti da applicazioni esistenti (e c’è chi è convinto che questa percentuale corrisponderà addirittura al 80-90%), facilmente si è tentati a concludere che l’adozione di un ESB sia indispensabile (tenendo anche conto del fatto che, ancora Gartner, consiglia di far risiedere la responsabilità dello sviluppo dei servizi nel centro di competenza per l’integrazione, qualora l’azienda lo preveda).

Il problema esiste (in questa fase SOA non è assolutamente “togli e sostituisci” ma, piuttosto, “incapsula e riusa”) e l’ESB è uno dei modi per risolverlo.

Come detto l’ESB offre oggetti preconfezionati con cui applicare il pattern VETRO: la mediazione sui trasporti, sui formati e sui dati tra ciò che l’ESB espone mediante interfacce standard e ciò che prevede il “protocollo legacy”. E’ chiaro, il tema dell’integrazione è vastissimo e non si può pretendere che ogni casistica sia prevista (o prevedibile): ciò che l’ESB offre nativamente copre una certa percentuale delle situazioni, il resto è coperto dall’utilizzo del SDK, magari applicando le modifiche ad un oggetto fornito dal produttore, risparmiando così tempo nello sviluppo.

Benché l’ESB costituisca un notevole passo avanti rispetto ai prodotti EAI non risolve totalmente il problema del vendor lock-in, questo è ciò che gli si imputa: le configurazioni sono del tutto proprietarie, una volta investito tempo e denaro nel prodotto è difficile buttar via tutto ed adottare qualche altra soluzione; il vendor lock-in, grazie agli standard WS-*, è risolto solo oltre il bordo dell’ESB.

L’altra osservazione che si fa consiste nel fatto di aver spostato il “groviglio degli spaghetti” all’interno dell’ESB, che questo continuerà a crescere e, in breve tempo, per una serie di cause, finirà col ripresentarsi anche all’esterno del prodotto (si veda ad esempio Jim Webber – Guerrilla SOA).

Inutile negarlo, il problema esiste, le soluzioni non sono molte, tutte riconducibili al solito dilemma “make or buy”: acquisto di un ESB o qualcosa più “semplice”? Adozione di librerie che assicurano gli standard (ad esempio WSIT) e sviluppo della mediazione necessaria?

Probabilmente la soluzione risiede (come spesso accade) nel mezzo:

• Benché l’ESB, come detto, non possa fornire risposte esaustive al problema dell’integrazione è un buon punto di partenza specie per quelle aziende che non dispongono di un folto personale IT. D’altro canto l’ESB non è assolutamente indispensabile per costruire una SOA: i servizi innanzitutto, le tecnologie abilitanti poi (l’ESB è solo uno dei modi per conseguirle).

• L’ESB potrebbe prevedere molte più funzionalità oltre quelle realmente necessarie, il rischio è quello di pagare anche quello che non sarà mai usato: meglio scegliere una soluzione progettata a componenti (incrementabili nel numero al crescere delle reali necessità o decrementabili al diminuire) o una soluzione più “modesta”. L’ESB o qualcosa di più “semplice”, da questo punto di vista, potrebbero essere più versatili di una soluzione “make” anche se ben progettata.

• Tutte queste soluzioni introducono un livello di disaccoppiamento: ma l’ESB o la sua versione “semplificata”, anche da questo punto di vista, potrebbero rivelarsi più versatili.

• Il rischio del vendor lock-in c’è, inutile nasconderlo: limitarsi ad usare l’ESB come fornitore di tecnologia abilitante dove e quando è necessario, non attestandovi ciò che già dispone dei necessari standard (probabilmente perché di recente fattura e ben progettato), impiegandolo, quindi, come un mediatore tra il “protocollo legacy” e l’interfaccia standard, usando quest’ultima come “bus”.

—-><—-

Oltre alla forma dei tradizionali pacchetti commerciali, gli ESB iniziano ad essere commercializzati on-demand come SaaS (Software as a Service) o come appliance hardware che promettono performance superiori nella manipolazione del XML (in particolare XSLT e XQuery).

—-><—-

Sullo stesso argomento:

• David A. Chappell – Enterprise Service Bus – O’Reilly
• SOA Evolution – ESB or not ESB?
• IBM developerWorks: Why the ESB is a fundamental part of SOA
• Jim Webber – Guerrilla SOA
• Steve Vinoski’s Blog – The ESB question
• Making it stick – More on the ESB

—-><—-

Ulteriore materiale:

• Anil John’s Blog – ESB in a SOA Infrastructure
• Dinkatron – SOA and ESB’s – cue backlash
• The Service Oriented Architecture (SOA) Blog – How to use ESBs for SOA
• MyArch – Is ESB the Starting Point for SOA?

—-><—-

Hai trovato questo post interessante? Sottoscrivi il feed completo e partecipa alla discussione