Nei numeri precedenti abbiamo affrontato le problematiche relative alle architetture di integrazione, con particolare attenzione a SOA e abbiamo presentato SwitchYard JBoss. A partire da questa puntata passeremo alla presentazione di un esempio reale, vedendo l’implementazione, la pubblicazione e i test di un servizio SwitchYard, cominciando in questo articolo con l’implementazione.
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.
Figura 1 – Diagramma delle classi.
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).
Figura 2 – Nuovo progetto SwitchYard.
Figura 3 – Nuovo progetto SwitchYard: nome.
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.
Figura 4 – Nuovo progetto SwitchYard: configurazione di implementazione.
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).
Figura 5 – Nuovo progetto SwitchYard: struttura Eclipse.
Figura 6 – L’apertura con l’editor visuale.
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:
Figura 7 – File di definizione del servizio.
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.
Figura 8 – Dashboard di definizione dei servizi SwitchYard.
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.
Figura 9 – Scelta dell’interfaccia del servizio.
Figura 10 – Definizione dell’interfaccia del servizio.
Figura 11 – Definizione completa del servizio.
Sulla dashboard, come illustrato dalla figura 12, verrà quindi visualizzato il Bean Service.
Figura 12 – Bean Service – rappresentazione sulla dashboard
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.
Figura 13 – Bean Service: skeleton delle classi di interfaccia e di implementazione.
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.
Figura 14 – Progetto SwitchYard attualizzato con la codifica dell’interfaccia e dell’implementazione.
Contestualmente il modello delle classi verrà attualizzato dalla classe di interfaccia e da quella che implementa il servizio (figura 15).
Figura 15 – Diagramma delle classi attualizzato.
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).
Figura 16 – Bean Service: menu contestuale.
Figura 17 – Bean Service: promozione del servizio.
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.
Figura 18 – Bean Service: tecnologia di promozione del servizio.
Viene riportata nella figura 19 l’attualizzazione della rappresentazione del servizio sulla dashboard.
Figura 19 – Bean Service – dashboard con la promozione del servizio
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).
Figura 20 – Bean Service: definizione della tecnologia di binding.
Figura 21 – Bean Service: tecnologia di binding di tipo SCA.
La definizione del servizio si conclude con la scelta delle politiche di clustering (figura 22).
Figura 22 – Bean Service: clustering per il binding SCA.
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 23 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.
Figura 23 – Definizione dichiarativa del servizio nel file SwitchYard.xml
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.
Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’Università di Roma. Si occupa di informatica da un po’ di tempo ed è attualmente impegnato su tematiche DevOps. Nel tempo libero ancora gioca a basket, nuota ed è appassionato di elettronica vintage.