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

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

   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:

[code lang=”java”]
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);
}
}
[/code]

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!