ESB con SwitchYard JBoss

V parte: Test del serviziodi

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 E' 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 E' 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() E' 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.0in>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.

Riferimenti

[1] SwitchYard

http://www.jboss.org/switchyard

https://docs.jboss.org/author/display/SWITCHYARD/Home

http://searchsoa.techtarget.com/feature/Red-Hat-makes-a-switch-SwitchYard-project-to-replace-JBoss-ESB

 

[2] ESB

http://en.wikipedia.org/wiki/Enterprise_service_bus

 

[3] jUDDI

http://juddi.apache.org

 

[4] jBPM

http://www.jbpm.org/

 

[5] BPMN

http://www.bpmn.org/

 

[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

http://www.drools.org/

 

[9] Apache Camel

http://camel.apache.org/

 

[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

 

[14] Oasis

http://docs.oasis-open.org/ns/opencsa/sca/200912

 

Condividi

Pubblicato nel numero
204 marzo 2015
Luigi Bennardis si è laureato in Scienze Statistiche ed Economiche all’università di Roma e si occupa di informatica da diversi anni. Dopo una lunga esperienza di system integration su piattaforma Java EE e Microsoft in una importante società di consulenza, attualmente si occupa di progettazione e sviluppo su tecnologie distribuite…
Articoli nella stessa serie