Riprendiamo il 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:
2. Inserire l’URL del WSDL del producer del servizio che vogliamo consumare (quello per esempio):

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

   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”):

   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!