Implementare Web Service con ASP.

NET
ASP.NETWeb Service Nell'era del "tutto connesso" diventato essenziale dotare le proprie applicazioni web di meccanismi in grado di fornire i propri dati a dispositivi di natura eterogenea. Ecco come creare ed utilizzare Web Services con ASP.NET. Di questi tempi avrete sicuramente sentito parlare di Web Services se vi occupate in qualche modo delle tecnologie legate allo sviluppo web. E' senza dubbio l'argomento preferito di conferenze, libri e studi di mercato dell'ultimo periodo. Tutto sembra indicare che avranno un gran successo, considerando che aziende del calibro di Microsoft, Sun e IBM stanno investendo molte delle proprie energie (e dei fondi propri) in questa nuova direzione. Allo stato attuale, dunque, quasi tutti i grossi vendor hanno delle soluzioni che implementano in una qualche miusa i Web Services: .NET di Microsoft, Sun ONE di Sun Microsystems, Oracle9i di Oracle, per citare i pi importanti, quelli che sicuramente si spartiranno una grossa fetta della torta. Districarsi tra tutte queste soluzioni non cosa semplice, specie perch c' una grande battaglia di numeri, a colpa di benchmark, test e contro-test. Potete farvi comunque un'idea di questi "litigi", a partire da questa pagina . Ad ogni modo, con questo articolo cercheremo di capire meglio cosa sono e come possono essere utilizzati, soffermendoci in modo specifico su ASP.NET. Perch web services? In un mondo dove tutto connesso ma non abbastanza, e molte altre periferiche lo saranno sicuramente in un futuro abbastanza prossimo, diventa importante avere uno standard in grado di astrarre una serie di principi e funzionalit, per garantire a dispositivi di natura differente pieno accesso a tipologie di dati eterogenei. Oggi sembra futuristico, ma tra un paio d'anni il nostro frigorifero o la nostra lavatrice, o se preferite il nostro videoregistratore o il condizionatore di casa, avranno un piccolo server web incorporato al loro interno, in grado di svolgere alcune funzionalit oggi inimmaginabili, come il controllo a distanza, la manutenzione, la loro sincronizzazione. Pensate ad uno scenario del genere: programmare una serata con gli amici, davanti la TV, con la sicurezza di trovare la casa riscaldata ed il frigo pieno... Appare chiaro che uno standard sia auspicabile, oltre che inevitabile per certi versi: chi pu permettersi il lusso di acquistare componenti incompatibili tra di loro? I web services non sono altro che un tentativo di uniformare le "lingue" di diversi dispositivi e farli dialogare tra di loro nel migliore dei modi possibile. Cosa si pu fare subito? In linea di massima nell'informatica e nel mondo di internet in particolare si tende a cercare le soluzioni pi economiche e che abbiano un tempo di sviluppo o riconversione vantaggio rispetto alle altre. Ci sono molti punti a favore di Web Services come tecnologia:

 una tecnologia disponibile gi adesso su molte piattaforme e che sfrutta tecnologie gi disponibili da molto tempo; si basa su HTTP, il pi famoso ed utilizzato dei protocolli della famiglia TCP/IP, come base per il trasporto dei dati e su XML/SOAP per la loro rappresentazione. Niente di pi standard, insomma.

Come funziona un web service Principalmente un web service espone all'esterno una serie di funzionalit, attraverso un listener, anche chiamato server. Un listener un particolare programma che si mette in ascolto delle richieste che provengono da eventuali client ed ovviamente, cerca di rispondere nel modo migliore.

