Ora che sappiamo come predisporre una pagina per l'utilizzo della Microsoft Ajax Library, passiamo a funzionalità decisamente più interessanti e vediamo come invocare un web service ASP.NET utilizzando la libreria.

 <%@ WebService Language="C#" Class="EchoWebService" %>
 
 using System;
 using System.Web;
 using System.Web.Services;
 using System.Web.Services.Protocols;
 using System.Web.Script.Services;
 
 [WebService(Namespace = "http://tempuri.org/")]
 [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)]
 [ScriptService]
 public class EchoWebService : System.Web.Services.WebService
 {
   [WebMethod]
   public string Echo(string toEcho)
   {
     return toEcho;
   }
 }
 

Il nostro web service è una classe chiamata EchoWebService che eredita dalla classe base WebService. All'interno della classe è definito il metodo Echo, che restituisce la stringa ricevuta come parametro.

Notiamo subito che, come sempre, tutti i web method devono essere decorati con l'attributo [WebMethod] dichiarato proprio sopra la signature del metodo. Inoltre, per permettere al metodo di essere chiamato da lato client utilizzando ASP.NET AJAX, è necessario aggiungere l'attributo [ScriptService] prima della dichiarazione della classe EchoWebService, come si può vedere nel codice di esempio.

Service Proxy

La presenza dell'attributo [ScriptService] è fondamentale perchè permette la generazione e l'invio di una porzione di codice JavaScript che contiene tutto ciò che è necessario per invocare i web method contenuti nel nostro web service. Questa porzione di codice JavaScript prende il nome di "proxy" perchè contiene (tra le altre cose) una serie di funzioni Javascript con lo stesso nome dei metodi definiti nel web service. La differenza è che queste funzioni, anzichè contenere il codice dei web method corrispondenti, contengono tutto il codice necessario per creare una richiesta asincrona (XmlHttp) che permette di chiamare il metodo dal server e quindi restituire il risultato del metodo di nuovo al client, senza bisogno di ricaricare l'intera pagina. Il termine "proxy" o "client proxy" è relativo alla funzione di questo codice, che permette di accedere dal client a metodi definiti in classi server.

Passiamo subito alla creazione della pagina ASP.NET che ci permette di completare l'esempio. Il codice seguente va inserito all'interno del tag form di una classica pagina ASP.NET.

 <asp:ScriptManager ID="TheScriptManager" runat="server">
   <Services>
     <asp:ServiceReference Path="EchoService.asmx" />
   </Services>
 </asp:ScriptManager>
 
 <span>Testo:</span>
 <input type="text" id="txtToEcho" />
 <input type="button" id="btnShow" value="Echo" />
 
 <script type="text/javascript">
 <!--
   function pageLoad(sender, e) {
     $addHandler($get('btnShow'), 'click', onClick);
   }
 
   function pageUnload(sender, e) {
     $removeHandler($get('btnShow'), 'click', onClick);
   }
 
   function onClick(evt) {
     EchoService.Echo($get('txtToEcho').value, onComplete);
   }
 
   function onComplete(result) {
     // result contiene la stringa restituita dal web method.
     alert(result);
   }
 //-->
 </script>
 

Nell'esempio la prima cosa da notare è il controllo ScriptManager, che deve essere sempre presente in qualunque pagina ASP.NET che utilizza le AJAX Extensions. All'interno dello ScriptManager è possibile definire una sezione chiamata Services, che contiene una serie di controlli ServiceReference, ciascuno dei quali specifica il percorso verso il web service al quale vogliamo accedere dalla nostra pagina. In questo caso, abbiamo referenziato il web service creato in precedenza, che si trova direttamente nella directory radice (root directory) del nostro sito. Lo ScriptManager fa in modo che per ciascun web service referenziato nella sezione Services venga richiesto il corrispondente proxy JavaScript.

Ancora sul service proxy

