Una panoramica sui Webservices
Il termine "webservice" spesso viene utilizzato quasi ad evocare meraviglie inenarrabili. L'enfasi in parte è meritata, ma sostanzialmente il concetto indica un'applicazione in grado di ricevere richieste codificate in un formato XML, elaborarle, e successivamente fornire i risultati nel medesimo formato.
Il mezzo di trasmissione che di solito rende possibile questo dialogo è una vecchia conoscenza: il protocollo HTTP.
Usando una metafora, potremmo dire che in uno scambio di telefonate tra un uomo d'affari tedesco e uno giapponese il telefono è HTTP, mentre la lingua inglese con la quale provano ad intendersi ricopre un ruolo simile a quello dell'XML.
Nei webservice poco importa in quale linguaggio siano stati scritti il client che esegue la richiesta e il server che la riceve, perché Php riesce a scambiare dati con Python, Java o Perl...e viceversa.
Come avviene tutto ciò?
Packaging
L'articolo Serializzare e immagazzinare i dati illustra come sia possibile rappresentare il contenuto di una variabile attraverso una sequenza di caratteri di testo: questa operazione viene detta anche Packaging (o Marshalling) e si rivela utile in molte occasioni.
Ebbene, nelle varie tecnologie per i servizi WEB, il compito affidato ad XML, è proprio quello fornire una rappresentazione universale dei dati consentendo e l'interoperabilità e lo scambio di codice tra applicazioni diverse.
Per comprendere esattamente cosa sia la serializzazione vi invito a leggere l'articolo appena citato, in particolare il paragrafo relativo alle capacità descrittive dell'XML.
Capacità descrittiva e il problema dei "tipi di dato"
Una delle cose che si apprendono immediatamente quando ci si avvicina per la prima volta ad un linguaggio di programmazione è che una stringa (Es. "Ciao belli!") è un tipo di dato diverso da un numero intero o a virgola mobile, e che esistono anche tipi di dato complessi come gli array e gli oggetti.
Purtroppo non tutti i linguaggi prevedono gli stessi tipi, inoltre vi sono linguaggi come Java che sono a "tipizzazione forte", ovvero molto rigorosi nella gestione dei tipi. Al contrario Php e Perl sono caratterizzati da una gestione molto più morbida e qualificano le variabili in base al contesto in cui vengono usate: ad esempio in Php la stringa "5" viene considerata automaticamente un intero qualora si tenti di sommarla ad un numero.
Per fare un ulteriore esempio di inconciliabilità, osserviamo che Perl distingue tra il tipo "array" (a chiavi numeriche) e il tipo "hash" (associativo), mentre in Php non c'è modo di comprendere immediatamente se un array sia associativo o a indicizzazione numerica.
In mezzo a questa babele non stupisce che i vari "dialetti XML" utilizzabili per il packaging e la condivisione abbiano preferito semplificare definendo dei propri tipi, i quali coincidono solo in parte con quelli esistenti nei diversi linguaggi.
Ad esempio poiché XML non può contenere dati binari questi vanno "avvolti" nella codifica base64 e danno luogo al tipo di dati "base64" che non trova riscontro in alcun linguaggio.
Inviare pacchetti XML con HTTP
Il protocollo di trasporto utilizzato è quasi sempre HTTP, la ragione principale è che esisteva già (l?intero WEB si fonda su esso) e consente di raggiungere anche macchine remote protette da firewall. La porta 80, infatti, su cui di solito stanno in ascolto i webserver è quasi sempre aperta; ad ogni modo la flessibilità delle tecnologie di cui stiamo parlando non preclude affatto l?adozione di soluzioni diverse.
Come avviene il dialogo tra client e server nei webservice?
Analogamente al modo in cui i navigatori sono abituati ad inviare informazioni attraverso i form html: quando clicchiamo sul tasto "Submit" inviamo il contenuto del modulo a una pagina sul server, che può risponderci a sua volta con del contenuto visualizzabile dal browser. Il metodo HTTP predefinito è POST.
Tutti i dettagli su come effettuare queste operazioni da puro codice Php sono descritti nell?articolo Php, Socket e HTTP.
Sintassi XML per i webservices
Proprio perché XML è uno standard aperto ed estremamente flessibile è necessario che le applicazioni si "accordino" sull'utilizzo di un "dialetto" condiviso (DTD, o Schema per gli appassionati dell'argomento) : per questa ragione sono state sviluppate diverse tecnologie come WDDX, XML-RPC e SOAP che fungono da piattaforma comune.
Php le supporta tutte in modo soddisfacente quindi le descriverò solo brevemente nei prossimi paragrafi, poichè negli articoli che verranno le affronteremo più approfonditamente.
XML-RPC
XML-RPC è stato sviluppato da UserLand Software nel 1998 ed è il primo protocollo standard completo per i sistemi distribuiti e l'interoperabilità tra le applicazioni, RPC sta per "Remote Procedure Call" ("chiamata a procedura remota") e significa che il client può chiedere al server di chiamare una o più routine i cui parametri (argomenti) saranno specificati dallo stesso client. Ovviamente è il server ad avere definito e reso disponibile a tale chiamata le diverse funzioni in questione.
Le diverse librerie per XML-RPC disponibili per i vari linguaggi, si occupano di tutto, sia del packaging dei dati che del loro invio tramite HTTP.
Ecco un pacchetto d'esempio per una request:
<?xml version="1.0" ?>
<methodCall>
<methodName>moltiplicaNum</methodName>
<params>
<param>
<value><i4>6</i4></value>
</param>
<param>
<value><i4>5</i4></value>
</param>
</params>
</methodCall>
Viene chiesto al server di eseguire la funzione moltiplicaNum() con argomenti gli interi (i4) 6 e 5.
XML-RPC sembra destinato ad essere rimpiazzato da SOAP, ma è ben lontano dall'essere considerato superato poiché, vista la sua semplicità, è l'ideale in contesti che non necessitano delle caratteristiche più avanzate del suo parente stretto.
SOAP
Il Simple Object Access Protocol è una derivazione di XML-RPC, dal quale eredita sia la sintassi che la possibilità di effettuare chiamate remote. Sembra destinato a fare la parte del leone nel futuro prossimo poiché SOAP 1.1 è alla base dei lavori del W3 per il W3C XML Protocol. Inoltre un'azienda nota ai più (Microsoft) sta puntando davvero molto su questo protocollo. Maggiori informazioni sulla bozza di lavoro del W3 sono reperibili qui http://www.w3.org/tr/soap12
WDDX
Sviluppato da Allaire Software (oggi fusa con Macromedia) fornisce un meccanismo per lo scambio di strutture di dati complesse alternativo a quelli visti fino ad ora, tra tutte è la tecnologia più semplice in quanto si occupa esclusivamente del packaging dei dati: la fase dell'invio attraverso HTTP e la creazione di un server che faccia da listener vengono lasciate all'abilità e alla fantasia dello sviluppatore.
Ad ogni modo ritengo che non vi sia nulla che XML-RPC è in grado di fare che non possa essere replicato anche utilizzando WDDX.
Utilità dei Servizi Web
Il fatto stesso di consentire ad applicazioni così diverse di dialogare tra loro dovrebbe essere sufficiente a suscitare l'interesse non solo dei programmatori Java esperti di reti e sistemi distribuiti, ma anche dei meno esigenti programmatori WEB.
Pensiamo alla possibilità di interrogare con qualsiasi linguaggio il database di Google (ce ne occuperemo presto) e di inserire nei nostri siti i risultati delle ricerche (una sorta di "grabbing" legalizzato insomma) o, per fare un ulteriore esempio, poter trasportare l'intera sessione di un utente da un sito all'altro (magari sviluppato con un altro linguaggio) anche se non è possibile condividere un database in cui memorizzare le sessioni.
Conclusioni
Questo articolo, molto teorico e poco pratico, è stato scritto con l'obiettivo preparare la strada alle applicazioni concrete di cui ci occuperemo nelle prossime settimane.
Ultimamente si fa un gran parlare dei servizi web e non c'è portale o rivista cartacea che non abbia presentato un qualche script d'esempio, spesso un po' arido, con l'intenzione di provare la potenza e l'utilità di questa tecnologie.
Secondo me ciò di cui si sente la mancanza è un approccio all'argomento che sia più di ampio respiro: un po' di teoria che illumini la pratica dovrebbe servire ad introdurre concetti che sono complicati soltanto in apparenza.
