E' da un po' di tempo che si sente parlare molto di Web Service, di .NET e del protocollo SOAP.

Il fatto che la tecnologia dei Web Services si stia sviluppando parallelamente a .NET e sia da .NET egregiamente supportata, potrebbe portarci a pensare che i Web Services siano una prerogativa e un'invenzione tutta Microsoft. In realtà non è così perché il Web Service è molto di più.

Il Web Service è una tecnologia che nasce e si sviluppa come standard per un modello di applicazioni del futuro, indipendentemente dal sistema operativo che lo utilizza o che lo predispone e dal modo in cui viene implementato.

Ma cosa è un Web Service?

Con il passare del tempo ed il maturarsi della tecnologia, abbiamo visto come le risorse messe a disposizione dal web siano diventate "risorse Web" e quindi "applicazioni Web", cioè una serie di pagine opportunamente costruite e messe insieme in un magico incastro capace di fare delle complicate elaborazioni prima impensabili.

La logica è relativamente molto semplice: digitiamo l'indirizzo della pagina dinamica, il server elabora il codice nella pagina e ci restituisce i risultati.

Finora ci siamo "limitati" ad utilizzare i risultati ottenuti da una elaborazione e a trasformare dei dati in contenuto informativo, rappresentandoli nella forme consentite dall'HTML.

D'altro canto, abbiamo anche assistito ad una migrazione delle nostre applicazioni locali: il software installato sulle nostre macchine si sta spostando verso il Web fino a diventare dei servizi Web ed essere distribuiti dal Web. Pensiamo per esempio ai diffusissimi siti che gestiscono la posta elettronica in tutto e per tutto, senza il bisogno di installare un qualche software client.

Dai risultati al codice

Ecco che siamo passati piano piano dall'utilizzo dei risultati forniti dal Web all'utilizzo del codice fornito dal Web.

I Web Services sono proprio dei servizi che mettono a disposizione il codice da utilizzare per costruire delle applicazioni più complesse.

Immaginiamo di montare una applicazione utilizzando diverse applicazioni installate su diversi server attraverso Internet.

Scendendo più in dettaglio, immaginiamo di utilizzare dei metodi e delle proprietà di un oggetto COM installato non sullo stesso server web ma su un altro server qualsiasi situato in Africa o nella Cina.

La tecnologia che permette di utilizzare la logica applicativa, oppure più semplicemente parlando, il codice di programmazione messo a disposizione di chi ne fa richiesta, è appunto alla base del concetto di Web Service.

Certo, ci sono altre tecnologie che hanno permesso di fare cose simili ma la novità insita nei Web Services sta nel fatto che questa volta, per consentire la comunicazione tra client e server, non si utilizzano dei protocolli specifici e proprietari ma un nuovo protocollo in fase di standardizzazione dal W3C, proposto non solo da Microsoft ma anche da IBM e altri grossi produttori.

La tecnologia Web Service è essenzialmente basata sul messaggio e quindi era necessario adottare un insieme di regole per poter inoltrare una richiesta client e costruire quindi un messaggio che possa essere capito dal server. Il server di conseguenza utilizzerà lo stesso formato per la risposta. Si è voluto scegliere un metodo standard per rappresentare i dati scambiati e la scelta non poteva che ricadere su XML. Il trasporto di questi dati in formato XML è affidato al protocollo HTTP. Dalla combinazione di XML e HTTP nasce proprio il protocollo SOAP (Simple Object Access Protocol), il protocollo standard per i Web Services.

Il WSDL

Una volta definito il modo in cui comunicare (il protocollo SOAP costituisce un insieme di regole per lo scambio delle informazioni) è necessario sapere cosa mettere a disposizione e cosa è possibile rendere disponibile con un Web Service.

Se possiamo utilizzare un metodo di un oggetto, allora abbiamo bisogno come minimo di sapere come si chiama il metodo, che parametri accetta, di che tipo e come va interpretato il risultato ottenuto.

E' proprio questo il compito del file WSDL (Web Service Description Language), un file in formato XML che descrive il Web Service in termini di metodi richiamabili, nomi dei parametri, tipi, ecc?

E' una sorta di contratto tra client e server, che si accordano in questo modo sulle informazioni da scambiarsi.

Un semplice Web Service

Dopo questa breve panoramica sull'idea del Web Service, passiamo alla pratica e vediamo come possiamo costruire un Web Service che ci permetta di interrogare un database Access residente su un server qualsiasi, diverso dal server Web da cui parte la chiamata: una possibile soluzione all'annoso problema di accedere ad un db Access remoto.

Ecco innanzitutto di cosa abbiamo bisogno: un sistema Windows 2000 Server (andrebbe bene anche Windows NT, ma gli esempi sono testati su Windows 2000), il Soap Toolkit 2.0 scaricabile da questo indirizzo e Visual Basic.

Il tutto è realizzato infatti con Classic ASP, avvalendosi di un componente installato con il Soap Toolkit e un componente realizzato con Visual Basic.

Naturalmente i presupposti per far funzionare questo esempio richiedono l'installazione del Soap Toolkit 2.0 sia sul server Web Service quanto sul server chiamante.

Sono presupposti un po' difficili da mettere in atto, visto che sarebbe bello avere installato il toolkit su tutti i server, anche se potrebbe essere un punto di partenza molto importante, in vista di una realizzazione futura di applicazioni di questo tipo.