In questo articolo si affrontano due argomenti. Anzitutto si analizzano le caratteristiche specifiche degli Enterprise Service Bus, visti come evoluzione delle soluzioni di integrazione. Si introduce poi SwitchYard che è l’implementazione di un ESB di JBoss.
Introduzione
Dopo aver illustrato una sintesi delle soluzioni di integrazione applicativa, in questa seconda parte sono individuate le specificità che caratterizzano l’Enterprise Service Bus quale evoluzione delle architetture di integrazione. Questa parte si conclude con la presentazione delle caratteristiche salienti di SwitchYard, l’implementazione dell’ESB di JBoss.
Servizi in un ESB
I servizi di un ESB rappresentano le funzionalità applicative esposte da questo middeware. La loro caratteristica è quella di essere univocamente definiti, auto–contenuti e indipendenti dallo stato e dal contesto del servizio stesso. Come illustrato nella figura 1, un ESB, attraverso un manifesto, espone la descrizione dei servizi senza riportare dettagli tecnici di implementazione. Attraverso questo principio di segregazione, all’interno di un ESB è possibile far corrispondere a un servizio implementazioni diverse di pari interfaccia.
Il descrittore rappresenta quindi lo strumento attraverso cui un consumatore può accedere al servizio corrispondente sull’appropriato protocollo di trasporto. Ogni ESB ha quindi a disposizione degli adattatori di protocollo necessari a gestire i dettagli di trasporto; eventuali adattatori intelligenti possono essere utilizzati nel caso sia necessario indirizzare messaggi sulla base del contesto o del loro contenuto. L’essenza di un ESB si esprime quindi in una piattaforma di esecuzione per questi adattatori e indirizzatori, progettata specificatamente per ospitare ed esporre servizi.
Figura 1 – Servizi in un ESB.
Registro dei servizi
Attraverso l’integrazione con il registro dei servizi, un ESB valorizza ulteriormente il principio di segregazione dei dettagli di implementazione. Infatti il meccanismo di accesso ai servizi esposti dall’ESB prevede che il consumatore interagisca direttamente con il fornitore del servizio, quindi, nonostante la segregazione dell’implementazione, le parti risultano fortemente accoppiate e sarebbe piuttosto complicato gestire un adeguamento dell’interfaccia. Un ESB supera questo limite con la possibilità di integrarsi con un registro di servizi il cui compito è quello di gestire la corrispondenza tra il servizio e la logica applicativa di implementazione.
Attraverso questo meccanismo, l’ESB associa al servizio richiesto dal consumatore l’interfaccia definita nel registro dei servizi, eseguendo poi per questa via il collegamento alla logica applicativa corrispondente, astraendo quindi il consumatore anche dall’interfaccia del servizio. Questa flessibilità va chiaramente a scapito del type–checking, con la conseguenza di possibili errori di corrispondenza dei tipi in fase di invocazione.
Aggregazione e collaborazione dei servizi
Sappiamo bene che la granularità di servizi rappresenta un elemento determinante per decidere il livello di riutilizzabilità degli stessi. La caratteristica dei servizi a grana grossa è quella di poter consumare servizi di grana più fine; a loro volta, le applicazioni che consumano servizi a grana grossa non sono più esponibili a servizi di grana più fine. Infatti i servizi a grana più fine, implementando funzionalità minime, non possono rappresentare aggregati di altri servizi. Da questi assunti deriva che i servizi compositi sono i soli a poter rappresentare l’aggregazione di servizi di granularità diversa.
In questo contesto, un ESB funziona da strato di messaggistica di collegamento fra applicazioni e servizi, fornendo così una infrastruttura di aggregazione e composizione dei servizi, il cui valore fondamentale consiste nel definire servizi compositi in modo dichiarativo a partire da servizi di base. Questo aspetto abilita la possibilità di integrare in un ESB gli strumenti di gestione di processi di business (BPM) sfruttando l’aggregazione e la collaborazione tra i servizi, e semplificando così il riutilizzo dei servizi di base a livello di processo di business.
Figura 2 – ESB: Aggregazione e collaborazione.
Servizi: dalla condivisione al riutilizzo
L’architettura di integrazione del Message Bus abilita un aspetto chiave delle architetture orientate ai servizi: la condivisione. In questo senso lo stesso servizio viene distribuito sul Bus in differenti ambienti, in ragione di alcune considerazioni, ad esempio, tecnologiche o di canale. Nonostante il componente e la sua implementazione del servizio siano riutilizzati, questo modello evidenzia un significativo overhead in termini di distribuzione, gestione e manutenzione. Questo overhead è descritto nella figura 3, dove tre istanze dello stesso servizio sono in esecuzione su sistemi diversi, ciascuno caratterizzato da diverse tecnologie di protocollo e di canale.
Figura 3 – Message BUS: condivisione dei servizi.
Un ESB supera i limiti della condivisione dei servizi del Message Bus attraverso un effettivo riuso dei servizi. Come possiamo vedere dalla figura 4, un ESB è configurato per diversi scenari di condivisione del servizio. In questo modo, i consumatori accedono alla stessa istanza del servizio utilizzando appropriati canali e protocolli.
Figura 4 – ESB: riutilizzo dei servizi.
Virtualizzazione dei servizi
In una realtà in cui le informazioni aziendali risiedono in sistemi mainframe centralizzati o sistemi distribuiti, la virtualizzazione dei servizi è la possibilità di suddividere le informazioni in “servizi virtuali”, indipendenti quindi dal protocollo, dalle tecnologie di trasporto e dall’implementazione effettiva dei componenti applicativi.
Con l’incapsulamento e l’aggregazione è infatti possibile virtualizzare i servizi, esponendoli così in modo consistente, creando un modello di riuso dei servizi in modalità black-box con la pubblicazione, allo stesso livello di astrazione, di interfacce diverse. In questo contesto, il compito dell’ESB è quello di gestire l’indirizzamento, la traslazione e l’aggregazione, quale soluzione al problema di interoperabilità derivato dalla virtualizzazione. Questa infatti, mappando l’interfaccia visibile di un servizio sull’interfaccia della risorsa del servizio effettivo, può fornire tutte le astrazioni dei servizi necessarie a tutti i tipi di consumatori.
L’immagine di figura 5 il concetto di virtualizzazione dei servizi all’interno di un ESB.
Figura 5 – ESB: virtualizzazione dei servizi.
JBoss SwitchYard
SwitchYard è la nuova implementazione dell’Enterprise Service Bus di JBoss. Evoluzione del progetto JBoss ESB, mette a disposizione un framework modulare di sviluppo completo e intuitivo che si integra con numerose tecnologie standard. Dispone di un run–time interno con dipendenze limitate, aspetto che permette la distribuzione e l’erogazione di servizi internamente alle proprie applicazioni o come applicazioni stand-alone Java o all’interno di una istanza di JBoss.
SwitchYard ha a disposizione quei componenti che realizzano le funzioni di connettività, trasformazioni, routing e orchestrazioni tipiche di un ESB. Il run-time di SwitchYard è tale da rappresentare un dettaglio trasparente nel ciclo di vita del servizio; in questo modo il progettista resta concentrato sull’implementazione, ottenendo dal framework gli strumenti di definizione dei test e di gestione dei dettagli importanti del servizio: il contratto, le politiche di gestione, la configurazione e la composizione. Le funzionalità comuni, come la validazione e la trasformazione, isolate dalla logica applicativa, vengono gestite da SwitchYard in modo dichiarativo, aspetto che assicura la consistenza ed elimina le ridondanze, offrendo allo sviluppatore una visione chiara della struttura delle relazioni dei servizi in una applicazione di integrazione.
FIgura 6 – Switchyard: modello di configurazione di un servizio.
La figura 7 evidenzia le caratteristiche di separazione tra strumenti di implementazione e test e l’ambiente di esecuzione. Possiamo notare le diverse tecnologie di implementazione dei servizi (Bean, Camel, BPM, etc.), quelle di comunicazione e di conversione di protocollo (SOAP, RESTEasy, Camel, etc.) e di trasformazione (Java, Smooks, JSON, XSLT, JAXB).
Figura 7 – SwitchYard: runtime, strumenti di sviluppo e di test.
Come vedremo nella prossima parte, l’implementazione di un servizio SwitchYard si basa sulla pubblicazione di un descrittore XML: il file switchyard.xml, dove sono dichiarate le classi di implementazione e di interfaccia del servizio, i gateway, le trasformazioni e tutte le politiche che ne definiscono il funzionamento all’interno del container.
Elenchiamo di seguito le tecnologie e le funzionalità principali integrate in SwitchYard, rimandando il lettore alla corrispondente documentazione ufficiale per una loro più approfondita trattazione.
Le integrazioni di SwitchYard
Switchyard è integrato con:
- CDI (Contexts and Dependency Injection), la specifica di Java Enterprise Edition per gestire il ciclo di vita e la dependency injection dei bean stateless. Questo permette a classi Java standard di diventare servizi semplicemente aggiungendo l’annotazione “@Service”; i bean vengono così registrati automaticamente in fase di esecuzione e i riferimenti ad altri servizi possono essere iniettati come bean CDI usando l’annotazione “@Inject”. Questa specifica può essere utilizzata anche per le tecnologie JSP e JSF iniettando servizi e riferimenti a livello di applicazioni web.
- jBPM 5 e BPMN 2 per la definizione grafica dei processi di business e l’integrazione dei workflow. Anche i processi di business risultano così disaccoppiati dai dettagli di implementazione attraverso la loro esposizione come servizi SwitchYard.
- Smooks, Java, XSLT, JSON in tema di trasformazione. Attraverso queste tecnologie il progettista definisce le trasformazioni dichiarative dei tipi che vengono automaticamente registrate ed eseguite da SwitchYard. Viene in questo modo superato l’approccio procedurale, fatto di implementazioni specifiche, quale soluzione del problema delle trasformazioni nei progetti di integrazione e nelle architetture orientate ai servizi.
- Drools attraverso cui è possibile incapsulare ogni regola di business sotto forma di servizi decisionali.
- Apache Camel framework attraverso il quale realizzare le pipeline di ogni servizio, disponendo di un motore di indirizzamento flessibile e basato sull’EIP, oltre a funzioni di gateway binding per i servizi SwitchYard.
- Plugin Forge per lo sviluppo di applicazioni basate su Maven per semplificare l’implementazione e rendere più efficiente il collaudo, utilizzando il supporto completo per il test unitario in fase di sviluppo.
Cosa implementa SwitchYard
SwitchYard implementa:
- Funzioni di trasformazione dei protocolli di comunicazione (p.e.: HTTP, FTP, REST, SOAP, JSON, DCOM, CORBA, SAP RFC etc.) attraverso cui realizzare la connettività tra applicazioni legacy. Attraverso specifici adattatori, infatti, i dati trasmessi su protocolli diversi verranno tradotti in un formato che può essere veicolato all’interno dell’ESB.
- Funzioni di registrazione ed erogazione di servizi attraverso jUDDI, un registro dei servizi che risolve e localizza i servizi pubblicati, funzionando da gestore dei riferimenti degli end-point interni all’ESB. Il progettista non dovrà quindi preoccuparsi di localizzare i servizi che saranno risolti attraverso il registro.
- Funzioni di orchestrazione di processi attraverso un processo centrale, erogato con l’implementazione di JBPM.
- Funzioni di change management in relazione alla stessa natura evolutiva dei servizi. In questo contesto, l’aggiornamento viene gestito attraverso funzionalità di hot deploy, versionamento e monitoraggio attraverso la console amministrativa.
- Funzioni di transazionalità per assicurare la consistenza dei servizi erogati.
Conclusioni
In questa seconda parte abbiamo illustrato gli aspetti che caratterizzano l’Enterprise Service Bus nell’ambito delle architetture di integrazione. Abbiamo quindi descritto l’implementazione, il modello di funzionamento e le tecnologie integrate di SwitchYard, l’ESB di JBoss, che utilizzeremo nella prossima parte come ambiente di esecuzione per pubblicare un semplice servizio.
Riferimenti
[1] SwitchYard
http://www.jboss.org/switchyard
https://docs.jboss.org/author/display/SWITCHYARD/Home
[2] ESB
http://en.wikipedia.org/wiki/Enterprise_service_bus
[3] jUDDI
http://juddi.apache.org
[4] jBPM
[5] BPMN
[6] Weld – CDI Reference Implementation
http://docs.jboss.org/weld/reference/latest/en-US/html/
[7] CDI
http://docs.oracle.com/javaee/6/tutorial/doc/giwhl.html
[8] Drools
[9] Apache Camel
[10] EIP
http://www.enterpriseintegrationpatterns.com/
[11] David Chappell, “Enterprise Service Bus”, O’Reilly, 2004
[12] Binildas C. A., “Enterprise Service Bus integration solutions for Java developers”, Packt Publishing, 2008
[13] SCA Service Component Architecture
http://en.wikipedia.org/wiki/Service_Component_Architecture
https://docs.jboss.org/author/display/SWITCHYARD08/SCA