Nel corso di questa serie abbiamo visto alcuni concetti generali delle architetture di integrazione con particolare riferimento a SOA, abbiamo presentato SwitchYard, la nuova implementazione dell’ESB JBoss, abbiamo configurato un’applicazione e ne abbiamo effettuato il deploy. Concludiamo in questo articolo la nostra trattazione con il test del servizio.
Test del servizio
Concluso lo sviluppo del servizio SwitchYard pubblicato sull’interfaccia SCA e SOAP, verranno implementati i corrispondenti client dimostrativi dell’utilizzo di queste due tecnologie di binding.
Client di test sul binding SCA
Come già descritto, la tecnologia di invocazione remota di un servizio SwitchYard, rappresenta la modalità attraverso cui applicazioni non SwitchYard possono invocare qualsiasi servizio SwitchYard pubblicato con binding SCA. Questa stessa modalità di comunicazione è quella che il canale interno di clustering utilizza per le chiamate tra istanze SwitchYard.
Viene riportata di seguito la codifica di una classe di esempio, sviluppata in un progetto Eclipse Java standard, che consuma sul protocollo di invocazione remota il servizio SwitchYard distribuito su JBoss.
public final class RemoteClient {
private static final QName SERVICEPRENOTAZIONE
= new QName("urn:it.luigibennardis.esb.prenotazioneesami.switchyard
:SWT-servizio-prenotazione-esami:1.0",
"PrenotazioneEsame");
private static final String URL
= "http://localhost:8080/switchyard-remote";
private RemoteClient() {
}
public static void main(final String[] ignored)
throws Exception {
RemoteInvoker invokerListaEsame = new HttpInvoker(URL);
RemoteMessage messageListaEsame = new RemoteMessage();
messageListaEsame.setService(SERVICEPRENOTAZIONE).setOperation(
"listaEsami").setContent(null);
DTOEsame[] resultListaEsami = null;
RemoteMessage replyListaEsami
= invokerListaEsame.invoke(messageListaEsame);
if (replyListaEsami.isFault()){
System.err.println("ERRORE IN FASE DI INVOCAZIONE DELL'OPERAZIONE
setOperation-listaEsami"
+ replyListaEsami.getContent());
}else{
if(replyListaEsami.getContent()!= null){
Object[] objects = (Object[])replyListaEsami.getContent();
resultListaEsami = new DTOEsame[objects.length +1] ;
for (int i = 0; i<objects.length; i++){
resultListaEsami[i] =(DTOEsame)objects[i];
out.println(resultListaEsami[i].getDescrizione());
out.println(resultListaEsami[i].getCodice());
out.println(resultListaEsami[i].getDataAppello().toString());
}else{
System.err.println("replyListaEsami È NULLO!! ");
}
}
RemoteInvoker invokerVersione = new HttpInvoker(URL);
RemoteMessage messageVersione = new RemoteMessage();
messageVersione.setService(
SERVICEPRENOTAZIONE).setOperation("versione").setContent(null);
RemoteMessage replyVersione = invokerVersione.invoke(messageVersione);
if (replyVersione.isFault()){
System.err.println("ERRORE IN FASE DI INVOCAZIONE DELL'OPERAZIONE
setOperation-versione"
+ replyVersione.getContent());
}else{
if(replyVersione.getContent()!= null){
String result = (String)replyVersione.getContent();
System.out.println("versione ->" + result);
}else{
System.err.println("replyVersione È NULLO!! ");
}
}
RemoteInvoker invokerPrEsame = new HttpInvoker(URL);
DTOInformazioniEsame dtoInfoEsame = new DTOInformazioniEsame();
dtoInfoEsame.setEsame(resultListaEsami[1]);
DTOStudente studente = new DTOStudente();
studente.setCognome("Bennardis");
studente.setNome("Luigi");
studente.setMatricola("12345670");
dtoInfoEsame.setStudente(studente);
RemoteMessage messagePrEsame = new RemoteMessage();
messagePrEsame.setService(SERVICEPRENOTAZIONE).setOperation(
"prenotaEsami").setContent(dtoInfoEsame);
RemoteMessage replyEsame = invokerPrEsame.invoke(messagePrEsame);
if (replyEsame.isFault()){
System.err.println("ERRORE IN FASE DI INVOCAZIONE DELL'OPERAZIONE
setOperation-prenotaEsami"
+ replyEsame.getContent());
}else{
if(replyEsame.getContent()!= null){
DTODatiPrenotazione result
= (DTODatiPrenotazione)replyEsame.getContent();
System.out.println(result.getCodicePrenotazione());
}else{
System.err.println("replyEsame.getContent() È NULLO!! ");
}
}
}
Client di test sul binding SOAP
Per quanto riguarda il test del servizio SwitchYard promosso sul protocollo SOAP, verrà utilizzato SOAP UI. Si riporta in figura 1 la request generata da SOAP UI, a fronte della pubblicazione del WSDL del servizio (vedi articolo precedente).
Figura 1 – Request SOAP verso il servizio SwitchYard “prenotaEsami”.
In figura 2 è invece riportata la corrispondente response inviata da SwitchYard al client SOAP.
Figura 2 – Response SOAP del servizio SwitchYard “prenotaEsami”.
Monitoraggio dei servizi sulla console di JBoss
La console di JBoss mette a disposizione le funzioni di monitoraggio delle applicazione SwitchYard distribuite. Come evidenziato dalla figura 3, sono disponibili le metriche dei messaggi SwitchYard: il numero di messaggi processati, i corrispondenti tempi di esecuzione totali, medi, massimi e minimi di tutte le applicazioni e del dettaglio di ciascuna di esse.
Figura 3 – Monitoraggio dei servizi SwitchYard.
Deploy da linea di comando
Oltre alle modalità di distribuzione attraverso Eclipse e la console JBoss, sarà anche possibile utilizzare i comandi JBoss da linea di comando. Viene riportato di seguito l’esempio utilizzato per questo servizio.
C:Programmijboss-as-7.1.0 in>jboss-cli.bat You are disconnected at the moment. Type 'connect' to connect to the server or 'help' for the list of supported commands. [disconnected /] connect localhost:9999 [standalone@localhost:9999 /] deploy D:workspacesEclipseRemoteInvoker SwitchYardExample_PrenotazioneEsame_SWT argetSWT-servizio-prenotazione-esami.jar [standalone@localhost:9999 /] deploy D:workspacesEclipseRemoteInvoker SwitchYardExample_PrenotazioneEsame_SWT argetSWT-servizio-prenotazione-esami.jar 'SWT-servizio-prenotazione-esami.jar' already exists in the deployment repository (use --force to replace the existing content in the repository). D:workspacesEclipseRemoteInvokerSwitchYardExample_PrenotazioneEsame_SWT argetSWT-servizio-prenotazione-esami.jar --force [standalone@localhost:9999 /] undeploy SWT-servizio-prenotazione-esami.jar [standalone@localhost:9999 /]
Conclusioni
Questa serie di articoli rappresenta il tentativo di sintetizzare le modalità con cui un ESB possa attuare modelli e implementazioni di interazione e comunicazione tra domini applicativi distinti. Nei fatti, superando il limiti delle altre architetture di integrazione, questo middleware realizza l’integrazione attraverso un effettivo disaccoppiamento dei sistemi utilizzando standard aperti, aspetto fondamentale per implementare architetture orientate ai servizi. In questo senso, un ESB deve essere considerato come un insieme di strumenti e una filosofia di progettazione. Non è quindi sufficiente acquistare un prodotto di ESB e installarlo nell’infrastruttura IT affinch� si possa affermare di avere una architettura di integrazione basata sul paradigma ESB.
Abbiamo visto, negli articoli precedenti, il ciclo di vita, dall’implementazione alla distribuzione, di un semplice servizio SwitchYard, l’ESB di JBoss. La fase di implementazione evidenzia come l’ambiente di esecuzione rappresenti un dettaglio trasparente nella fase di realizzazione del servizio, così che il progettista possa prendere in considerazione i dettagli rilevanti del servizio: la sua interfaccia, l’implementazione e le politiche di configurazione. Infatti, attraverso le direttive di annotazione, risulta molto semplice esporre un servizio a partire dall’implementazione di una classe Java standard senza che in questa vengano codificate le specifiche di funzionamento del container. Inoltre il supporto al clustering del container, sempre implementato in modo dichiarativo, permette di ottenere per ogni servizio l’alta affidabilità. Sulla base di questi elementi questa soluzione di ESB potrebbe rappresentare una scelta corretta se, nella valutazione del costo globale, si prendono in considerazione anche i costi attribuibili al tempo necessario allo start-up e quindi all’acquisizione della tecnologia da adottare.
Questo middleware infatti realizza obiettivi di riduzione dei costi, non solo riferibili all’acquisto di licenze ma anche e soprattutto derivanti dalla riduzione dei costi di sviluppo, abilitando inoltre la possibilità di riutilizzo di implementazioni già fatte. La rapidità di implementazione, assieme agli altri aspetti di costo potrebbero quindi trovare il favore dei progettisti, che lavorano spesso su pianificazioni sfidanti, e del management, che ha sempre a disposizione budget limitati.
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.