Tra le principali novità degli ultimi anni spiccano il web 2.0, la tecnologia Ajax, le Rich Internet Application e i web services. I web services sono una tecnologia che, in modo più o meno indiretto, impatta su tutte le altre tecnologie appena menzionate. Una chiamata Ajax è una sorta di web service libero dalla necessità di rispettare un protocollo rigido; le Rich Internet Application usano spesso dei web services per aggiornare i contenuti in modo rapido e trasparente all'utente; il web 2.0 sfrutta molti servizi distribuiti, che sono spesso web services.
I web services possono sembrare complicati o astratti di primo acchito, ma si basano su un concetto estremamente semplice: garantire l'interoperabilità dello scambio di dati tra applicazioni e/o piattaforme diverse. Quello che a volte rende difficile lavorare con i web services è la creazione di un singolo web service, la cui difficoltà dipende dalla tecnologia scelta per l'implementazione. Ma preoccuparsi dell'implementazione prima di aver compreso i concetti fondamentali che stanno alla base dei web services significa mettere il carro davanti ai buoi. Rimandiamo alle prossime puntate la discussione sul come implementare un web service (vedremo un esempio in PHP), e iniziamo con l'introdurre il protocollo SOAP per vedere qualche esempio concreto.
Vantaggi dei web services
Il principale motivo che spinge a gestire lo scambio di dati tra applicazioni è l'interoperabilità dei sistemi. Quando due applicazioni dialogano tra loro usando dei web services, sia chi espone il servizio (server) che chi lo consuma (client) possono ignorare le scelte tecnologiche della controparte.
Esempio: se espongo un web service che fornisce previsioni meteo, posso decidere di realizzare il lato server in Java, PHP, .NET o qualsiasi altra tecnologia. Chi consuma il servizio (lato client) è altrettanto libero di usare la tecnologia che preferisce. Anche se server e client utilizzeranno tecnologie diverse, memorizzando dati su database diversi e girando su sistemi operativi diversi, a livello dei web services tali differenze non esistono. Se un domani una delle due parti volesse migrare su un altro sistema, cambiare applicazione, database o architettura, l'altra parte non si accorgerà di nulla: tutto continuerà a funzionare come prima, senza alcune modifica.
Principi di funzionamento
Non vi è alcuna magia sotto il concetto di interoperabilità. Il principio di funzionamento è semplicissimo: client e server si scambiano normalissimi messaggi di testo, usando la sintassi XML (chi non conoscesse l'XML può dare un'occhiata a questo articolo). Vediamo subito un esempio concreto, considerando un web service che fornisce le previsioni meteo di una zona. La richiesta inviata dal client potrebbe essere qualcosa del genere
<forecastRequest>
<town>Milan</town>
<contry>Italy</country>
<when>17-03-2012</when>
</forecastRequest>
la risposta prodotta dal server potrebbe essere
<forecastResponse>
<description>Sunny and warm</description>
</forecastResponse>
come vediamo, request e response rispettano il formato XML: è per questo motivo che al client “non importa nulla” di come sia implementato il server, e viceversa. Fin tanto che i messaggi scambiati rispettano il formato XML l'interoperabilità del servizio viene da sé.
Il protocollo SOAP
Quanto detto sopra è sostanzialmente corretto, ma abbiamo semplificato l'argomento allo scopo di rendere il più chiaro possibile il principio di funzionamento. Esistono molti modi di concordare uno scambio di messaggi tra client e server nel paradigma dei web services, come ad esempio SOAP e REST, per cui il protocollo di comunicazione non è né standard né omogeneo. In altre parole esistono diversi “dialetti” relativi ai web services, cosa che riduce l'interoperabilità teorica. Nella pratica client e server devono concordare quale “dialetto” usare tra le scelte possibili. Come se non bastasse, anche dopo aver scelto un “dialetto” specifico, potremo scegliere tra diversi stili di comunicazione, come esempio lo stile RPC/encoded, RPC/literal, Document/literal ed altri.
Noi ci concentreremo sul protocollo SOAP (Simple Object Access Protocol), che sembra essere quello più consolidato e con maggiori possibilità di affermarsi come standard nell'immediato futuro. Per il protocollo SOAP vale sostanzialmente quando detto fin'ora, con una piccola precisazione formale: a rigore un messaggio SOAP non è XML. Per XML si intende solamente il formato dei dati, ovvero un insieme di tag nidificate tra loro. Il protocollo SOAP utilizza l'XML per lo scambio dei dati, ma aggiunge alcune specifiche, che riguardano (ad esempio) come trasmettere i dati su un protocollo di trasporto (di solito HTTP). In sintesi: SOAP è un modo di “mettere assieme” il protocollo di trasporto e il formato XML per concordare un paradigma di trasmissione di messaggi tra client e server.
Per ribadire il concetto basta osservare che SOAP prevede anche la possibilità di trasmettere dati in formato XML attraverso un protocollo di trasporto diverso dall'HTTP, come ad esempio il TCP/IP.
Conclusioni
Abbiamo introdotto i vantaggi dei web services e accennato alle caratteristiche del protocollo SOAP. Nelle prossime puntate vedremo come definire l'interfaccia di comunicazione tra client e server mediante un documento WSDL (Web Service Definition Language), assieme a qualche esempio concreto in PHP. Ci basteranno poche righe di codice per creare sia il lato server del servizio, sia la definizione del WSDL descrittore del servizio stesso. A quel punto, quando avremo sotto gli occhi il codice che realizzare il servizio, dovrebbe essere più facile metabolizzare i concetti visti sopra e iniziare a pensare al codice di un'eventuale client (sempre in PHP).