Senza entrare troppo nei dettagli, la generazione del service proxy avviene attraverso un handler HTTP chiamato ScriptResource.axd. Questo handler ha il compito di processare le richieste verso i file con estensione speciale "asmx/js" e di restituire il proxy corrispondente. Nel nostro caso viene richiesto il file EchoService.asmx/js e l'handler restituisce il proxy relativo al web service EchoService.asmx. Il meccanismo descritto non è particolarmente complicato e si rivela molto efficace.

Se volete avere un'idea di come è strutturato il codice del service proxy, è sufficiente caricare la pagina relativa nel browser e, nel nostro caso, sostituire il nome con "EchoService.asmx/js". A questo punto, la richiesta viene processata dall'handler che restituisce il seguente codice:

 var EchoService=function() {
 EchoService.initializeBase(this);
 this._timeout = 0;
 this._userContext = null;
 this._succeeded = null;
 this._failed = null;
 }
 
 EchoService.prototype={
 Echo:function(toEcho,succeededCallback, failedCallback, userContext) {
 return this._invoke(EchoService.get_path(), 'Echo',false,{toEcho:toEcho},succeededCallback,failedCallback,userContext); }}
 [...]
 

Questa porzione di codice Javascript mostra come il proxy sia costituito da una funzione EchoService (lo stesso nome del nostro web service) che viene estesa con una funzione chiamata Echo (stesso nome del nostro web method). Anzichè contenere il codice del metodo vero e proprio, Echo contiene il codice necessario per inviare una richiesta asincrona verso il web service ed invocare il "vero" metodo Echo.

Una API per interagire con il DOM

Torniamo al codice dell'esempio proposto. Dopo lo ScriptManager troviamo il markup della pagina, costituito da un semplice controllo TextBox affiancato da un pulsante. Come si vede, non c'è nessuna chiamata a funzioni JavaScript mescolata con l'HTML, perchè il modello di ciclo di vita lato client offerto da ASP.NET AJAX ci consente di separare il codice JavaScript dal markup così come facciamo lato server con il file di codebehind, che ha lo scopo di mantenere separato il codice C# o VB.NET dal markup ASP.NET. Come illustrato in precedenza, le funzioni pageLoad e pageUnload vengono chiamate automaticamente dal runtime di ASP.NET AJAX e ci consentono di gestire il codice client della pagina.

Nella funzione pageLoad c'è una interessante chiamata alla funzione $addHandler; questa funzione permette di aggiungere un handler per un evento lanciato da un elemento della pagina. Nel nostro caso l'elemento in questione è il pulsante, al quale accediamo utilizzando la funzione $get, che è semplicemente un alias per la funzione DOM standard document.getElementById. Il secondo parametro passato a $addHandler è una stringa contenente il nome dell'evento che vogliamo intercettare, in questo caso l'evento click del pulsante. Notiamo che non occorre utilizzare il prefisso 'on' prima del nome dell'evento. Infine, l'ultimo parametro è il nome della funzione JavaScript che gestisce l'evento, in questo caso onClick.

Contenuti dell'articolo

• Pagina 1
  • Abilitare ASP.NET AJAX in una pagina web
  • Ciclo di vita lato client
  • Sys.Application
  • Un modello a tre fasi
• Pagina 2
  • Service Proxy
  • Ancora sul service proxy
  • Una API per interagire con il DOM
• Pagina 3
  • Elaborazione dei risultati mediante callback
  • Round-trip di "tipi complessi"
  • Conclusioni
  • Risorse

• I nuovi controlli di ASP.NET 3.5: LinqDataSource, ListView e DataPager
• Galleria fotografica dinamica con ASP.NET AJAX
• Usare Search come un servizio nei tuoi siti e nei tuoi client
• Mappe nel tuo sito con Virtual Earth
• Integrare Windows Live ID, Contacts e Presence API nelle tue applicazioni
• Introduzione ai cloud based service con Windows Live Services
• Realizzare un custom extender AJAX con ASP.NET 3.5
• Tracciare le modifiche ai dati e allineare i datawarehouse con il Change Data Capture in SQL Server 2008