Introduzione
Dopo aver descritto, nell’ambito delle architetture di integrazione, le caratteristiche dell’Enterprise Service Bus, a partire da questo articolo viene presentata una semplice implementazione di un servizio SwitchYard, con il set-up dell’ambiente di esecuzione: l’application server JBoss, e di quello di sviluppo: Eclipse. Il ciclo di vita verrà concluso con la fase di distribuzione e di test.
Predisposizione degli ambienti di esecuzione e di sviluppo
Vengono riportati di seguito i bundle di distribuzione e la documentazione relativa all’Application Server, all’ambiente di sviluppo e ai componenti aggiuntivi di Eclipse utilizzati per lo sviluppo e il test del servizio SwitchYard. Gli indirizzi da cui effettuare il download delle risorse è riportato nei riferimenti al termine dell’articolo. Per ragioni di spazio non verranno forniti i dettagli tecnici di set-up dell’ambiente, ampiamente trattati su internet alle pagine ufficiali. Verrà fatto solo riferimento all’utilizzo di un ambiente di sviluppo Eclipse, di un Application Server JBoss e del supporto SwitchYard sia per Eclipse che per JBoss:
- Eclipse [1]
- JBoss [2]
- Runtime di SwitchYard [3]
- Documentazione della versione di SwitchYard utilizzata per questo articolo [4]
Realizzazione del servizio
L’esempio proposto consiste nel pubblicare sull’ESB un servizio di prenotazione di esami universitari che espone due funzionalità utente:
- la lista degli esami che lo studente può sostenere al prossimo appello;
- la prenotazione di uno degli esami disponibili.
Si tratta di un tipico esempio, più volte impiegato in letteratura per la sua chiarezza e le sue caratteristiche, e usato anche su queste pagine da alcuni degli autori più assidui di MokaByte [5].
In figura 1 viene riportato il diagramma delle classi che rappresenta la serializzazione della logica applicativa e di accesso ai dati delle funzionalità del servizio, diagramma che non riporta nessun riferimento a implementazioni specifiche o API riferibili al container di pubblicazione.
Prima di entrare nel dettaglio della creazione del progetto, ricordiamo al lettore che tutto il codice sorgente presentato è disponibile su GITHUB [6].
Creazione del progetto e set-up del workspace
Dopo aver aggiunto a Eclipse il supporto per lo sviluppo di servizi SwitchYard, per creare il progetto di esempio verrà utilizzato il wizard corrispondente (figura 2), dove al primo step il progettista dichiarerà il nome del progetto (figura 3).
In figura 4 viene riporata la definizione dei dettagli del progetto, relativa ai componenti di implementazione e ai namespace. In questo caso il runtime di SwitchYard proposto corrisponde all’unico installato e quindi disponibile all’ambiente di sviluppo. Per questo servizio verrà utilizzato il supporto di implementazione di tipo Bean e il gateway di binding SCA, tecnologia attraverso la quale i servizi SwitchYard e i client con supporto SwitchYard possono comunicare reciprocamente. Nei dettagli questa tecnologia di binding realizza:
- la comunicazione tra istanze diverse di SwitchYard;
- l’esposizione di un end-point di invocazione remota per client esterni attraverso la tecnologia di Remote Invoking che permette a client stand-alone di comunicare con un servizio SwitchYard;
- il clustering di servizi in due o più istanze di SwitchYard.
Al termine del wizard il progetto avrà la struttura riportata nella figura 5, dove vengono evidenziati il package di implementazione e il file di definizione del servizio (switchyard.xml).
Implementazione del servizio
Un servizio SwitchYard si basa su un modello di configurazione, dove ogni applicazione pubblica il corrispondente descrittore switchyard.xml nella cartella META-INF. È questo descrittore XML che definisce l’implementazione del servizio, i gateway e le trasformazioni. Gli elementi di questo file XML sono conformi alla SCA “Service Component Architecture - Assembly Model Specification”.
Il primo passo dopo aver creato il progetto vuoto è quello di dichiarare le configurazioni del servizio attraverso il file switchyard.xml:
Viene quindi proposta dall’ambiente di sviluppo l’area visuale di definizione dei servizi SwitchYard (figura 8) dove sono presenti gli strumenti necessari alla definizione della tecnologia di implementazione e di binding.
Per questo esempio verrà utilizzata l’implementazione di tipo Bean Component, un contenitore pluggabile di SwitchYard che permette a classi Java di erogare o consumare servizi, semplicemente annotando una classe standard, piuttosto che consumare un servizio SwitchYard esistente, iniettando in una classe Java gli opportuni riferimenti.
Trascinando sull’area visuale (figura 8) l’icona che rappresenta l’implementazione del Bean, viene avviato il wizard di creazione della classe di implementazione, dove verrà indicata l’interfaccia del servizio (figura 9), creandola se necessario (figura 10), e completando in questo modo la definizione del Bean (figura 11) con la dichiarazione della classe di implementazione corrispondente.
Sulla dashboard, come illustrato dalla figura 12, verrà quindi visualizzato il Bean Service.
Saranno quindi a disposizione del progettista i due skeleton vuoti dove definire l’interfaccia e l’implementazione del servizio. In figura 13 viene riportata la struttura attualizzata del progetto Eclipse.
Negli skeleton verrà quindi codificata la logica del servizio che si ipotizza essere costituito da due metodi, uno di prenotazione di un esame e l’altro di elenco degli esami potenziali che uno studente può sostenete al prossimo appello.
Viene riportata di seguito la codifica dove si nota l’assenza di riferimenti a implementazioni del container di esecuzione: la codifica è infatti rappresenta da una banale logica di wrapping della classe di accesso dati. Sarà infatti la direttiva di annotazione @Service(IPrenotazioneEsame.class) che realizzerà l’esposizione di questa logica sotto forma di servizio del container SwitchYard. Per semplificare la lettura, le condizioni di controllo vengono riportate sotto forma di pseudocodifica.
Interfaccia del servizio
package it.luigibennardis.prenotazioneesami.swy;
public interface IPrenotazioneEsame {
DTODatiPrenotazione prenotaEsame(DTOInformazioniEsame infoEsame);
DTOEsame[] listaEsami();
}
Classe di implementazione del servizio
@Service(IPrenotazioneEsame.class)
public class PrenotazioneEsameBean implements IPrenotazioneEsame {
@Override
public DTODatiPrenotazione prenotaEsami(DTOInformazioniEsame infoEsame) {
String codicePrenotazione = null;
DTODatiPrenotazione localDatiPrenotazione = null;
// VERIFICA CHE LO STUDENTE SIA IN REGOLA CON IL PAGAMENTO DELLE TASSE
//infoEsame.getStudente();
//infoEsame.getCodiceEsame();
// VERIFICA CHE LO STUDENTE RISPETTI LA PROPEDUTICITA'
//infoEsame.getStudente();
//infoEsame.getCodiceEsame();
// VERIFICA LA DISPONIBILITA' DI POSTI PER L'APPELLO
// infoEsame.getCodiceEsame();
// GENERA IL CODICE PRENOTAZIONE [CODICEFACOLTA-CODICEESAME-CODAPPELLO]
codicePrenotazione = "001111";
//RITORNA UNA CLASSE CHE SERIALIZZA LE INFORMAZIONI DI PRENOTAZIONE
localDatiPrenotazione = new DTODatiPrenotazione(codicePrenotazione,
infoEsame.getStudente(),
infoEsame.getEsame());
return localDatiPrenotazione ;
}
@Override
public DTOEsame[] listaEsami(String matricolaStudente) {
try {
DTOEsame[] esamiDisponibili = null;
String codiceAppello = this.codiceProssimoAppello();
//ACCEDE ALLA CLASSE DI ACCESSO DATI PER OTTENERE
//LA LISTA DEGLI ESAMI CHE LO STUDENTE PUO’ SOSTENERE
esamiDisponibili = new DAOEsame().listaEsamiDisponibili(matricolaStudente,codiceAppello);
return esamiDisponibili;
}catch (Exception e) {
e.printStackTrace();
return null;
}
}
}
Viene riportata in figura 14 l’attualizzazione del progetto con la codifica delle classi di interfaccia e di implementazione.
Contestualmente il modello delle classi verrà attualizzato dalla classe di interfaccia e da quella che implementa il servizio (figura 15).
Promozione del servizio
Una volta definita e implementata l’interfaccia e la classe di implementazione sarà necessario promuovere il servizio SwitchYard. In questo senso la dashboard fornisce un menu contestuale attivabile sulla rappresentazione grafica del servizio (figura 16, figura 17).
Verrà quindi proposta (figura 18) la selezione della tecnologia di pubblicazione dell’interfaccia e la scelta del nome del servizio che sarà esposto dal container.
Viene riportata nella figura 19 l’attualizzazione della rappresentazione del servizio sulla dashboard.
L’ultimo passaggio consiste nella definizione della tecnologia di binding utilizzando sempre un menu contestuale, questa volta disponibile sulla rappresentazione grafica della promozione del servizio (figura 20 e figura 21).
La definizione del servizio si conclude con la scelta delle politiche di clustering (figura 22).
La figura 23 rappresenta l’attualizzazione sulla dashboard della completa definizione del servizio SwitchYard.
Viene in questo modo ultimata la definizione degli aspetti tecnologici di pubblicazione del servizio SwitchYard, corrispondenti in dichiarazioni che il plug-in di Eclipse ha codificato nel file di definizione del servizio. Nella figura 24 sono stati evidenziati i fragment XML relativi alla dichiarazione del nome del servizio, della classe di implementazione, dell’interfaccia esposta e della tecnologia di binding.
Conclusioni
Per questo mese ci fermiamo qui, ma torneremo presto al nostro progetto, presentandone il deploy su JBoss unitamente a molte altre caratteristiche necessarie per la sua pubblicazione.
Riferimenti
- [1] Download di Eclipse
<https://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/junosr2>
- [2] Download di JBoss
<http://jbossas.jboss.org/downloads/>
- [3] Download di SwitchYard
<http://switchyard.jboss.org/downloads>
- [4] Documentazione SwitchYard
<https://docs.jboss.org/author/display/SWITCHYARD08/Home>
- [5] L.V. Tagliati, “Architetture REST: un modello di maturità. I parte: Da RESTless a RESTful”, MokaByte 168, Dicembre 2011
<http://goo.gl/TgQWbg>
- [6] Il progetto su GitHub
<https://github.com/lbennardis/SwitchYardESBDemo>
