ESB con SwitchYard JBoss

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];
          System.out.println(resultListaEsami[i].getDescrizione());
          System.out.println(resultListaEsami[i].getCodice());
          System.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).

In figura 2 è invece riportata la corrispondente response inviata da SwitchYard al client SOAP.

Monitoraggio dei servizi sulla console di JBoss

La console di JBoss mette a disposizione le funzioni di monitoraggio delle applicazioni 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.

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:\Programmi\jboss-as-7.1.0\bin>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:\workspaces\Eclipse\RemoteInvoker\
SwitchYardExample_PrenotazioneEsame_SWT\target\SWT-servizio-prenotazione-esami.jar

[standalone@localhost:9999 /] deploy D:\workspaces\Eclipse\RemoteInvoker\
SwitchYardExample_PrenotazioneEsame_SWT\target\SWT-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:\workspaces\Eclipse\RemoteInvoker\SwitchYardExample_PrenotazioneEsame_SWT\
target\SWT-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 i 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 un’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, potrebbe 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/Enterpriseservicebus>

• \
• [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/ServiceComponentArchitecture>

<https://docs.jboss.org/author/display/SWITCHYARD08/SCA>

• \
• [14\] Oasis

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