Web Services for dummies: creare un servizio web SOAP per Tomcat – il Consumer

Riprendiamo il nostro tutorial passo passo sulla creazione di un servizio web SOAP per Tomcat con Eclipse. Chi si è perso la scorsa puntata dirà: perché dovrei usare SOAP nel 2011? Una risposta valida può essere: perché non devi scrivere una riga di codice! Banale ma efficace! 😉 Vediamo quindi come questa regola si applica soprattutto alla scrittura del client/consumer del servizio web.

Il Consumer

In pochi passi:

  1. Creiamo un nuovo progetto web: scegliamo target runtime, nome ecc… Al termine, click destro sulla cartella src, poi New -> Other… e selezionare Web Service Client:
    Selezionare Web Service Client
  2. Inserire l’URL del WSDL del producer del servizio che vogliamo consumare (quello creato nel post precedente per esempio):
    Inserire l'indirizzo del WSDL

    Ricordiamo che il WSDL si ottiene sempre aggiungendo il query param WSDL (non case sensitive) all’URL del servizio:

    http://localhost:8080/WebServiceProducerTest/services/MyService?wsdl

  3. Selezionare il livello di deploy: scegliamo tra “Test service” o “Run service” e decidiamo di monitorare il servizio (“Monitor the Web Service”):
    Selezionare il livello di deploy

    Se scegliamo di testare il servizio, nella schermata successiva verrà chiesto quali metodi testare: Eclipse creerà una pagina JSP per lo scopo.

Un occhio al progetto

La magia è compiuta! Guardando il progetto, sono apparse una serie di classi che ricordano il nome del servizio che abbiamo creato sul provider e dei parametri passati in input e output.

Per curiosità, diamo un occhiata alle classi Input e Output generate automaticamente: sono molto complesse, con la stessa firma di quelle del producer, ma internamente molto diverse. L’idea è quella di usare le classi generate come se il servizio fosse locale, trasparente allo sviluppatore: le classi create infatti fanno da proxy e nascondono tutta l’interazione col server che sta dietro le quinte. Vediamo come, con due test in JUnit:

public class MyServiceTest {

   @Test
   public void testEcho() throws Exception {
      MyService service = new MyServiceProxy();
      
      String echo = service.echo("Say what?!");
      
      assertNotNull(echo);
      assertEquals("Echo Say what?!", echo);
   }

   @Test
   public void testSort() throws Exception {
      MyServiceService serviceLocator = new MyServiceServiceLocator();
      MyService service = serviceLocator.getMyService();
      
      Output output = service.sort(new Input(new int[] {5,4,3,2,1}));
      
      assertNotNull(output);
      assertNotNull(output.getSortedVector());
      assertTrue(output.getSortedVector().length > 0);
      assertEquals(5, output.getSortedVector().length);
      assertEquals(output.getSortedVector()[0], 1);
      assertEquals(output.getSortedVector()[1], 2);
      assertEquals(output.getSortedVector()[2], 3);
      assertEquals(output.getSortedVector()[3], 4);
      assertEquals(output.getSortedVector()[4], 5);
   }

}

I due test mostrano le modalità con cui è possibile invocare il servizio (cioè tra MyServiceProxy o MyServiceServiceLocator): in ambedue i casi, a leggere questo codice non si ha la minima percezione che il servizio sia remoto, nascondendo egregiamente la complessità della codifica e decodifica del protocollo SOAP in semplici chiamate tra oggetti.

Conclusioni

Con questo post, abbiamo chiuso il cerchio: dalla creazione, alla consultazione di un servizio web SOAP. Nelle prossime settimane affronteremo lo stesso argomento con JBoss 6 per mostrare le differenze di approccio e poi tenteremo di fare la stessa cosa per i servizi REST, cercando ci capirne le differenze architetturali. Stay tuned!

Andrea Como

Sono un software engineer focalizzato nella progettazione e sviluppo di applicazioni web in Java. Presso OmniaGroup ricopro il ruolo di Tech Leader sulle tecnologie legate alla piattaforma Java EE 5 (come WebSphere 7.0, EJB3, JPA 1 (EclipseLink), JSF 1.2 (Mojarra) e RichFaces 3) e Java EE 6 con JBoss AS 7, in particolare di CDI, JAX-RS, nonché di EJB 3.1, JPA2, JSF2 e RichFaces 4. Al momento mi occupo di ECM, in particolar modo sulla customizzazione di Alfresco 4 e sulla sua installazione con tecnologie da devops come Vagrant e Chef. In passato ho lavorato con la piattaforma alternativa alla enterprise per lo sviluppo web: Java SE 6, Tomcat 6, Hibernate 3 e Spring 2.5. Nei ritagli di tempo sviluppo siti web in PHP e ASP. Per maggiori informazioni consulta il mio curriculum pubblico. Follow me on Twitter - LinkedIn profile - Google+