Come si pu vedere dalla figura precedente, le parti in gioco sono due: il client che effettua la richiesta (anche chiamato consumer ) ed 3ener che fornisce una risposta (anche chiamato provider ). E' essenzialmente quello che avviene con la normale navigazione attraverso un browser, solo che in questo caso gli attori non sono utente e server, ma due server. Il tutto, come abbiamo gi detto, sfruttando "solamente" XML (SOAP) e HTTP. L'utilit dei Web Services In genere i web services sono molto attuali, al giorno d'oggi, nell'ambito dei progetti legati in qualche modo all'e-business: banche, corrieri, societ d'affari o di e-commerce, sono queste le principali "cavie" della tecnologia. Le informazioni si sono scambiate da sempre, l'unica differenza che ora c' un metodo comune da seguire per snellire tutta una serie di processi e garantire un'uniformit di sviluppo. Un gran bel vantaggio, credetemi! In breve, due entit si mettono d'accordo per scambiarsi una serie di informazioni e per astrarre il procedimento, si affidano ad un sistema in grado di garantire una manutenibilit ed una durata della soluzione il pi lunga possibile. Detta in questo modo potrebbe sembrare che l'unico modo possibile per utilizzare i web services sia costruirsene uno. In realt, un modo alternativo per andare alla caccia di web services visitare UDDI.org , Universal Description, Discovery, and Integration service, un servizio promosso da IBM e Microsoft per rendere pubblici quei web services che possono essere integrati nelle proprie applicazioni. Provate a visitare il sito: c' solo l'imbarazzo della scelta!

E con le ASP? Le ASP non supportano nativamente i web services, bisogna pertanto dotarsi di un particolare tool (il SOAP Toolkit), scaricabile gratuitamente dal sito Microsoft . Va installato sui server su cui andremo ad utilizzare i nostri web services (sia listener che client) e permette di accedere alle funzionalit di un web service senza entrare nei dettagli implementativi di questa tecnologia. Avendo installato correttamente il toolkit, ci baster un codice come quello utilizzato nel [listato1] per richiamare un web service. Per quanto riguarda la creazione della parte server, ovvero di un servizio che metta a disposizione dei client eventuali informazioni, il discorso si complica un attimo. Il SOAP toolkit infatti in grado di convertire in web services solo server component, ovvero oggetti COM compilati. Questo vuol dire che se desiderate mantenere la business logic della vostra applicazione in uno script ASP, o semplicemente il vostro attuale fornitore di hosting non vi permette l'uso di DLL COM, questo non l'approccio migliore e vi tocca fornire l'implementazione manualmente, cosa piuttosto scomoda e resa automatica dal toolkit grazie alla creazione dei file WDSL e WSML. Se vi interessa comunque sfruttare queste caratteristiche, vi consiglio di leggere in proposito questo tutorial . A questo punto, importante soffermarsi in particolare sul compito del 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... Rappresenta una sorta di contratto tra client e server, che si accordano in questo modo sulle informazioni da scambiarsi, ed essenziale perch le due entit funzionino correttamente. Web Services nell'era .NET Il .NET framework nasce gi con pieno supporto ai web services, con un motore che cattura le chiamate ai web services, rendendo molto semplice e veloce l'accesso e la creazione di questo genere di applicazioni. I Web Services .NET sono facilmente individuabili per via della loro estensione (.asmx). Dunque, sviluppare Web Services con ASP.NET estremamente semplice, come vedremo tra qualche riga. Se siamo in possesso di una copia (anche beta) di Visual Studio.NET, il discorso si fa ancora pi semplice: con pochi click possibile creare un web service funzionante: sar VS.NET a creare automaticamente tutto il codice necessario.

Esempio di creazione di Web Service con VS.NET.

Il listener con ASP.NET Come dicevamo, il bello di ASP.NET risiede nella possibilit di gestire i web services in maniera nativa. Nel [listato 2] potete trovare un primo rudimentale esempio di Web Service. In questo caso abbiamo scelto come linguaggio il C#, ma nulla ci vieta di scriverlo in uno degli altri linguaggi supportati dal .NET framework. Lo stesso web service scritto in VB.NET, la nuova versione riveduta e corretta di Visual Basic, disponibile nel [listato 3]. Come potete notare, differenza di sintassi a parte, il risultato e la logica dei due esempi la stessa, indentica. E' utile soffermarsi su alcuni punti in particolare: Namespace : il nome esterno del web service. importante scegliere qualcosa di semplice ed immediato. Description: la descrizione che verr mostrata quando si "naviga" all'interno di un web services (vedere la figura 3).

