Sotto la definizione di Web Services ricade una procedura in grado di erogare un servizio ad un client locale o remoto. Finora, nel mondo Windows, questo compito è stato svolto egregiamente dai cosiddetti componenti COM. Nel caso più tipico un componente di questo genere è disponibile solo per le applicazioni installate su una certa macchina, e un tempo venivano chiamati OLE Server, proprio a dimostrare la loro natura di servizio; le applicazioni facenti uso di tali servizi, viceversa, erano “client”.
Nel tempo la necessità di separare fisicamente il client dal server è stata risolta in vari modi, tra cui DCOM e la sua evoluzione COM+, ma tutti presentavano problemi di funzionamento o di configurazione al di fuori di una rete locale (Internet), legati particolarmente al routing (NETBIOS) oppure alla sicurezza (NAT, Firewall). Oggi la soluzione di questi problemi è alla 22 della nascita dei Web Services, insieme alle sempre più pressanti richieste che provengono dal business online.
Da questo punto di vista, al momento, la Microsoft sembra essere l’unica ad offrire una piattaforma veramente completa per questo tipo di sviluppo, e basta ricordare l’offerta a 360 gradi sia nel settore backoffice che negli strumenti di sviluppo. Evitando di fare la storia di come sono andate le cose, ricordo che lo sviluppo di Web Services è stato semplificato al punto di ridursi a poche procedure visuali o automatiche (wizard); anche se il gran parlare attorno a .NET potrebbe creare confusione (il nome stesso dice già tutto), nel seguito daremo prova di questo e vedremo qualche esempio pratico. Prima di proseguire, però, sento il dovere di ricordare che lo sviluppo di Web Services è un punto di arrivo per un programmatore più che un punto di partenza: anche se in questo articolo non si presuppone alcuna conoscenza precedente, non raccomando lo sviluppo di Web Services a chi non avesse dimestichezza con la creazione di componenti (DLL) COM.
Introduzione
In casa Microsoft le possibilità offerte per la realizzazione di Web Services sono essenzialmente due, una legata a Visual Studio 6 ed al SOAP Toolkit, ed una legata a .NET e alla versione 7 del tool di sviluppo. Si tratta di due strade piuttosto diverse; la prima dovrebbe privilegiare gli sviluppatori che non intendono adottare da subito il nuovo tool, e si pensa che siano parecchi, vista la rivoluzione che saranno costretti ad affrontare. Questa strada dovrebbe consentire di riutilizzare codice e competenze ed allo stesso tempo di fare cose nuove col minimo dello sforzo. La seconda strada, invece, apre nuovi orizzonti, ma richiede un prezzo da pagare piuttosto alto, soprattutto sul piano dell’incompatibilità col preesistente. A tal proposito la stessa Microsoft raccomanda che:
prodotti professionali scritti con Visual Studio 6 ed utilizzanti il SOAP Toolkit in versione 1, siano portati alla versione 2 del SOAP Toolkit;
prodotti da realizzare nel giro di poco tempo (si intenda prima del rilascio definitivo di .NET), siano realizzati esclusivamente con la versione 2 del SOAP Toolkit;
negli altri casi si raccomanda di utilizzare Visual Studio .NET;
in ogni caso si raccomanda di non utilizzare più il SOAP Toolkit in versione 1.x.
Detto questo, si capisce che lo sviluppo di Servizi Web non può prescindere da situazioni di fatto, come ad esempio se si sviluppa da zero e si ha piena libertà, oppure se si deve riutilizzare componenti business già esistenti. Infine se si può (o si deve) utilizzare codice standard o proveniente dall’open source e da Unix. Purtroppo queste considerazioni esulano dallo scopo di questo articolo, ma è bene sapere che una strada potrebbe essere molto vantaggiosa rispetto ad un’altra, e questa è una cosa da tenere presente in situazioni produttive.
Esiste, quindi, una varietà di esigenze possibili, e per ciascuna di queste esigenze esiste una soluzione; per contro va detto subito che si tratta quasi sempre soluzioni a pagamento, a differenza dell’approccio open source di PHP o di Perl.
Il nuovo ambiente di sviluppo Microsoft copre i linguaggi di programmazione più importanti, cioè il C++, il Basic, Java ed il nuovo C#. E’ possibile sviluppare un progetto utilizzando linguaggi differenti anche contemporaneamente e non ci sono limiti per la fantasia: tantissimi ingredienti possono essere mescolati come volete, in funzione delle necessità e delle scelte strategiche. Da una soluzione completamente multipiattaforma (Perl, PHP, Java, ecc.), oppure una via di mezzo (C#, simile a Java ma ottimizzato sul piano delle prestazioni) fino a riciclare competenze, codice e programmatori (classico caso del Visual Basic, sul quale molte software house hanno fatto grossi investimenti).
Insomma .NET accontenta tutti, anzi al momento consente (teoricamente) di sviluppare anche in COBOL, Mercury, Python, Component Pascal, Mondrian, RPG, Dyalog APL, Oberon, Scheme, Eiffel, Pascal, SmallTalk, Fortran, Perl, Standard ML, grazie al lavoro svolto da qualche decina di società sparse in tutto il mondo. Tra queste Active State, lo standard “de facto” per il Perl sotto Windows, merita una citazione particolare perché offre un eccellente supporto per lo sviluppo di Web Services sia all’interno che all’esterno della nuova piattaforma, con i linguaggi Python, Perl e PHP (e promette quello di Ruby e Tcl nel breve periodo). Visual Perl e Visual Python sono stati già annunciati (e probabilmente rilasciati nel momento in cui leggerete questo articolo) e d’altra parte il tool Komodo anticipava già da qualche tempo le intenzioni della software house, offrendo caratteristiche analoghe a quelle dell’editor di Visual Studio 7, con debug interattivo del Perl e supporto per XSLT (da notare che questo tool è licenziato a costo zero per uso non commerciale).
Potenzialmente, quindi, con Windows qualsiasi programmatore può avere accesso al mondo dei Web Services, anche se nella realtà pratica, come sempre, le soluzioni che verranno davvero utilizzate saranno molte meno. Cominciamo dalla prima.
Il SOAP Toolkit
Il SOAP Toolkit 2.0 è un tool che consente di realizzare Web Services in modo semplice e visuale. E’ un prodotto che si presta bene sia per scopi di studio o approfondimento, sia di utilizzo professionale. E’ pensato anche per principianti e se avete una minima familiarità con Visual Basic 6 e IIS sarete in grado di vedere in funzione il vostro primo Web Services nel giro di una decina di minuti. E’ pensato per realizzare Web Services completamente nuovi o per remotizzare quelli già esistenti senza che sia nemmeno necessario, in teoria, il relativo sorgente. Nella realtà pratica, però, si rende necessaria quasi sicuramente qualche modifica o, meglio ancora, la scrittura di un componente wrapper da esporre tramite i metodi SOAP.
Il toolkit è disponibile presso il sito MSDN (msdn.microsoft.com): il download, gratuito, pesa circa 1MB e contiene tutto quello che vi serve per realizzare un Web Service, mentre gli esempi d’uso sono disponibili con un download separato; pensato per il Visual Basic, è utilizzabile in qualunque contesto. Con la nuova versione sono stati effettuati numerosi cambiamenti che lo rendono incompatibile con le precedenti; in particolare, ora supporta completamente il WSDL (Web Services Description Language) e la specifica SOAP 1.1. Inoltre si tratta di un prodotto completamente supportato da Microsoft, mentre le versioni precedenti erano state rilasciate come sample, quindi senza supporto. L’implementazione degli standard SOAP e WSDL è completamente nuova rispetto alle precedenti, e la necessaria migrazione non dovrebbe essere molto difficoltosa: nella maggior parte dei casi sarà sufficiente generare un nuovo file WSDL al posto dei vecchi SDL. Viceversa, l’interfaccia low-level ROPE non esiste più, e le relative parti di codice sono da riscrivere usando i nuovi oggetti, ma non ci sono altre avvertenze.
D’altra parte il tool ha avuto un notevole successo da subito, ma deve essere stato usato soprattutto in contesti sperimentali, piuttosto che in ambienti realmente produttivi; pertanto, si giustifica la discreta incompatibilità tra le varie versioni. Anzi, vorrei segnalare la presenza di un gran numero di articoli che fanno ancora riferimento alle vecchie interfacce; quindi, assicuratevi sempre di controllare a quale versione si riferisce la letteratura, rispetto a quella istallata nel vostro computer.
Attualmente gli oggetti SOAP client e server sono supportati dalle seguenti piattaforme:
client di oggetti SOAP su Windows 98, Windows ME, Windows NT 4.0 Service Pack 6 e Windows 2000 Service Pack 1 o successive;
oggetti SOAP lato server su Windows 2000 or Windows NT 4.0 Service Pack 6 o successive;
in entrambi i casi è richiesto Internet Explorer 5.0 o 5.5, o versione successiva (comunque il SOAP Toolkit 2.0 installa il componente MSXML 3.0 SP1).
Il SOAP Setup wizard (soaptoolkit20.exe) installa sia i file necessari per sviluppare componenti, sia quelli per supportarne l’installazione. In particolare il runtime è in C:\Program Files\Common Files\MSSoap, mentre i file necessari per lo sviluppo sono in C:\Program Files\MSSoap.
La creazione di un componente SOAP, a partire da un componente COM già funzionante, si risolve nella creazione di un’applicazione IIS con un certo numero di settaggi che consentono di esporre l’interfaccia del componente, o parte di essa. Ciò può avvenire tramite una pagina ASP, o in alternativa tramite un listener ISAPI, ma tutto questo lavoro viene svolto dietro le quinte da un wizard che esegue tutte le operazioni evitando che si deva scrivere anche una sola riga di codice. I passi principali del wizard possono essere riassunti come segue, ma basta usarlo un paio di volte per avere la piena familiarità con lo strumento:
1. selezione del componente COM da esporre tramite SOAP;
2. scelta delle classi e dei membri da esportare;
3. scelta del server e del tipo di listener;
4. formato dei file e posizione del loro salvataggio.
.NET
A differenza di quanto accade nel caso precedente, con .NET lo sviluppo avviene da zero e non è necessario disporre di un componente già funzionante. Piuttosto che descrivere ulteriormente le caratteristiche di questo tool (servirebbe più di un articolo), proveremo direttamente a realizzare un servizio che implementa quattro metodi, le quattro operazioni.
Vista la semplicità del compito, la realizzazione del servizio sarà effettuata sia in Basic che in C#. Inoltre verranno creati sia un componente proxy che il client stesso (solo C#). Insomma vedremo il ciclo completo di realizzazione e utilizzo di un Web Service.
Visual Studio non si occupa solo di rendere possibili tutte le fasi dello sviluppo (editing, debugging, compilazione), ma predispone, tramite IIS, tutta l’interfaccia Web che consente di testare il componente. A differenza del SOAP Toolkit, il cui obbiettivo è quello di remotizzare componenti esistenti, le problematiche di tipo distribuito si pongono fin dall’inizio e questo aiuta a strutturare il componente in modo più corretto. E’ inutile dire che anche in questo caso le varie procedure sono molto semplificate, e in qualche minuto avrete il Web Service ‘up and running’. Ovviamente la prima cosa da fare è quella di creare un nuovo progetto.
In C#, selezionare nel menù principale File, Nuovo Progetto e nella successiva finestra di dialogo fare clic nella lista “Project type” su “Visual C# Projects” e nella lista “Templates” su “ASP.NET Web service”.
In Visual Basic, selezionare nel menù principale File, Nuovo Progetto e nella successiva finestra di dialogo fare clic nella lista “Project type” su “Visual Basic Projects” e nella lista “Templates” su “ASP.NET Web service”.
In entrambi i casi il nome del progetto (casella Name) diviene il nome di una cartella virtuale nel Web server specificato nella casella Location. Evidentemente il Web server deve essere appositamente configurato tramite l’installazione dei componenti del framework .NET e deve essere raggiungibile tramite le credenziali dell’utente di Visual Studio. Per semplificare le cose, confido nel fatto che utilizziate Windows 2000 (oppure XP) con IIS in locale, e pertanto la configurazione dell’ambiente sia già stata eseguita dall’installazione di Visual Studio. Se non è così, potrebbe succedere che qualcosa non funzioni…
A questo punto non resta che implementare i vari metodi e poiché non penso di dovermi dilungare sui dettagli di questa realizzazione, la riporto direttamente:
In C#:
[WebMethod]
public double Somma(double a, double b)
{
return a + b;
}
[WebMethod]
public double Sottrazione(double a, double b)
{
return a – b;
}
[WebMethod]
public double Moltiplicazione(double a, double b)
{
return a * b;
}
[WebMethod]
public double Divisione(double a, double b)
{
double tempValue = 0;
if ( b != 0 )
{
tempValue = a / b;
}
return tempValue;
}
Mentre in Visual Basic:
Somma = a + b
End Function
Sottrazione = a – b
End Function
Moltiplicazione = a * b
End Function
If b <> 0 Then
Divisione = a / b
End If
End Function
Fin qui non ci sarebbe davvero nulla di particolare, se non fosse che… abbiamo già finito. Infatti dopo aver effettuato il build della nostra soluzione (CTRL+SHIFT+B), è possibile aprire il browser all’indirizzo http://localhost/nome_progetto (in questo caso http://localhost/vbWebService) per ottenere una pagina di presentazione del servizio, con link che consentono di testare direttamente il funzionamento di tutti i metodi. Nulla di magico, questo lavoro poteva essere fatto tranquillamente a mano (magari col Notepad), ma il risparmio di tempo è sicuramente notevole e lo sviluppatore può concentrarsi sulla parte più interessante del suo lavoro.
Come immaginate, il servizio è già disponibile all’esterno se il computer è collegato alla rete con un indirizzo pubblico; in questo caso un client si può collegare da qualsiasi parte del mondo (a seconda delle impostazioni di security) e istanziare il nostro componente sia tramite il protocollo HTTP (metodi GET e POST) sia tramite SOAP. In particolare questo è quello che si vede con telnet (localhost, porta 80, la prima riga contiene il comando):
GET /vbWebService/Service1.asmx/Somma?a=2&b=3
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Fri, 12 Jan 2001 17:44:02 GMT
Cache-Control: private, max-age=0
Content-Type: text/xml; charset=utf-8
Content-Length: 86
La stessa cosa, ovviamente, si poteva fare con un browser digitando nella barra dell’indirizzo il comando:
http:// localhost/vbWebService/Service1.asmx/Somma?a=2&b=3
anche se nella maggior parte dei casi l’obbiettivo sarà quello di creare un client vero e proprio. A questo punto, anche per non appesantire troppo la trattazione, procederemo solo in linguaggio C#, visto che la creazione di un client in Visual Basic è assolutamente analoga.
Creazione del client
Per interagire col servizio appena realizzato (Operazioni) è necessario creare una classe di interfaccia, detta proxy. Questa classe verrà istanziata dal client, che in tal modo sarà in grado di richiamare le funzioni del componente remoto come si trattasse di un componente locale, incluso l’elenco dei membri automatico nell’editor. Sebbene la creazione di una simile classe sia del tutto possibile, si tratta di una compito laborioso e ripetitivo ed esiste un tool che, manco a dirlo, fa tutto automaticamente. Funziona dalla riga di comando e deve essere utilizzato dal Visual Studio Command Prompt, piuttosto che dalla finestra console standard. Per farla breve (la prima riga contiene il comando):
D:\>wsdl.exe http://localhost/csWebService/Service1.asmx?wsdl
Microsoft (R) Web Services Description Language Utility
[Microsoft (R) .NET Framework, Version 1.0.2914.16]
Copyright (C) Microsoft Corp. 1998-2001. All rights reserved.
Writing file ‘D:\Operazioni.cs’.
Su questo non mi dilungo in spiegazioni, poiché basta dare il comando senza parametri, per avere tutte le informazioni che servono; ricordo solo che, tramite apposito switch, è possibile generare la classe proxy in qualunque linguaggio, e questo vi consentirà di creare rapidamente il proxy che fa per voi. E’ da notare come il file generato da wsdl.exe supporti sia il funzionamento sincrono che asincrono, e per ciascun metodo viene creata anche la coppia BeginMetodo() e EndMetodo().
Questa caratteristica ha una certa importanza, dato che l’applicazione client non può essere certa che i metodi richiamati dal proxy siano effettivamente sempre disponibili, visto che il client è remoto e possono esserci disturbi nella comunicazione. Una volta che si dispone della classe proxy, il passo successivo è quello di creare una DLL (è sufficiente creare un nuovo progetto di tipo Class Library, aggiungere la reference a System.Web.Service, incollare il codice generato nel passo precedente e compilare; nel mio caso ho chiamato questa libreria ProxyOperazioni).
Finalmente si può affrontare il client vero e proprio, e per semplicità lo realizzeremo sotto forma di applicazione console. Una volta creato il nuovo progetto, questa volta di tipo Console Application, basta aggiungere una reference alla libreria che avete appena creato (ProxyOperazioni), ed un’altra a System.Web.Service. Il codice, semplicissimo, è il seguente:
using System;
namespace ClientOperazioni
{
class Class1
{
static void Main()
{
double a = 2;
double b = 3;
ProxyOperazioni.Operazioni calcola = new ProxyOperazioni.Operazioni();
Console.WriteLine (‘{0} + {1} = {2}’, a, b, calcola.Somma(a, b));
}
}
}
Eseguendo questo programma si ottiene il prevedibile output:
2 + 3 = 5
Press any key to continue
esattamente come immaginato.
