Ovvero, perché un Esb estensibile è quanto serve per fare la vera integrazione di servizi e applicazioni.
In questo spazio (Techne – Con parole mie) i protagonisti della tecnologia raccontano e si raccontano, portando alla luce la miscela virtuosa di tecnica ed esperienza al servizio delle esigenze dell’utenza. Parlano sulla base della conoscenza, evitando di fare riferimento alla propria produzione, bensì portando il discorso su un piano generale e fruibile da tutti.
Il titolo di questo documento si ispira ad Alan Cooper e al suo libro “The Inmates Are Running The asylum”, nel quale racconta che i software engineer spesso sono in grado di riconoscere solo tre numeri: zero, uno e infinito. Qualsiasi numero più grande di uno viene considerato infinito. Così i problemi possono sembrare più importanti, o i sistemi troppo complessi, proprio perché per il futuro ci si trova a dover considerare un numero infinito di possibilità.
L’esempio che si trova nel libro è quello di un servizio di video-on-demand in un sistema di intrattenimento in-flight. Poiché qualsiasi sistema di questo tipo deve offrire più di un film, il progettista potrebbe focalizzarsi troppo sull’esigenza di inserire una selezione di film molto ampia.
I software engineer spesso organizzano queste collezioni in gerarchie, e in questo esempio il primo livello offre la possibilità di scegliere un genere, mentre solo l’ultimo offre il dettaglio di titoli e descrizioni. L’esempio ha sei livelli di navigazione click-through, molti di più di quelli graditi da un utente per scegliere un semplice film. Tra l’altro, anche decidere in quale categoria inserire un determinato film può essere problematico.
Il progetto alternativo proposto da Cooper è quello di far scorrere i manifesti dei film, permettendo all’utente di fermarli in qualunque momento per visualizzare maggiori informazioni e possibilmente selezionare il film. Anche se questo genere di navigazione non può offrire un elevato numero di film, è sicuramente in grado di contenerne la quantità media offerta da un sistema di intrattenimento in-flight. Altre funzionalità avanzate erano anch’esse disponibili, come per esempio la possibilità di far scorrere più velocemente le locandine.
C’è tanto da integrare
Dopo questa introduzione, è ora di chiarire al lettore il vero obiettivo di questa trattazione. L’integrazione delle applicazioni costituisce ancora una sfida per le aziende, rappresentando una significativa porzione del costo di nuovi progetti, e la maggior parte delle imprese necessita di un’integrazione ancora maggiore per soddisfare le sue esigenze di business. Con l’elevata eterogeneità che caratterizza gli ambienti IT odierni, come può un’offerta di integrazione essere gestita al fine di risolvere un set potenzialmente infinito di esigenze di interoperabilità e come può essere fatto eliminando la complessità ma soddisfacendo gli utenti evoluti?
La soluzione è un extensible Enterprise Service Bus (Esb) ma, prima passare ad osservarlo nel dettaglio, dobbiamo parlare di Soa (Service Oriented Architecture) e dei concetti che stanno alla base di un Esb.
Le attuali best practice per l’integrazione sono raccolte in una serie di principi noti come Soa, nei quali le applicazioni vengono modificate, o incapsulate, al fine di offrire servizi che possono essere utilizzati da altre applicazioni. Tali servizi vengono utilizzati da una gamma iniziale di applicazioni e sono resi disponibili per essere riutilizzati da altre applicazioni ancora. Questo riutilizzo dei servizi è uno degli elementi chiave di risparmio offerti da una Soa. Il secondo vantaggio è che l’approccio Soa fornisce un’architettura molto pulita, offrendo una flessibilità decisamente maggiore rispetto agli approcci ad-hoc all’integrazione (per esempio quelli realizzati tramite integrazioni punto-punto).
Una Soa è una serie di principi, non si tratta di sola tecnologia. La tecnologia di interoperabilità per la Soa viene fornita dall’Esb che non solo gestisce lo strato di comunicazione, ma anche l’interoperabilità di altri aspetti di livello più elevato quali sicurezza, transazione e gestione.
Una delle principali sfide per un Esb è il fatto che diversi tipi di applicazioni in azienda siano già stati integrati con middleware diversi, cosa che crea in azienda delle vere e proprie “isole di middleware”, ognuna delle quali bene integrata internamente ma caratterizzata da standard diversi (protocolli, formati dati, sicurezza) rispetto alle altre.
Vi sono numerosi prodotti e standard middleware sul mercato (Mq, Corba, Tuxedo, Tibco/Rendezvous, Jms, ecc), alcuni con opzioni di utilizzo diverse (Tuxedo e Corba per dirne due). Vi sono funzionalità di livello ancora più alto: molti meccanismi di sicurezza, molti sistemi di transazioni, e molte modalità per combinarli. In aggiunta, alcune aziende hanno i propri protocolli e/o formati dati, alcune hanno addirittura le loro implementazioni di sicurezza per via di requisiti speciali o perché hanno investito in queste prima che fosse disponibile un prodotto commerciale completo.
Di fronte a questa incredibile gamma di scelte, come può un software vendor offrire un Esb in grado di gestire quello che sembra un set infinito di scelte?
Una strada è quella dell’extensible Esb che implementa l’integrazione tra una gamma comune di standard e prodotti middleware (quali, appunto, Mq, Corba, Tibco/Rendezvous, J2Ee Rmi/Iiop e Jms, Tuxedo e naturalmente Web service) e altre estensioni di questi. Anche se questo insieme si evolve continuamente, non deve necessariamente soddisfare tutte le possibilità in modalità out-of-the-box.
Extensible Esb
Ed è qui dove l’extensible Esb entra in gioco. I clienti possono estenderlo al fine di permettergli di fornire interoperabilità con un middleware meno comune: quello di un vendor di nicchia, o un modo inusuale di utilizzare un middleware comune o un middleware proprietario che nessun vendor Esb potrebbe supportare in modo indipendente. Il supporto all’estensibilità ha alcune similitudini con le funzionalità avanzate del sistema in-flight di Cooper: gli utenti normali non si rendono nemmeno conto dell’esistenza di queste funzionalità, ma permettono che il sistema venga usato da una gamma molto più ampia di utenti.
Anche le terze parti possono estenderlo. Un system integrator che si focalizza su un settore verticale, come per esempio le telecomunicazioni, può aggiungere supporto a una funzionalità middleware importante per quel mercato.
Anche gli hub sono a volte un ottimo modo per integrare, mentre altre volte appesantiscono troppo il sistema e possono divenire un centro di controllo del potere in azienda. È sicuramente meglio, allora, utilizzare una tecnologia di integrazione che permette di scegliere la modalità di implementazione che meglio soddisfa le esigenze aziendali, piuttosto che imporre un approccio specifico.
Gli hub di Eai (Enterprise Application Integration) sono stati il primo tentativo per far interoperare le isole di middleware, ma l’approccio era troppo centralizzato: troppa enfasi sull’hub e non abbastanza sulle applicazioni che devono comunicare. Le Soa (Service oriented architecture) mettono l’enfasi sui servizi e un Esb esiste per consentire loro di comunicare e, naturalmente, per fornire facility di alto livello come la sicurezza e la gestione.
Le Soa hanno senso solo quando tutte le barriere tra applicazioni sono state rimosse di modo che qualsiasi applicazione possa utilizzare qualsiasi servizio se dispone delle autorizzazioni necessarie.
Un Esb, quindi, deve essere estensibile per superare le barriere che esistono in azienda, e non solo quelle out-of-the-box.
Tutti gli analisti software sostengono gli approcci Soa ed Esb e raccomandano ai propri clienti di adottarli nei prossimi anni. Soa rappresenta un approccio architetturale fondamentale adottato da molte aziende in tutto il mondo, mentre Esb è la tecnologia per supportare la comunicazione e le funzionalità di alto livello all’interno di una Soa. Tuttavia, un Esb deve essere molto flessibile, deve offrire diverse tipologie di implementazione di modo che gli ingegneri possano concentrarsi sui servizi che devono interoperare, invece che sulla tecnologia che facilita le comunicazioni o sulla modalità in cui è implementata all’interno del sistema. Ma soprattutto, un Esb deve essere estensibile per soddisfare le esigenze delle aziende reali che utilizzano una vasta gamma di tecnologie proprietarie e acquisite. Questa estensibilità deve inoltre consentire al sistema di essere semplice ma al tempo stesso deve soddisfare gli utenti più evoluti.
(*)Fondatore e Chief Corporate Scientist di Iona Technologies