Semplicemente richiamando il nostro Web Services (ad esempio, con http://localhost/webservices/listenerVB.asmx) vedremo qualcosa come quello mostrato nella figura precedente. Cliccando sull'unica funzione disponibile, accederemo ad una schermata come la seguente, che ci permetter di testare il Web Service e ci mostrer alcuni esempi di chiamata, molto utili nel caso in cui si stia cercando di fruirne da una piattaforma differente.

Infine, aggiungendo ?WSDL come parametro (http://localhost/webservices/listenerVB.asmx? WSDL) ci verr automaticamente mostrato il WSDL relativo.

Costruiamo il client Il client, anche detto consumer, consumatore, leggermente pi difficile da costruire rispetto alla parte server. Per prima cosa, bisogna creare un proxy, a partire dal Web Service, che permetta al nostro client di poter accedere senza problemi alle caratteristiche della parte server. Anche in questo caso ci viene incontro il .NET SDK, con un tool a riga di comando in grado di costruire automaticamente il WSDL necessario ed implementarlo tramite proxy.
wsdl.exe /language: <i>language</i> /protocol: <i>protocol </i> /namespace: <i>Namespace</i> /out: <i>filename </i> /username: <i>username</i> /password: <i>password</i> /domain: <i>domain </i> /appsettingurlkey: <i>keyname</i> <i><url or path></i>

Nel nostro caso, basta lanciare dal prompt dei comandi, questo:
wsdl.exe /language:Cs /namespace:myClient /out:euroClient.cs http://localhost/webservices/listenerVB.asmx

Abbiamo scelto di creare il proxy in C#, a partire dal nostro listener scritto in VB.NET, ma nulla ci vieta di fare il contrario o di utilizzare lo stesso linguaggio: sono dettagli implementativi che siamo noi stessi a decidere. Il lavoro di questo tool visibile nel [listato 4]. Compilare il proxy Per comodit, conveniente creare un assembly (un file compilato) in grado di fornire l'accesso al web services in tutte le pagine della nostra applicazione. A tale scopo, creiamo un semplice file, sempre in C#, come quello del [listato 5], che si occuper essenzialmente di semplificarci la vita. Ci spostiamo dal prompt dei comandi sulla directory in cui sono contenuti i nostri due file, e facciamo eseguire il seguente comando, che compiler i due file in un unico assembly:
csc.exe /t:library /out:MyClient.dll *.cs /r:System.dll,System.Web.dll

Csc non altro che il compiler per C#, disponibile sempre con l'SDK .NET. L'omologo per VB.NET VBc.exe. I parametri accettati sono gli stessi, in particolare out consente di specificare il nome e la posizione del file generato. Il file creato, MyClient.dll, andr sposato nella directory /bin/ della nostra applicazione, che rappresenta il percorso in cui il motore ASP.NET va a ricercare gli assembly. Implementare il proxy Una volta creato il proxy, dobbiamo implementarlo. Il meccanismo a questo punto molto semplice, basta utilizzare uno script come quello del [listato 6]. Si tratta di ereditare dal proxy alcune caratteristiche, tramite la direttiva Inherits . Abbiamo scelto la vita meno flessibile ma certamente pi standard, quindi possibile semplificare lo script, facendo in modo che restituisca il valore attraverso una semplice funzione.

Conclusioni Le varianti possibili sono numerose e a partire da questi esempi potete certamente creare Web Services di un'utilit sicuramente maggiore rispetto alla semplice conversione Lire-Euro.

Ad ogni modo, gli esempi trattati in questo articolo potete scaricarili e provarli in locale. Questo articolo solo uno spunto, qualcosa per farvi scoprire nel migliore dei modi questa tecnologia davvero affascinante. Sappiate che ormai quasi tutti i prodotti supportano o hanno in cantiere il supporto per i Web Services, per cui pu ritornarvi davvero utile dare un'occhiata pi in profondit! Approfondimenti Serializzazione XML con i Web Service di ASP.NET e ASP WebServices.org MSDN